[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Received: from ietf.org by ietf.org id aa02570; 26 Feb 97 2:50 EST
Received: from cnri by ietf.org id aa02262; 26 Feb 97 2:41 EST
Received: from sunhegering7.nm.informatik.uni-muenchen.de by CNRI.Reston.VA.US
id aa03801; 26 Feb 97 2:41 EST
Received: from hpheger9.nm.informatik.uni-muenchen.de (hpheger9.nm.informatik.uni-muenchen.de [129.187.214.29]) by sunhegering7.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with ESMTP id IAA09983; Wed, 26 Feb 1997 08:34:48 +0100 (MET)
Received: from localhost (neumair at localhost) by hpheger9.nm.informatik.uni-muenchen.de (8.7.5/8.6.10) with SMTP id IAA18455; Wed, 26 Feb 1997 08:34:40 +0100 (MET)
Date: Wed, 26 Feb 1997 08:34:40 +0100 (MET)
Sender:ietf-request at ietf.org
From: Bernhard Neumair <neumair at nm.informatik.uni-muenchen.de>
To: dbworld at cs.wisc.edu, dec_wireless at samson.zko.dec.com, dini at crim.ca,
end2end-interest at venera.isi.edu, enternet at bbn.com,
gcomlist1 at manjaro.ece.iit.edu, giga at tele.pitt.edu, globecom at signet.com.sg,
hipparch at sophia.inria.fr, ieee.announce at bellcore.com,
ieee_rtc_list at cs.tamu.edu, ieeetcpc at ccvm.sunysb.edu,
ietf at CNRI.Reston.VA.US, ifip-6-1 at labs-n.bbn.com, ifip-nm at bbn.com,
isadsoc at fokus.gmd.de, itc at fokus.gmd.de
Subject: CALL FOR PAPERS: JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Message-ID: <Pine.HPP.3.95q.970226083410.18342C-100000 at hpheger9.nm.informatik.uni-muenchen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
****************************************************
*** Please note the new deadline for submissions ***
****************************************************
[Apologies if you receive multiple copies of this.]
------------------------------------------------------------------
*********************
* Deadline Extended *
*********************
CALL FOR PAPERS
JOURNAL OF NETWORK AND SYSTEMS MANAGEMENT
Special Issue on
Managing Mobility and Mobile Computing Systems
Guest Editors:
Bernhard Neumair (University of Munich)
Rene Wies (TTI TECTRAN GmbH)
During the recent years Mobile Computing has become a very
important trend in the usage of computing systems. The advantages
of mobility and the increasing availability of adequate hardware
and software have promoted the development and deployment of
wireless LANs. Furthermore, with greater distances being bridged
by corporate networks, and with world-wide network access, mobile
computing systems can be increasingly used almost anywhere and any
time without a restriction on the available services (e.g., mail,
WWW, etc.).
Managing these mobile systems, the related services, data, and
networks as well as managing the mobility aspects of users (e.g.,
location of home directories, applications, etc.), however, are
still unsolved problems. This special issue is intended to
address these issues and to provide hints for future directions.
The focus of this special issue will be on, but is not limited to,
the following topics:
o Applicability of existing management concepts, tools,
platforms, architectures, etc. to mobile computing
o New concepts, tools, and protocols needed for the
management of mobility and mobile computing systems
o Aspects of dynamic management domains and management
policies incorporating mobile computing systems
o Management requirements imposed by new services and
applications, and new techniques supporting mobility
(e.g., replicating file systems, caching strategies)
o Management requirements imposed by new technologies and
standards (Wireless LANs, HIPERLAN, IEEE P802.11, Mobile
IP, etc.)
o Change and configuration management for mobile
systems (dynamic configuration, downloading and
customizing configurations), and integration aspects
o Security and accounting aspects for mobile systems
o Managing and integrating PDAs
Instructions to Authors:
Please submit four copies of your manuscript, not exceeding 20
double-spaced type-written pages, to one of the Guest Editors
(postscript files by e-mail are also welcome). Please prepare
manuscripts according to the Instructions to Contributors which
can be found in any copy of the Journal. An electronic copy of
this can be obtained by visiting JNSM www page at URL
http://www.cstp.umkc.edu/jnsm/.
Please include the authors' names, addresses, telephone and fax
numbers, and e-mail addresses.
Guest Editors:
Dr. Bernhard Neumair
Department of Computer Science
University of Munich
Oettingenstrasse 67, D-80538 Munich, Germany
Phone: +49-89-2178-2171
Fax: +49-89-2178-2262
E-Mail: neumair at informatik.uni-muenchen.de
Dr. Rene Wies
TTI TECTRAN GmbH
P.O. Box 251
D-82026 Gruenwald/Munich, Germany
Phone: +49-89-641-97040
Fax: +49-89-641-4299
E-Mail: r.wies at ieee.org
Schedule:
Manuscript due: March 30, 1997
Notification of Acceptance: July 30, 1997
Revised Manuscript due: September 30, 1997
Publication Date: First Quarter 1998
Received: from ietf.org by ietf.org id aa05749; 26 Feb 97 4:48 EST
Received: from cnri by ietf.org id aa05641; 26 Feb 97 4:44 EST
Received: from emout14.mx.aol.com by CNRI.Reston.VA.US id aa05651;
26 Feb 97 4:44 EST
Received: (from root at localhost)
by emout14.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0)
id EAA19649;
Wed, 26 Feb 1997 04:41:18 -0500 (EST)
Date: Wed, 26 Feb 1997 04:41:18 -0500 (EST)
Sender:ietf-request at ietf.org
From: GlobalIS at aol.com
Message-ID: <970226044115_-1172476214 at emout14.mail.aol.com>
To: DOSLYNX-DEV at raven.cc.ukans.edu, HPV at sonoma.edu, IETF at CNRI.Reston.VA.US,
POWDERWORKS at cs.colorado.edu
Subject: NEW COMPUTER VIRUS ALERT!!!!
Source-Info: From (or Sender) name not authenticated.
WARNING!!!!!!!
There are several new and highly dangerous internet-spread viruses that could
cause hundreds, even thousands of dollars' worth of damage to your hardware
and/or software. GIS (Global Information Services) has compiled all the
latest data on these newest viruses, as well as the older ones. Learn how to
protect yourself!!!
For more information, reply with the word "information".
Received: from ietf.org by ietf.org id aa11187; 26 Feb 97 8:27 EST
Received: from mersey.hursley.ibm.com by ietf.org id aa11059; 26 Feb 97 8:23 EST
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA64734; Wed, 26 Feb 1997 13:21:19 GMT
Date: Wed, 26 Feb 1997 13:21:19 GMT
Message-Id: <9702261321.AA64734 at hursley.ibm.com>
Sender:ietf-request at ietf.org
From: "(Brian E Carpenter)" <brian at hursley.ibm.com>
Subject: don't shoot the messenger
To: ietf at ietf.org
Reply-To: ietf at ietf.org
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 895
Source-Info: From (or Sender) name not authenticated.
I hesitate to do this but for those of you that don't
receive the ISOC electronic newsletter, the following snip
may be of interest.
"* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
Cyber Promotions, Inc., best known for having been kicked off of as many
as 20 different Internet Service Providers for sending unsolicited e-
mail, has announced that it will become an Internet Service Provider
itself. CPI plans to charge its customers $50 per month, enabling them
to send unsolicited mass mailings -- referred to as spams -- as long as
they allow users to remove themselves from such lists and comply with
local, state, and federal laws. When asked why the company had not
thought of this solution earlier, CPI president Sanford Wallace said
that his company had been too busy with lawsuits.
(Cowles/SIMBA Media Daily 20 Feb 1997)"
Don't shoot the messenger :-)
Brian Carpenter
Received: from ietf.org by ietf.org id aa11740; 26 Feb 97 8:35 EST
Received: from AIC.NET by ietf.org id aa11555; 26 Feb 97 8:34 EST
Received: by aic.net for ietf at ietf.org at Wed, 26 Feb 1997 16:31:40 +0300 (GMT)
Message-Id: <199702261331.QAA17592 at aic.net>
Subject: Re: don't shoot the messenger
To: ietf at ietf.org
Date: Wed, 26 Feb 1997 16:31:39 +0300 (GMT)
In-Reply-To: <9702261321.AA64734 at hursley.ibm.com> from "ietf-request at ietf.org" at Feb 26, 97 01:21:19 pm
Sender:ietf-request at ietf.org
From: Edgar Danielian <edd at acm.org>
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
> Cyber Promotions, Inc., best known for having been kicked off of as many
> as 20 different Internet Service Providers for sending unsolicited e-
> mail, has announced that it will become an Internet Service Provider
> itself. CPI plans to charge its customers $50 per month, enabling them
> to send unsolicited mass mailings -- referred to as spams -- as long as
> they allow users to remove themselves from such lists and comply with
> local, state, and federal laws. When asked why the company had not
> thought of this solution earlier, CPI president Sanford Wallace said
> that his company had been too busy with lawsuits.
> (Cowles/SIMBA Media Daily 20 Feb 1997)"
I'm sure they will be much more busy after becoming ISP...
IMHO,
-edd
Received: from ietf.org by ietf.org id aa12514; 26 Feb 97 8:50 EST
Received: from popper.pbi.net by ietf.org id aa12392; 26 Feb 97 8:48 EST
Received: from hobbes.eng.pbi.net by popper.PBI.net (4.1/PBI-12/1/95)
id AA14244; Wed, 26 Feb 97 05:46:11 PST
Date: Wed, 26 Feb 1997 05:46:11 -0800 (PST)
Sender:ietf-request at ietf.org
From: Christopher Nielsen <cnielsen at pbi.net>
X-Sender: cnielsen at hobbes.eng.pbi.net
To: ietf at ietf.org
Subject: Re: don't shoot the messenger
In-Reply-To: <9702261321.AA64734 at hursley.ibm.com>
Message-Id: <Pine.GSO.3.95.970226053700.8492s-100000 at hobbes.eng.pbi.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 26 Feb 1997, (Brian E Carpenter) wrote:
> "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
> Cyber Promotions, Inc., best known for having been kicked off of as many
> as 20 different Internet Service Providers for sending unsolicited e-
> mail, has announced that it will become an Internet Service Provider
> itself. CPI plans to charge its customers $50 per month, enabling them
> to send unsolicited mass mailings -- referred to as spams -- as long as
> they allow users to remove themselves from such lists and comply with
> local, state, and federal laws. When asked why the company had not
> thought of this solution earlier, CPI president Sanford Wallace said
> that his company had been too busy with lawsuits.
> (Cowles/SIMBA Media Daily 20 Feb 1997)"
Would it be legally feasible to deny peering agreements or upstream
service to someone like this? They have to either get their upstream
service from -someone- or have a peering agreement. I'd be interested to
see who it is or if they can manage to get a peering agreement with
anyone.
On another note, those who attended the most recent NANOG meeting probably
heard Paul Vixie's solution to spammers: blackhole routes.
--
Christopher Nielsen Pacific Bell Internet Services
Senior Systems Administrator and San Francisco, CA
Security Officer
cnielsen at pbi.net #include <stddsclmr.h>
Received: from ietf.org by ietf.org id aa13854; 26 Feb 97 9:08 EST
Received: from cs.columbia.edu by ietf.org id aa13748; 26 Feb 97 9:06 EST
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id JAA15033; Wed, 26 Feb 1997 09:04:02 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id JAA11225; Wed, 26 Feb 1997 09:04:01 -0500 (EST)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <331442D1.10E1 at cs.columbia.edu>
Date: Wed, 26 Feb 1997 09:04:01 -0500
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Christopher Nielsen <cnielsen at pbi.net>
CC: ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <Pine.GSO.3.95.970226053700.8492s-100000 at hobbes.eng.pbi.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Christopher Nielsen wrote:
>
> On Wed, 26 Feb 1997, (Brian E Carpenter) wrote:
>
> > "* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
> > Cyber Promotions, Inc., best known for having been kicked off of as many
> > as 20 different Internet Service Providers for sending unsolicited e-
> > mail, has announced that it will become an Internet Service Provider
> > itself. CPI plans to charge its customers $50 per month, enabling them
> > to send unsolicited mass mailings -- referred to as spams -- as long as
> > they allow users to remove themselves from such lists and comply with
> > local, state, and federal laws. When asked why the company had not
> > thought of this solution earlier, CPI president Sanford Wallace said
> > that his company had been too busy with lawsuits.
> > (Cowles/SIMBA Media Daily 20 Feb 1997)"
>
> Would it be legally feasible to deny peering agreements or upstream
> service to someone like this? They have to either get their upstream
> service from -someone- or have a peering agreement. I'd be interested to
> see who it is or if they can manage to get a peering agreement with
> anyone.
>
> On another note, those who attended the most recent NANOG meeting probably
> heard Paul Vixie's solution to spammers: blackhole routes.
I'd say: get all the spammers to sign up with one spam-only provider,
find out what IP range they got and add a capability to sendmail to
block that range. Unlike, say, netcom, you don't have to worry about
blocking the mail of innocent bystanders.
>
> --
> Christopher Nielsen Pacific Bell Internet Services
> Senior Systems Administrator and San Francisco, CA
> Security Officer
> cnielsen at pbi.net #include <stddsclmr.h>
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from ietf.org by ietf.org id aa15002; 26 Feb 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa14422; 26 Feb 97 9:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tcplw at bsdi.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-tcplw-high-performance-00.txt
Date: Wed, 26 Feb 1997 09:19:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260919.aa14422 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TCP Large Windows Working
Group of the IETF.
Title : TCP Extensions for High Performance
Author(s) : V. Jacobson, R. Braden, D. Borman
Filename : draft-ietf-tcplw-high-performance-00.txt
Pages : 41
Date : 02/25/1997
This memo presents a set of TCP extensions to improve performance over
large bandwidth*delay product paths and to provide reliable operation over
very high-speed paths. It defines new TCP options for scaled windows and
timestamps, which are designed to provide compatible interworking with
TCP's that do not implement the extensions. The timestamps are used for
two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS
(Protect Against Wrapped Sequences). Selective acknowledgments are not
included in this memo.
This memo updates and obsoletes RFC-1323, a Proposed Standard, with
small clarifications and corrections.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-tcplw-high-performance-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tcplw-high-performance-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tcplw-high-performance-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970226091302.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tcplw-high-performance-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tcplw-high-performance-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226091302.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14999; 26 Feb 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa14368; 26 Feb 97 9:18 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-pam-html-fine-trans-00.txt
Date: Wed, 26 Feb 1997 09:18:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260918.aa14368 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Fine-Grained Transclusion in the
Hypertext Markup Language
Author(s) : A. Pam
Filename : draft-pam-html-fine-trans-00.txt
Pages : 3
Date : 02/25/1997
The word "hypertext" was coined by Theodor Holm Nelson in his paper "A File
Structure for the Complex, the Changing and the Indeterminate", presented
at the ACM 20th national conference in 1965. One of the key concepts in
Nelson's vision of hypertext is "transclusion" or virtual inclusion, which
permits composite documents to be constructed by reference to the original
components rather than by copying.
The Hypertext Markup Language (HTML) is a markup language used to create
hypertext documents that are platform independent. HTML currently
permits the transclusion of various content types using tags which
accept a "SRC" attribute, such as the <IMG>, <EMBED> and <APPLET> tags,
but does not provide a mechanism for transcluding textual content.
This document proposes markup for text transclusions in HTML and
explains its usage.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-pam-html-fine-trans-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-pam-html-fine-trans-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-pam-html-fine-trans-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970225113525.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-pam-html-fine-trans-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-pam-html-fine-trans-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225113525.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15004; 26 Feb 97 9:24 EST
Received: from ietf.ietf.org by ietf.org id aa14331; 26 Feb 97 9:18 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-03.txt
Date: Wed, 26 Feb 1997 09:18:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260918.aa14331 at ietf.org>
--NextPart
Note: This revision includes changes as a result of WG Last Call
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : The resolution of ISAKMP with Oakley
Author(s) : D. Harkins, D. Carrel
Filename : draft-ietf-ipsec-isakmp-oakley-03.txt
Pages : 32
Date : 02/25/1997
[MSST96] (ISAKMP) provides a framework for authentication and key exchange
but does not define them. ISAKMP is designed to be key exchange
independant; that is, it is designed to support many different key
exchanges.
[Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and
details the services provided by each (e.g. perfect forward secrecy for
keys, identity protection, and authentication).
This document describes a proposal for using the Oakley Key Exchange
Protocol in conjunction with ISAKMP to obtain authenticated keying
material for use with ISAKMP, and for other security associations
such as AH and ESP for the IETF IPsec DOI.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-isakmp-oakley-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970225104523.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-isakmp-oakley-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225104523.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16504; 26 Feb 97 9:40 EST
Received: from ietf.ietf.org by ietf.org id aa14443; 26 Feb 97 9:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-00.txt
Date: Wed, 26 Feb 1997 09:19:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702260919.aa14443 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (RR) Record in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-00.txt
Pages : 15
Date : 02/25/1997
This document describes the use of the Roaming Relationship (RR) record in
the DNS for the description of inter-domain business relationships, as
required for enabling of roaming. In the absence of DNS security, RR
records may be used for determining the existence of a business
relationship between the local ISP and the user's home domain, as well as
the location of an appropriate settlement agent. However, since the RR
records are not secured, other methods (such as hierarchical authentication
routing) must be used in order to validate the business relationship path.
When DNS security is implemented, the business relationship path is
authenticated via digital signatures, and as a result, additional services
may be provided, such as non-repudiation of proxied authentications and
signed receipts for accounting record transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-dnsrr-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970225140606.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970225140606.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16865; 26 Feb 97 9:44 EST
Received: from bells.cs.ucl.ac.uk by ietf.org id aa16595; 26 Feb 97 9:42 EST
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.25501-0 at bells.cs.ucl.ac.uk>; Wed, 26 Feb 1997 14:39:47 +0000
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
cc: Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
In-reply-to: Your message of "Wed, 26 Feb 1997 09:04:01 EST." <331442D1.10E1 at cs.columbia.edu>
Date: Wed, 26 Feb 1997 14:39:45 +0000
Message-ID: <2235.856967985 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
>> On another note, those who attended the most recent NANOG meeting probably
>> heard Paul Vixie's solution to spammers: blackhole routes.
>I'd say: get all the spammers to sign up with one spam-only provider,
>find out what IP range they got and add a capability to sendmail to
>block that range. Unlike, say, netcom, you don't have to worry about
>blocking the mail of innocent bystanders.
why block them?
mark their traffic as low precedence, AND bill them for it
jon
Received: from ietf.org by ietf.org id aa23096; 26 Feb 97 11:18 EST
Received: from core.IConNet.NET by ietf.org id aa22826; 26 Feb 97 11:14 EST
Received: from localhost (brisco at localhost)
by fs.IConNet.NET (8.8.5/8.8.5) with SMTP id LAA18133;
Wed, 26 Feb 1997 11:12:10 -0500 (EST)
Date: Wed, 26 Feb 1997 11:12:10 -0500 (EST)
Sender:ietf-request at ietf.org
From: "T.P.Brisco" <brisco at iconnet.net>
To: Bill Flanigan <flanigab at ncr.disa.mil>
cc: ietf at ietf.org, Roger WOJA Kermode <woja at media.mit.edu>
Subject: Re: 38th IETF Meeting...Hotel Gripe
In-Reply-To: <9701258569.AA856922921 at ncr.disa.mil>
Message-ID: <Pine.GSO.3.92.970226111101.13091B-100000 at fs.IConNet.NET>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Can someone post a handful of nearby hotels? The lady
at registration wasn't much help ....
Tom
On Tue, 25 Feb 1997, Bill Flanigan wrote:
> Hello Roger,
>
> Maybe you're lucky--well, sort of.
>
> After all, this is Memphis TN (not Memphis, Egypt or Mars) where
> the going rates for hotels/motor inns/motels is in the $50-60
> range--AAA, e.g., lists about 25 (with three-diamond ratings) in that
> price range including a number within brisk-walking distance of the
> Peabody.
Received: from ietf.org by ietf.org id aa23640; 26 Feb 97 11:28 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa23547;
26 Feb 97 11:26 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA16885; Wed, 26 Feb 97 11:23:35 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA16627; Wed, 26 Feb 1997 11:23:25 -0500
Date: Wed, 26 Feb 1997 11:23:25 -0500
Message-Id: <9702261623.AA16627 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Cc: Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
In-Reply-To: Henning Schulzrinne's message of Wed, 26 Feb 1997 09:04:01 -0500,
<331442D1.10E1 at cs.columbia.edu>
Subject: Re: don't shoot the messenger
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Wed, 26 Feb 1997 09:04:01 -0500
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
I'd say: get all the spammers to sign up with one spam-only provider,
find out what IP range they got and add a capability to sendmail to
block that range. Unlike, say, netcom, you don't have to worry about
blocking the mail of innocent bystanders.
MIT has already put that feature (an access list for incoming IP
addresses/subnets) in our sendmail hubs.....
- Ted
Received: from ietf.org by ietf.org id aa23855; 26 Feb 97 11:29 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa23665;
26 Feb 97 11:28 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA17616; Wed, 26 Feb 97 11:26:09 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA16632; Wed, 26 Feb 1997 11:26:07 -0500
Date: Wed, 26 Feb 1997 11:26:07 -0500
Message-Id: <9702261626.AA16632 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Bill Flanigan <flanigab at ncr.disa.mil>
Cc: ietf at ietf.org, Roger WOJA Kermode <woja at media.mit.edu>,
flanigab at ncr.disa.mil
In-Reply-To: Bill Flanigan's message of Tue, 25 Feb 97 17:39:20 EST,
<9701258569.AA856922921 at ncr.disa.mil>
Subject: Re: 38th IETF Meeting...Hotel Gripe
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Tue, 25 Feb 97 17:39:20 EST
From: Bill Flanigan <flanigab at ncr.disa.mil>
Naturally, this can't help, but make me a bit curious about who (if
anyone) is seriously negotiating these rates, and what criteria (if
any) are being used?
IETF attendance is now so large that advance-booking guarantees to
completely fill many hotels in an area (even a year in advance) is
virtually riskless. This should put the IETF hotel-booking folks
firmly in the driver's seat as far as getting the lowest possible room
rate in the meeting hotel and others in the area.
Actually, we have a similar problem to USENIX. The number of meeting
and breakout rooms that we need is extremely small compared to the
number of attendees we have (read: number of paying hotel rooms). Thus,
the number of sites where we can meet are quite limited.
This does make me wonder why there were so few rooms reserved at the
IETF block rate, though. Unless the hotel was hoping that enough other
people would pay the full rate after the IETF block was exhausted,
instead of staying at the $50-$60 motel that's 1/4 mile away....
- Ted
Received: from ietf.org by ietf.org id aa24269; 26 Feb 97 11:35 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa24126; 26 Feb 97 11:34 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA32304;
Wed, 26 Feb 1997 11:31:59 -0500
Message-Id: <199702261631.LAA32304 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Neal McBurnett <nealmcb at bell-labs.com>
Cc: ietf at ietf.org, m.t.hamilton at lut.ac.uk, wright at lbl.gov
Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists
In-Reply-To: Your message of "Tue, 25 Feb 1997 16:58:42 PST."
<9702260058.AA13799 at lever.dr.lucent.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <9702260058.AA13799 at lever.dr.lucent.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_383835428P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 26 Feb 1997 11:31:58 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_383835428P
Content-Type: text/plain; charset=us-ascii
On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said:
> The machines are frequently distinct from the "mail" machine
> for a given organization because the operational characteristics
> and requirements can be very different.
>
> I propose the alias "list" for the "mail list" service.
> It is the most common generic name in the lists I subscribe to.
> Are there common alternatives?
Well.. actually, I suspect that in most cases, the machine name is
either listserv.domain.xyz (for people running LSoft's software),
or majordomo.domain.xyz, or listproc.domain.xyz (for those running
the CREN list processor). I can't remember seeing a machine called
list.domain.xyz, and I've been doing Listserv stuff since 1984 or so.
Are you sure that your "the lists I subscribe to" isn't biased in some
way (for instance, many of your lists are hosted in one domain, so
that domain's preferences impact the names you see)?
The command languages for these 3 products are sufficiently different
that bundling them all under the same 'list' is probably a bad idea.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_383835428P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxRlfNQBOOoptg9JAQHCUwP/W7VtJ0FGgeZ3P/U0Ei7Dx7/KgWZ0sFb+
1HMGcZa8UASOZJ6o3NegsAoFHkkJi5rqW574UpN9rJS7476s0wSSMeJg5M+MZYb7
z9/XlB5oMb8UIEEyqMkTaOYSJJBP10ztRsRo42SjGQgTXV3NLrPNo3pPoLnntCiE
YM8CSrLt7aA=
=SbSb
-----END PGP MESSAGE-----
--==_Exmh_383835428P--
Received: from ietf.org by ietf.org id aa25391; 26 Feb 97 11:50 EST
Received: from mailgate22-hme0.a001.sprintmail.com by ietf.org id aa25289;
26 Feb 97 11:47 EST
Received: by mailgate22 (SMI-8.6/SMI-SVR4)
id IAA26897; Wed, 26 Feb 1997 08:45:19 -0800
Message-Id: <199702261645.IAA26897 at mailgate22>
Received: from sdn-ts-020mdrelrp13.dialsprint.net(206.133.13.48) by mailfep2-hme1 via smap (KC5.24)
id Q_10.1.1.6/Q_27061_1_3314689a; Wed Feb 26 08:45:14 1997
Sender:ietf-request at ietf.org
From: "Mark A. Mooney" <markmooney at sprintmail.com>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Remove
Date: Wed, 26 Feb 1997 11:44:03 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1160
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Remove markmooney at sprintmail.com
unsubscribe markmooney at sprintmail.com
Received: from ietf.org by ietf.org id aa27448; 26 Feb 97 12:21 EST
Received: from buster.lbl.gov by ietf.org id aa27311; 26 Feb 97 12:18 EST
Received: from [128.3.9.20] by cnrmail.lbl.gov
with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 26 Feb 1997 09:15:28 -0800
X-Sender: wright at cnrmail.lbl.gov
Message-Id: <v03101700af3a1ec9797f at [128.3.9.20]>
In-Reply-To: <199702261631.LAA32304 at black-ice.cc.vt.edu>
References: Your message of "Tue, 25 Feb 1997 16:58:42 PST."
<9702260058.AA13799 at lever.dr.lucent.com>
<9702260058.AA13799 at lever.dr.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 26 Feb 1997 09:15:26 -0800
To: Valdis.Kletnieks at vt.edu, Neal McBurnett <nealmcb at bell-labs.com>
Sender:ietf-request at ietf.org
From: Russ Wright <Wright at lbl.gov>
Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists
Cc: ietf at ietf.org, ids at merit.edu
Source-Info: From (or Sender) name not authenticated.
Thanks for the comments. If anyone else has suggestions perhaps we should
discuss on the ids at merit.edu list rather than the general ietf list.
To address this particular comment- I think Valdis is correct about
avoiding one alias. Having said that it was made pretty clear to me that
the IESG folks who reviewed this document don't want a long list of aliases
in the document.
Russ
At 8:31 AM -0800 2/26/97, Valdis.Kletnieks at vt.edu wrote:
>On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said:
>> The machines are frequently distinct from the "mail" machine
>> for a given organization because the operational characteristics
>> and requirements can be very different.
>>
>> I propose the alias "list" for the "mail list" service.
>> It is the most common generic name in the lists I subscribe to.
>> Are there common alternatives?
>
>Well.. actually, I suspect that in most cases, the machine name is
>either listserv.domain.xyz (for people running LSoft's software),
>or majordomo.domain.xyz, or listproc.domain.xyz (for those running
>the CREN list processor). I can't remember seeing a machine called
>list.domain.xyz, and I've been doing Listserv stuff since 1984 or so.
>Are you sure that your "the lists I subscribe to" isn't biased in some
>way (for instance, many of your lists are hosted in one domain, so
>that domain's preferences impact the names you see)?
>
>The command languages for these 3 products are sufficiently different
>that bundling them all under the same 'list' is probably a bad idea.
>
>
>--
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
Received: from ietf.org by ietf.org id aa28200; 26 Feb 97 12:33 EST
Received: from mail1.microsoft.com by ietf.org id aa28079; 26 Feb 97 12:30 EST
Received: by mail1.microsoft.com with Internet Mail Service (5.0.1457.3)
id <FWP7TAWC>; Wed, 26 Feb 1997 09:27:27 -0800
Message-ID: <503A2A3C2932CF118D8800805FD44E1802BBD755 at RED-68-MSG>
Sender:ietf-request at ietf.org
From: Eric Fleischman <ericfl at microsoft.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: don't shoot the messenger
Date: Wed, 26 Feb 1997 09:22:13 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Source-Info: From (or Sender) name not authenticated.
I see that you have now completed your move.
I have signed up for the next IETF. I am looking forward to seeing you.
-----Original Message-----
From: (Brian E Carpenter) [SMTP:brian at hursley.ibm.com]
Sent: Wednesday, February 26, 1997 5:21 AM
To: ietf at ietf.org
Subject: don't shoot the messenger
I hesitate to do this but for those of you that don't
receive the ISOC electronic newsletter, the following
snip
may be of interest.
"* SPAMMER LAUNCHES ISP FOR OTHER COMMERCIAL E-MAILERS
Cyber Promotions, Inc., best known for having been
kicked off of as many
as 20 different Internet Service Providers for sending
unsolicited e-
mail, has announced that it will become an Internet
Service Provider
itself. CPI plans to charge its customers $50 per month,
enabling them
to send unsolicited mass mailings -- referred to as
spams -- as long as
they allow users to remove themselves from such lists
and comply with
local, state, and federal laws. When asked why the
company had not
thought of this solution earlier, CPI president Sanford
Wallace said
that his company had been too busy with lawsuits.
(Cowles/SIMBA Media Daily 20 Feb 1997)"
Don't shoot the messenger :-)
Brian Carpenter
Received: from ietf.org by ietf.org id aa29219; 26 Feb 97 12:48 EST
Received: from hp.rz.uni-potsdam.de by ietf.org id aa29080; 26 Feb 97 12:45 EST
Received: from rz.uni-potsdam.de (persius.rz.uni-potsdam.de) by hp.rz.uni-potsdam.de with ESMTP
(1.37.109.10G/16.2) id AA240398742; Wed, 26 Feb 1997 18:39:02 +0100
Received: from jhartman.rz.uni-potsdam.de by rz.uni-potsdam.de (SMI-8.6/SMI-SVR4)
id SAA17892; Wed, 26 Feb 1997 18:39:50 +0100
Message-Id: <330B51C9.66BD at pobox.com>
Date: Wed, 19 Feb 1997 20:17:29 +0100
Sender:ietf-request at ietf.org
From: Joerg Hartmann <joerg.hartmann at pobox.com>
Reply-To: ecology at pobox.com
Organization: Oekologie & Innovationen
X-Sender: Joerg Hartmann <joerg.hartmann at pobox.com> (Unverified)
X-Mailer: Mozilla 4.0b1 (Win95; I)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: Re: New Ideas for a WWW standard (fwd)
X-Priority: Normal
References: <199702172128.NAA08323 at server.livingston.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Would you please stop this talk about plattforms, prefered proprietary
scripting/macro languages and so on?!!! This all does _not_ belong to
IETF.
--
Ecology & Innovations, mailto:ecology at pobox.com,
http://pobox.com/~ecology/
Hebbelstrasse 9, D-14469 Potsdam, Germany Phone: +49-(0)331-27092-15
P.O. Box 600844, D-14408 Potsdam Fax/3: +49-(0)331-27092-17
CEO + MD IT/OS Mr. Joerg Hartmann, mailto:joerg.hartmann at pobox.com,
http://pobox.com/~ecology/joerg.hartmann/
Received: from cnri by ietf.org id aa29636; 26 Feb 97 12:52 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa17517;
26 Feb 97 12:52 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id KAA29876 for telnet-ietf-list at bsdi.com; Wed, 26 Feb 1997 10:43:58 -0700 (MST)
Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id KAA29851 for <telnet-ietf at bsdi.com>; Wed, 26 Feb 1997 10:43:32 -0700 (MST)
Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4)
id SAA06207; Wed, 26 Feb 1997 18:44:53 +0100
Date: Wed, 26 Feb 1997 18:44:53 +0100
From: Sebastien Boving <seb at deis38.deis.unibo.it>
Message-Id: <199702261744.SAA06207 at deis38.deis.unibo.it.>
To: telnet-ietf at bsdi.com
Subject: long suboptions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: A0qSjvhHqFUikI85BtsM9g==
Hi,
I'm new on this list, and haven't seen any traffic since i'm following it.
I hope i'm not the onlyone out here.
I'm expanding the Oct 23, 1995 telnet source to make it work with
SESAME authentication (encryption will follow). SESAME uses a GSS-API,
for authentication the client sends a firts encrypted token, the server
checks this and sends his own authentication information back.
The problem is, the token leaves (as far as i can see with the debugging
options) the client ok, but the server always refuses the security token,
even if it shouldn't. The problem is that the token delivered to sesame_is()
(called on receipt of a IS) is much smaller than the actually sent token by
the client.
The server also makes this clear by stating:
td: recv suboption (terminated by TERMINAL TYPE 55, not IAC SE!) AUTHENTICATION
IS SESAME CLIENT|MUTUAL AUTH 96 130 (...)
Actually, the clients asks net_write to send a token of about 1500 bytes to
the server. The server receives this, but at about the 510th (512th?) byte
an IAC is inserted (at what point?), so it thinks the suboption is badly
terminated!
Still this IAC doesn't appear in str_data when the client is sending it!
What is going wrong? Why is this byte inserted in the stream?
TIA, and sorry if this is a stupid question...
Sebastien Boving.
(just another student)
Received: from ietf.org by ietf.org id aa00473; 26 Feb 97 13:08 EST
Received: from iggy.iwsc.com by ietf.org id aa00335; 26 Feb 97 13:06 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA214; Wed, 26 Feb 1997 10:08:50 -0800
Message-ID: <3314797F.36C at metacomm.com>
Date: Wed, 26 Feb 1997 09:57:19 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: "Theodore Y. Ts'o" <tytso at mit.edu>
CC: Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <9702261623.AA16627 at dcl.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Theodore Y. Ts'o wrote:
>
> Date: Wed, 26 Feb 1997 09:04:01 -0500
> From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
>
> I'd say: get all the spammers to sign up with one spam-only provider,
> find out what IP range they got and add a capability to sendmail to
> block that range. Unlike, say, netcom, you don't have to worry about
> blocking the mail of innocent bystanders.
>
> MIT has already put that feature (an access list for incoming IP
> addresses/subnets) in our sendmail hubs.....
>
> - Ted
To me this looks too much like censorship. I'll rather be my own
censor.
Branislav
Received: from ietf.org by ietf.org id aa01737; 26 Feb 97 13:26 EST
Received: from aleve.media.mit.edu by ietf.org id aa01438; 26 Feb 97 13:24 EST
Received: from ml.media.mit.edu (ml.media.mit.edu [18.85.13.107]) by media.mit.edu (8.7.5/ML961206) with SMTP id NAA31223 for <ietf at ietf.org>; Wed, 26 Feb 1997 13:21:42 -0500 (EST)
Received: from bad-taste.media.mit.edu by ml.media.mit.edu; (5.65v3.2/1.1.8.2/12Apr96-0443PM)
id AA08312; Wed, 26 Feb 1997 13:21:42 -0500
Date: Wed, 26 Feb 1997 13:21:37 -0500 (EST)
Sender:ietf-request at ietf.org
From: Roger WOJA Kermode <woja at media.mit.edu>
To: ietf at ietf.org
Subject: Re: 38th IETF Meeting...Hotel Gripe
Message-Id: <Pine.OSF.3.91.970226132106.27595D-100000 at bad-taste.media.mit.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
try these on your web browser......
ftp://ftp.ietf.org/ietf/0mtg-at-a-glance-97apr.txt
http://www.fodors.com/ir.cgi?dest=Memphis at 35&2=name
you can find out where the hotels are relative to the meeting site
using....
http://www.city.net/countries/united_states/tennessee/memphis/maps/
woja
Roger Kermode Research Assistant
woja at media.mit.edu tel : +1 617 253 0341
Entertainment & Information Systems Group fax : +1 617 258 6264
MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA
On Wed, 26 Feb 1997, T.P.Brisco wrote:
>
>
> Can someone post a handful of nearby hotels? The lady
> at registration wasn't much help ....
>
> Tom
>
> On Tue, 25 Feb 1997, Bill Flanigan wrote:
> > Hello Roger,
> >
> > Maybe you're lucky--well, sort of.
> >
> > After all, this is Memphis TN (not Memphis, Egypt or Mars) where
> > the going rates for hotels/motor inns/motels is in the $50-60
> > range--AAA, e.g., lists about 25 (with three-diamond ratings) in that
> > price range including a number within brisk-walking distance of the
> > Peabody.
>
>
>
Received: from cnri by ietf.org id aa02882; 26 Feb 97 13:46 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19180;
26 Feb 97 13:46 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id LAA03771 for telnet-ietf-list at bsdi.com; Wed, 26 Feb 1997 11:41:21 -0700 (MST)
Received: from forge.BSDI.COM (dab at forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id LAA03755; Wed, 26 Feb 1997 11:40:44 -0700 (MST)
Received: (from dab at localhost) by forge.BSDI.COM (8.8.2/8.7.3) id LAA05265; Wed, 26 Feb 1997 11:40:43 -0700 (MST)
Date: Wed, 26 Feb 1997 11:40:43 -0700 (MST)
From: David Borman <dab at bsdi.com>
Message-Id: <199702261840.LAA05265 at forge.BSDI.COM>
To: seb at deis38.deis.unibo.it, telnet-ietf at bsdi.com
Subject: Re: long suboptions
Sebastien,
> The problem is, the token leaves (as far as i can see with the debugging
> options) the client ok, but the server always refuses the security token,
> even if it shouldn't. The problem is that the token delivered to sesame_is()
> (called on receipt of a IS) is much smaller than the actually sent token by
> the client.
>
> The server also makes this clear by stating:
> td: recv suboption (terminated by TERMINAL TYPE 55, not IAC SE!) AUTHENTICATION
> IS SESAME CLIENT|MUTUAL AUTH 96 130 (...)
>
> Actually, the clients asks net_write to send a token of about 1500 bytes to
> the server. The server receives this, but at about the 510th (512th?) byte
> an IAC is inserted (at what point?), so it thinks the suboption is badly
> terminated!
> Still this IAC doesn't appear in str_data when the client is sending it!
The telnet server accumulates the suboption into a static circular buffer,
which is 512 bytes long. You say you are sending a token of 1500 bytes, so
it is going to wrap that buffer almost 3 times... In telnetd/state.c:
unsigned char subbuffer[512], *subpointer= subbuffer, *subend= subbuffer;
For the quick fix, make the buffer bigger.
-David Borman, dab at bsdi.com
Received: from ietf.org by ietf.org id aa04661; 26 Feb 97 14:07 EST
Received: from cnri by ietf.org id aa04582; 26 Feb 97 14:06 EST
Received: from po2.glue.umd.edu by CNRI.Reston.VA.US id aa19687;
26 Feb 97 14:06 EST
Received: from z.glue.umd.edu (tle at z.glue.umd.edu [128.8.10.71])
by po2.glue.umd.edu (8.8.5/8.8.5) with ESMTP id NAA02927;
Wed, 26 Feb 1997 13:55:53 -0500 (EST)
Received: from localhost (tle at localhost) by z.glue.umd.edu (8.8.5/8.7.3) with SMTP id NAA17128; Wed, 26 Feb 1997 13:55:44 -0500 (EST)
X-Authentication-Warning: z.glue.umd.edu: tle owned process doing -bs
Date: Wed, 26 Feb 1997 13:55:43 -0500 (EST)
Sender:ietf-request at ietf.org
From: Thao Le <tle at eng.umd.edu>
X-Sender: tle at z.glue.umd.edu
To: tccc at ieee.org
cc: vacets-tech at vacets.org
Subject: Call for Papers - Deadline for Submitting Abstracts/Summaries
Message-ID: <Pine.SOL.3.95.970226134556.16556A-100000 at z.glue.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Dear friends
The deadline for submitting abstracts/summaries for VTIC '97 will be the
end of this week (March 31, 1997). We would like to invite you to
submit your own summaries and urge your colleagues to do so.
We look forward to hearing from you and meeting you at VTIC '97.
Best regards,
Thao Le
-----------------------------
Vietnamese Association for
Computing, Engineering Technology and Science (VACETS)
http://www.saigon.com/~vacets
vacets-adcom at vacets.org
CALL FOR PAPERS
1997 VACETS Technical International Conference (VTIC-97)
vtic-tech at vacets.org
San Jose State University, San Jose, California
July 17 - 19, 1997
The second VACETS Technical International Conference will be held
on July 17 and 19, 1997 at San Jose State University, San Jose,
California. The theme of this year conference is "Key Technologies
for the Year 2000". We will focus on advances in 1997 pacing
technologies that we believe will become key technologies in the year
2000.
Instructions to Authors:
Prospective authors are invited to submit research and overview papers
in all engineering and computer, physical, medical and social sciences
disciplines for presentation and/or posting during the conference.
Original papers are solicited in, but are not limited to, the following
areas:
===========================================
(1) Biomedical and Bio-Chemistry Technology
(2) Robotics and Controls Technology
(3) Telecommunications Technology
(4) Computer Systems and Applications
(5) IC Design Technology
(6) Biometric Systems
(7) Energy and Environmental Technology
(8) Speech, Signal, Video, Image Processing Applications
(9) Material and Manufacturing Technologies
(10) Other Sciences, Engineering and Technologies
============================================
Students are encouraged to submit their papers. Accepted papers will
be printed in the conference proceedings under Student Paper Session.
There will be three student paper awards to be presented at the
conference.
Since the format of the conference allows a number of special topics
sessions or workshops to be held, proposals from participants willing
to organize special sessions on relevant topics are also welcomed. The
organizers will be responsible for inviting speakers to their special
sessions.
Schedule
- Submission of proposal for special sessions must be received by
December 15, 1996.
- Submission of one page summary must be received by March 1, 1997.
- Notification of acceptance by April 1, 1997.
- Final manuscripts (photoready papers) are due on May 15, 1997.
Summary Submission
Submission of one page text summary by e-mail to
vtic-tech at vacets.org
is requested. Small black and white illustrations, in pcx format (MS
Windows Paintbrush readable) can also be included in the file, provided
it has been pkzipped and uuencoded. An alternative is to send two
copies of the summary, with illustrations (but not the original
illustrations themselves) to the Technical Program Chair:
Dr. Tran Thong
Micro Systems Engineering, Inc.
6024 SW Jean Rd
Lake Oswego, OR 97035
Fax: 503 635-9610
1. The official language of the conference is English (both paper
and presentation). Vietnamese language submission is encouraged but an
English summary must be included.
2. Please indicate your preferences: oral or poster presentation.
3. The summary should include the name, address (both e-mail and postal)
and phone/fax number of the author(s).
4. Also, to simplify the review process, please indicate the primary
technical area covered by the paper, PLEASE INCLUDE THIS INFORMATION IN
THE SUBJECT LINE OF YOUR E-MAIL, for example: "VTIC-97 paper in
Robotics"
All questions regarding the format of the paper or the acceptance
status should be directed to the Technical Program Chair.
Dr. Tran Thong
Fax: 503 635-9610
E-Mail: trant at teleport.com
Technical Paper Format
Papers submitted will be reviewed by the Conference Proceedings
editorial staff for publication suitability. Editorial changes may be
made to meet technical proceedings publication standards.
1. Paper should be printed on both sides of 8.5 X 11 in (21.6 X 27.9 cm)
white sheets.
2. Begin with the title of the paper, name(s) of author(s), e-mail
address (if available), complete return address, telephone and fax
number.
3. A 10 to 15 lines abstract in "italic"
4. Use Word Processor: Microsoft Word 6.0 (or earlier readable version
or Word Perfect). Font: Arial 10. An alternative is to submit an Adobe
Acrobat pdf file.
5. Leave 1 in (2..54 cm) margin for each side, top and bottom of the
page.
6. Make one or two-column per page.
7. The paper length is limited to 8 pages. Indicate page number in blue
pencil.
8. Submit a 3.5" diskette in MS Word format for text, graphs, tables,
formulas, etc., and two hardcopies of the papers.
9. Mail the paper and diskette to the Technical Program Vice-Chair:
Dr. Thuy Trong Le
Supercomputer Group
Fujitsu America, Inc.
3055 Orchard Drive
San Jose, CA 95134-2022 USA
email: thuy at fujitsu.com
Received: from cnri by ietf.org id aa04696; 26 Feb 97 14:07 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa19732;
26 Feb 97 14:07 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id MAA05271 for telnet-ietf-list at bsdi.com; Wed, 26 Feb 1997 12:02:36 -0700 (MST)
Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id MAA05267; Wed, 26 Feb 1997 12:02:32 -0700 (MST)
Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4)
id UAA06368; Wed, 26 Feb 1997 20:05:16 +0100
Date: Wed, 26 Feb 1997 20:05:16 +0100
From: Sebastien Boving <seb at deis38.deis.unibo.it>
Message-Id: <199702261905.UAA06368 at deis38.deis.unibo.it.>
To: dab at bsdi.com, telnet-ietf at bsdi.com
Subject: Re: long suboptions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: 95ebp5TFIaWEIHBEP8IzsA==
> The telnet server accumulates the suboption into a static circular buffer,
> which is 512 bytes long. You say you are sending a token of 1500 bytes, so
> it is going to wrap that buffer almost 3 times... In telnetd/state.c:
>
> unsigned char subbuffer[512], *subpointer= subbuffer, *subend= subbuffer;
>
> For the quick fix, make the buffer bigger.
>
> -David Borman, dab at bsdi.com
>
That was the problem, it now works!
Thanks,
Sebastien.
Received: from ietf.org by ietf.org id aa06465; 26 Feb 97 14:33 EST
Received: from ietf.ietf.org by ietf.org id aa06055; 26 Feb 97 14:27 EST
To: IETF-Announce: ;
Subject: WG ACTION: The Internet and the millenium problem (2000)
Date: Wed, 26 Feb 1997 14:27:50 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9702261427.aa06055 at ietf.org>
A new working group has been formed in the Operational Requirements Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
The Internet and the millenium problem (2000)
---------------------------------------------
Chair(s):
Erik Huizer <Erik.Huizer at sec.nl>
Operational Requirements Area Director(s):
Scott Bradner <sob at harvard.edu>
Michael O'Dell <mo at uu.net>
Deirdre Kostick <kostick at qsun.att.com>
Area Advisor
Scott Bradner <sob at harvard.edu>
Mailing lists:
General Discussion:2000 at nic.surfnet.nl
To Subscribe: listserv at nic.surfnet.nl
In Body: subscribe 2000 <your name> in body
Archive:
Description of Working Group:
The Millenium problem
According to the trade press billions of dollars will be spend the
upcoming three years on the year 2000 problem, also called the
millenium problem (though the third millenium will only start in 2001).
This problem consists of the fact that many software packages and some
protocols use a two digit field for the year in a date field. Most of
the problems seem to be in administrative and financial programs, some
of which have been written in archaic languages like Cobol. A lot of
organizations are now starting to make an inventory of which software
and tools they use will suffer from the millenium problem.
....and the Internet
With the increasing popularity of the Internet,
more and more organizations start to use the Internet as a serious
business tool. This means that most organizations will want to analyse
the millenium problems due to the use of Internet protocols and popular
Internet software. In the trade press the first articles suggest that
the Internet will collapse at midnight the 31st of december 1999.
To counter these suggestions (that are obviously wrong) and to avoid
that all over the Internet people will redo the same inventory over and
over again the WG is to make an inventory of all important Internet
protocols and their most popular implementations with respect to the
millenium problem. Only software and protocols directly related to the
Internet will be considered.
The inventory will be published as an informational RFC. The RFC will
contain:
o Description of the year 2000 problems and when they will occur
o Summary of possible solutions and timelines for those solutions
o Inventory of the year 2000 problem in the most popular Internet
protocols and their most popular implementations
o Suggested solutions to the problems noted in the inventory
o A disclaimer that the RFC does not pretend to be complete and that
the proposed solutions should be tested before being relied upon (this
for the US readers).
The WG will only meet once (in Memphis, April 1997), most of the work
will be done via the mailinglist.
Goals and Milestones:
Feb 97 Begin collecting inventory.
Sep 97 Submit Internet-Draft to IESG for publication as an
Informational RFC.
Received: from ietf.org by ietf.org id aa06462; 26 Feb 97 14:33 EST
Received: from ietf.ietf.org by ietf.org id aa06045; 26 Feb 97 14:27 EST
To: IETF-Announce: ;
Subject: WG ACTION: Secure Shell (secsh)
Date: Wed, 26 Feb 1997 14:27:48 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9702261427.aa06045 at ietf.org>
A new working group has been formed in the Security Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
Secure Shell (secsh)
--------------------
Chair(s):
Perry Metzger <perry at piermont.com>
Security Area Director(s):
Jeffrey Schiller <jis at mit.edu>
Mailing lists:
General Discussion:ietf-ssh at clinet.fi
To Subscribe: majordomo at clinet.fi
In Body: subscribe ietf-ssh at clinet.fi in body
Archive:
Description of Working Group:
The goal of the working group is to update and standardize the popular
SSH protocol. SSH provides support for secure remote login, secure file
transfer, and secure TCP/IP and X11 forwardings. It can automatically
encrypt, authenticate, and compress transmitted data. The working
group will attempt to assure that the SSH protocol
o provides strong security against cryptanalysis and protocol attacks,
o can work reasonably well without a global key management or
certificate infrastructure,
o can utilize existing certificate infrastructures (e.g., DNSSEC,
SPKI, X.509) when available,
o can be made easy to deploy and take into use,
o requires minimum or no manual interaction from users,
o is reasonably clean and simple to implement.
The resulting protocol will operate over TCP/IP or other reliable but
insecure transport. It is intended to be implemented at the application
level.
Goals and Milestones:
Feb 97 Submit Internet-Draft on SSH-2.0 protocol
Apr 97 Decide on Transport Layer protocol at Memphis IETF.
Aug 97 Finalize upper level protocols at Munich IETF.
Sep 97 Submit Internet-Drafts to IESG to consider for publication as
RFCs.
Dec 97 Meet at DC IETF meeting.
Received: from ietf.org by ietf.org id aa08275; 26 Feb 97 15:06 EST
Received: from box.nl by ietf.org id aa08191; 26 Feb 97 15:04 EST
Received: from cs-gj3-a7.hro.nl (cs-gj3-a7.hro.nl [145.24.129.139]) by box.nl (8.7.5/8.6.9) with SMTP id VAA15386; Wed, 26 Feb 1997 21:01:28 +0100
Date: Wed, 26 Feb 1997 21:01:28 +0100
Message-Id: <199702262001.VAA15386 at box.nl>
X-Sender: unit at box.nl
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ecology at pobox.com
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: Re: New Ideas for a WWW standard (fwd)
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 20:17 19-02-97 +0100, you wrote:
>Would you please stop this talk about plattforms, prefered proprietary
>scripting/macro languages and so on?!!! This all does _not_ belong to
>IETF.
>
I realize that the topic does not per se belong to the IETF list. But if
you had read the document referenced you would have discovered the reasons I
posted to the IETF. Further, judging from the discussion that ensued, it
seems that the topic struck the interest of many who subsribe to the list.
Please see the original document as well as the comments at:
http://www.box.nl/~unit/mike/prop.htm
-michael_roetto
>
>
::::::::::::::::::::::::::::::::::::
Internet Design Unit
http://www.box.nl/~unit/idu
Personal Page:
http://www.box.nl/~unit/mike
::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa13226; 26 Feb 97 16:04 EST
Received: from ietf.ietf.org by ietf.org id aa12642; 26 Feb 97 15:59 EST
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: FTP Security Extensions to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Feb 1997 15:59:25 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702261559.aa12642 at ietf.org>
The IESG has received a request from the Common Authentication Technology
Working Group to consider "FTP Security Extensions"
<draft-ietf-cat-ftpsec-09.txt> for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 12, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa14782; 26 Feb 97 16:24 EST
Received: from ietf.ietf.org by ietf.org id aa14605; 26 Feb 97 16:20 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP4 Referrals to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Feb 1997 16:20:43 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702261620.aa14605 at ietf.org>
The IESG has received a request to consider IMAP4 Referrals
<draft-gahrns-imap-referrals-01.txt> as a Proposed Standard. This has
been reviewed in the IETF but is not the product of an IETF Working
Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 26, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa20552; 26 Feb 97 17:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27668;
26 Feb 97 17:47 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA21493 at pad-thai.cam.ov.com>; Wed, 26 Feb 1997 20:57:51 GMT
Message-Id: <199702262057.PAA17090 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Memphis agenda and discussion solicitation
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 26 Feb 1997 15:57:45 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT-WG members:
The level of discussion on the list has been relatively quiet lately,
and we have one meeting slot assigned for the Memphis IETF. I'd like
to invite all members to initiate and pursue discussions of WG-related
topics, and would like at this time to solicit requests for agenda
time in order that the slot may be used most effectively towards closure
and advancement of active and pending documents.
Thanks, regards, ...
--jl
Received: from cnri by ietf.org id aa06457; 27 Feb 97 2:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03844;
27 Feb 97 2:37 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <GAA10832 at pad-thai.cam.ov.com>; Thu, 27 Feb 1997 06:00:50 GMT
Message-Id: <199702270600.BAB20132 at ig.cs.utk.edu>
To: ftp-wg at hops.ag.utk.edu
Cc: cat-ietf at mit.edu
Subject: [fwd] Last Call: FTP Security Extensions to Proposed Standard
Date: Thu, 27 Feb 1997 01:00:38 -0500
From: Keith Moore <moore at cs.utk.edu>
Precedence: bulk
FTP extensions WG people:
The CAT WG has developed a proposal for security extensions for
FTP, and asked IESG that it be considered for Proposed Standard.
In accordance with the FTPEXT WG charter, which directs it to
review and make recommendations on proposed security extensions
to FTP, I hereby request that the FTPEXT review this document
and make appropriate recommendations. Individuals may of course
submit their own comments independent of the working group.
Note: while the FTPEXT group may of course discuss this proposal on
its mailing list, any recommendations (from either the working group or
individuals) on this proposal should be sent to ietf at ietf.org or
iesg at ietf.org before March 12.
Keith Moore
co-Director, Applications Area
IESG
------- Forwarded Message
To: IETF-Announce:;
cc: cat-ietf at mit.edu
Sender: ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: FTP Security Extensions to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Feb 1997 15:59:25 -0500
Message-ID: <9702261559.aa12642 at ietf.org>
The IESG has received a request from the Common Authentication Technology
Working Group to consider "FTP Security Extensions"
<draft-ietf-cat-ftpsec-09.txt> for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 12, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa09157; 27 Feb 97 5:36 EST
Received: from ibmmail.com by ietf.org id aa08867; 27 Feb 97 5:26 EST
Received: from uk.ibm.com by ibmmail.COM (IBM VM SMTP V2R3) with BSMTP id 3826;
Thu, 27 Feb 97 05:23:56 EST
Date: Thu, 27 Feb 1997 05:23:58 EST
Sender:ietf-request at ietf.org
From: pfh at uk.ibm.com
To: cat-ietf at mit.edu, ftp-wg at hops.ag.utk.edu, ietf at ietf.org
X-Sender-Info: Paul Ford-Hutchinson
Classification: -- NONE --
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: draft-ietf-cat-ftpsec-09.txt
Message-ID: <9702270526.aa08867 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Two comments
- The length of time that PROT is valid for is not specified - is it
per data connection; is it cleared with a new AUTH/USER/ ... ...
(I guess the latter, but I don't think it can be an implementation
decision)
- Can PBSZ 0 please define a 'streaming' encryption mechanism (like
TLS (SSL)). This allows us to use this draft to negotiate TLS (with
AUTH and PROT) but then all the stuff about encapsulating the data
channel isn't relevant, as that is done for you by TLS.
So, if 'PBSZ 0' meant
- O.K. then you can send a PROT, and the data stream will be
encrypted for you (the ftp application) lower down, so
it will appear to you as a 'normal' unencapsulated data
connection.
Cheers,
Paul
-.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.-
Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL)
IGN EDI Products Development and Support. (pfh at uk.ibm.com)
Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836
Received: from cnri by ietf.org id aa10884; 27 Feb 97 6:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07725;
27 Feb 97 6:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <KAA16401 at pad-thai.cam.ov.com>; Thu, 27 Feb 1997 10:24:54 GMT
Message-Id: <9702271024.AA08280 at MIT.EDU>
Date: Thu, 27 Feb 1997 05:24:44 EST
From: pfh at uk.ibm.com
To: cat-ietf at mit.edu, ftp-wg at hops.ag.utk.edu, ietf at ietf.org
X-Sender-Info: Paul Ford-Hutchinson
Classification: -- NONE --
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: draft-ietf-cat-ftpsec-09.txt
Precedence: bulk
Two comments
- The length of time that PROT is valid for is not specified - is it
per data connection; is it cleared with a new AUTH/USER/ ... ...
(I guess the latter, but I don't think it can be an implementation
decision)
- Can PBSZ 0 please define a 'streaming' encryption mechanism (like
TLS (SSL)). This allows us to use this draft to negotiate TLS (with
AUTH and PROT) but then all the stuff about encapsulating the data
channel isn't relevant, as that is done for you by TLS.
So, if 'PBSZ 0' meant
- O.K. then you can send a PROT, and the data stream will be
encrypted for you (the ftp application) lower down, so
it will appear to you as a 'normal' unencapsulated data
connection.
Cheers,
Paul
-.--.---.----.-----.----.---.--.--.---.----.-----.----.---.--.-
Paul Ford-Hutchinson FORDHUP @ NHBVM9 (GBIBMLLL @ IBMMAIL)
IGN EDI Products Development and Support. (pfh at uk.ibm.com)
Warwick (OSU-1) +44 (0)1926 464836 : tie (7)66 4836
Received: from ietf.org by ietf.org id aa13732; 27 Feb 97 9:06 EST
Received: from unlinfo.unl.edu by ietf.org id aa13568; 27 Feb 97 9:02 EST
Received: from unlinfo2.unl.edu by unlinfo.unl.edu (4.1/SMI-4.1)
id AA02935; Thu, 27 Feb 97 07:59:42 CST
Received: by unlinfo2.unl.edu (4.1/SMI-4.1)
id AA00614; Thu, 27 Feb 97 07:59:38 CST
Date: Thu, 27 Feb 1997 07:59:37 -0600 (CST)
Sender:ietf-request at ietf.org
From: thomas keller <tkeller at unlinfo2.unl.edu>
Subject: Re: don't shoot the messenger
To: Branislav Meandzija <bran at metacomm.com>
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
In-Reply-To: <3314797F.36C at metacomm.com>
Message-Id: <Pine.3.89.9702270719.A354-0100000 at unlinfo2.unl.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 26 Feb 1997, Branislav Meandzija wrote:
> Theodore Y. Ts'o wrote:
> > Date: Wed, 26 Feb 1997 09:04:01 -0500
> > From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
> > I'd say: get all the spammers to sign up with one spam-only provider,
> > find out what IP range they got and add a capability to sendmail to
> > block that range. Unlike, say, netcom, you don't have to worry about
> > blocking the mail of innocent bystanders.
>>> MIT has already put that feature (an access list for incoming IP
>>> addresses/subnets) in our sendmail hubs.....
>>>> To me this looks too much like censorship. I'll rather be my own
>>>> censor.
Censorship? Hardly. Spamming of this nature imposes a large and
expensive load on the hosts of every system on the spam list. Why do you
think that those who are paying the costs should subsidize this unsavory
and unethical practice?
Received: from ietf.org by ietf.org id aa14818; 27 Feb 97 9:32 EST
Received: from hail.ncr.disa.mil by ietf.org id aa14751; 27 Feb 97 9:30 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id JAA07136; Thu, 27 Feb 1997 09:26:24 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857064429; Thu, 27 Feb 97 09:25:31 EST
Date: Thu, 27 Feb 97 09:25:31 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9701278570.AA857064429 at ncr.disa.mil>
To: "T.P.Brisco" <brisco at iconnet.net>
Cc: ietf at ietf.org, woja at media.mit.edu, flanigab at ncr.disa.mil
Subject: Re[2]: 38th IETF Meeting...Hotel Gripe
Source-Info: From (or Sender) name not authenticated.
Hello Tom,
1. Recommend you get the AAA Tour Book for Tennessee--it list and rates
about forty in "Greater "Memphis."
2. List for downtown (all have 901 area code):
a. Best Western (two diamonds) 948-9005;
b. Comfort Inn (three) 526-0583;
c. Days Inn (two) 527-4100;
d. Holiday Inn (three) 527-7300;
e. Another Holiday Inn (three) 525-5491; and
f. Radison (three) 528-1800.
3. Rack rates for the above range from $50 to $109 before AAA (or
other) discounts.
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: 38th IETF Meeting...Hotel Gripe
Author: "T.P.Brisco" <brisco at IConNet.NET> at smtp
Date: 2/26/97 11:11 AM
Can someone post a handful of nearby hotels? The lady
at registration wasn't much help ....
Tom
On Tue, 25 Feb 1997, Bill Flanigan wrote:
> Hello Roger,
>
> Maybe you're lucky--well, sort of.
>
> After all, this is Memphis TN (not Memphis, Egypt or Mars) where
> the going rates for hotels/motor inns/motels is in the $50-60
> range--AAA, e.g., lists about 25 (with three-diamond ratings) in that
> price range including a number within brisk-walking distance of the
> Peabody.
Received: from ietf.org by ietf.org id aa15364; 27 Feb 97 9:42 EST
Received: from hail.ncr.disa.mil by ietf.org id aa15280; 27 Feb 97 9:40 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id JAA07432; Thu, 27 Feb 1997 09:36:39 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857065038; Thu, 27 Feb 97 09:35:49 EST
Date: Thu, 27 Feb 97 09:35:49 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9701278570.AA857065038 at ncr.disa.mil>
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: ietf at ietf.org, woja at media.mit.edu, flanigab at ncr.disa.mil
Subject: Re[2]: 38th IETF Meeting...Hotel Gripe
Source-Info: From (or Sender) name not authenticated.
Hello Ted,
Here a few other things you might want to ponder:
1. When I've negotiated with "four star" downtown hotels (BTW, my
team always includes a lawyer), the issue usually boils down to
how many room will I guarantee for how many night at a specific
rate to get the number of meeting rooms I need FOR FREE.
2. Let's assume that 2,000 IETFers pay to attend (and show up) at
an average of $270 a head. This yields $540K. Let's also assume that
the cost of the food and beverages is $5.00 per day per person for 4.5
days plus $20.00 per person for the cash-bar reception. This totals
$85K. Net profit, therefore, is $540K less $85K or $455K. This
represents a "surplus fee" of $228 paid by each attendee. Any idea
where this money ends up? I have some.
3. Let's further assume that the lowest below-the-rack-rate that
the Peaboy will go for (which I doubt is really the case) to make
their profit target is ($119 +129)/2 + $119, or $124. If attendees
pay a registration fee of $270 less $228 or $42, this allows them to
effectively stay at the Peaboy for five nights at $74 per night ($124
less $228/5). Now the Peabody's rates suddenly become not so
outrageous.
Best regards,
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: 38th IETF Meeting...Hotel Gripe
Author: "Theodore Y. Ts'o" <tytso at MIT.EDU> at smtp
Date: 2/26/97 11:26 AM
Date: Tue, 25 Feb 97 17:39:20 EST
From: Bill Flanigan <flanigab at ncr.disa.mil>
Naturally, this can't help, but make me a bit curious about who (if
anyone) is seriously negotiating these rates, and what criteria (if
any) are being used?
IETF attendance is now so large that advance-booking guarantees to
completely fill many hotels in an area (even a year in advance) is
virtually riskless. This should put the IETF hotel-booking folks
firmly in the driver's seat as far as getting the lowest possible room
rate in the meeting hotel and others in the area.
Actually, we have a similar problem to USENIX. The number of meeting
and breakout rooms that we need is extremely small compared to the
number of attendees we have (read: number of paying hotel rooms). Thus,
the number of sites where we can meet are quite limited.
This does make me wonder why there were so few rooms reserved at the
IETF block rate, though. Unless the hotel was hoping that enough other
people would pay the full rate after the IETF block was exhausted,
instead of staying at the $50-$60 motel that's 1/4 mile away....
- Ted
Received: from ietf.org by ietf.org id aa16542; 27 Feb 97 9:59 EST
Received: from www.atr.net by ietf.org id aa16349; 27 Feb 97 9:57 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id wa000230 for <ietf at ietf.org>; Thu, 27 Feb 1997 12:00:20 +0000
Message-ID: <3315BDA4.6789 at atr.net>
Date: Thu, 27 Feb 1997 12:00:20 -0500
Sender:ietf-request at ietf.org
From: Turner W Rentz III <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advance Technology and research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: A legal argument against SPAM
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at warp.atr.net
Source-Info: From (or Sender) name not authenticated.
My math teacher once told me
"you've got to learn to talk like a lawyer."
Here's an armchair law student's proof that
spamming is against the law in the State of
Oregon.
1. Unsolicited (marketing) telephone calls are against the law.
2. The wording of the law refers to these calls as 'communication by
telephony'
3. Email accessed by modem is 'communication by telephony'.
Therefore, unsolicited (marketing) email received over a modem is
against the law. Spam is unsolicited email sent over a modem. Therefore,
Spam is against the law. Q.E.D.
A precedent can be set in this state, with others to follow.
Telemarketing is not against the law everywhere, unfortunately :(
Received: from ietf.org by ietf.org id aa16966; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16205; 27 Feb 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-klyne-addressing-00.txt
Date: Thu, 27 Feb 1997 09:56:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16205 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : E-mail addressing: the worst of all worlds?
Author(s) : G. Klyne
Filename : draft-klyne-addressing-00.txt
Pages : 5
Date : 02/26/1997
This memo is a critique of Internet e-mail addressing, with particular
reference to its suitability for use in a general purpose interpersonal
communication medium as opposed to its present use largely within a
restricted community.
The critique focusses on the differences between e-mail addresses
and other forms of addressing with which very many lay people are
intimately familiar.
This memo does not offer any solutions to the issues raised; rather
it is hoped to provoke some debate on the matter. The author would be
particularly interested in views from those whose natural language
does not use the Roman (western) alphabet.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-klyne-addressing-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-klyne-addressing-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-klyne-addressing-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970226093439.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-klyne-addressing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-klyne-addressing-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226093439.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16970; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16238; 27 Feb 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kwan-proxy-client-conf-00.txt
Date: Thu, 27 Feb 1997 09:56:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16238 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DHCP Option for Proxy Client Configuration File
Author(s) : S. Kwan
Filename : draft-kwan-proxy-client-conf-00.txt
Pages : 3
Date : 02/26/1997
Application-level gateways are used on networks to provide controlled
access to the Internet. Clients in those networks must be configured
with the name or address of available proxy servers, the list of local
domain names, and other proxy client configuration information before
they can access the Internet. The defacto method of proxy client
configuration is the download of a script or configuration file
named by a URL. This document describes a DHCP option in which to
transmit this URL to a proxy client.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kwan-proxy-client-conf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kwan-proxy-client-conf-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kwan-proxy-client-conf-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970226102558.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kwan-proxy-client-conf-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kwan-proxy-client-conf-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226102558.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16974; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16279; 27 Feb 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rmonmib at cisco.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rmonmib-hcrmon-00.txt
Date: Thu, 27 Feb 1997 09:56:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16279 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote Network Monitoring
Working Group of the IETF.
Title : Remote Network Monitoring Management Information Base
for High Capacity and Switched Networks
Author(s) : S. Waldbusser
Filename : draft-ietf-rmonmib-hcrmon-00.txt
Pages : 43
Date : 02/26/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmonmib-hcrmon-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rmonmib-hcrmon-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rmonmib-hcrmon-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970226174200.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmonmib-hcrmon-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmonmib-hcrmon-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226174200.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16969; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16254; 27 Feb 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-durand-gse+-00.txt
Date: Thu, 27 Feb 1997 09:56:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16254 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : GSE+ - An Alternate Addressing Architecture to GSE
Author(s) : A. Durand
Filename : draft-durand-gse+-00.txt
Pages : 3
Date : 02/26/1997
This document present an alternative addressing architecture to the GSE
proposal (draft-ipng-gseaddr-00.txt) of Mike O'Dell. The basic change is
the introduction of a site identifier in the ESD.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-durand-gse+-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-durand-gse+-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-durand-gse+-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970226105118.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-durand-gse+-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-durand-gse+-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226105118.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa16971; 27 Feb 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa16222; 27 Feb 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-slein-www-dist-author-00.txt
Date: Thu, 27 Feb 1997 09:56:04 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9702270956.aa16222 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for Distributed Authoring and Versioning on
the World Wide Web
Author(s) : J. Slein, F. Vitali, J. Whitehead, D. Durand
Filename : draft-slein-www-dist-author-00.txt
Pages : 17
Date : 02/26/1997
Current World Wide Web (WWW or Web) standards provide simple support for
applications which allow remote editing of typed data. In practice, the
existing capabilities of the WWW have proven inadequate to support
efficient, scalable remote editing free of overwriting conflicts. This
document presents a list of features in the form of requirements which, if
implemented, would improve the efficiency of common remote editing
operations, provide a locking mechanism to prevent overwrite conflicts,
improve relationship management support between non-HTML data types,
provide a simple attribute-value metadata facility, provide for the
creation and reading of container data types, and integrate versioning
into the WWW.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-slein-www-dist-author-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-slein-www-dist-author-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-slein-www-dist-author-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970226104148.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-slein-www-dist-author-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-slein-www-dist-author-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970226104148.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25510; 27 Feb 97 11:21 EST
Received: from mailhost.worldnet.att.net by ietf.org id aa25194;
27 Feb 97 11:17 EST
Received: from LOCALNAME ([207.146.160.192]) by mtigwc02.worldnet.att.net
(post.office MTA v2.0 0613 ) with SMTP id AAA2962
for <ietf at ietf.org>; Thu, 27 Feb 1997 16:14:43 +0000
X-Sender: PJJ.PC at postoffice.worldnet.att.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: PJJ.PC at worldnet.att.net
Subject: Remove us from the mailing list
Date: Thu, 27 Feb 1997 16:14:43 +0000
Message-ID: <19970227161441.AAA2962 at LOCALNAME>
Source-Info: From (or Sender) name not authenticated.
To whom it may concern,
We are a law firm in Chicago. Somehow you have managed to get us on
a mailing list for some organization we do not belong to. We are now
receiving at least 20 messages a day with information nobody has any use
for. Please remove us form this list as soon as you receive this message.
If this is not the correct adress for which I can talk to about removing us
form the list can you please refer me to it.
Thank You
Ms. SMH
for PJJ.PC
Received: from ietf.org by ietf.org id aa00532; 27 Feb 97 12:55 EST
Received: from icicle.winternet.com by ietf.org id aa00404; 27 Feb 97 12:51 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id LAA19787 for <ietf at ietf.org>; Thu, 27 Feb 1997 11:49:17 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 11:49:17 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma019770; Thu, 27 Feb 97 11:48:59 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id da000081 for <ietf at ietf.org>; Thu, 27 Feb 1997 11:57:22 +0000
Received: by localhost with Microsoft Mail
id <01BC24A5.634B6320 at localhost>; Thu, 27 Feb 1997 11:57:21 -0600
Message-ID: <01BC24A5.634B6320 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Date: Thu, 27 Feb 1997 11:16:32 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
Someone please remove me from this list
Thanks
Received: from ietf.org by ietf.org id aa00879; 27 Feb 97 13:02 EST
Received: from black-ice.gateway.com by ietf.org id aa00714; 27 Feb 97 13:00 EST
Received: from localhost (abc at localhost) by station1.firehouse.net (8.8.4/Not quite) with SMTP id MAA01163 for <ietf at ietf.org>; Thu, 27 Feb 1997 12:57:31 -0500 (EST)
Date: Thu, 27 Feb 1997 12:57:30 -0500 (EST)
Sender:ietf-request at ietf.org
From: Alan Clegg <abc at firehouse.net>
To: ietf at ietf.org
Subject: Revelation caused by [Re: Remove us from the mailing list]
In-Reply-To: <19970227161441.AAA2962 at LOCALNAME>
Message-ID: <Pine.BSI.3.95.970227125418.1096A-100000 at station1.firehouse.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997 PJJ.PC at worldnet.att.net wrote:
> We are now
>receiving at least 20 messages a day with information nobody has any use
>for.
Oddly enough, this boils right down to the problem at the heart of the
Internet these days, does it not?
-abc
|
The Internet is not for sissies. [paul at vix.com] | Alan Clegg
|
Received: from ietf.org by ietf.org id aa00882; 27 Feb 97 13:02 EST
Received: from iggy.iwsc.com by ietf.org id aa00760; 27 Feb 97 13:00 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA252; Thu, 27 Feb 1997 10:03:03 -0800
Message-ID: <3315C996.1186 at metacomm.com>
Date: Thu, 27 Feb 1997 09:51:18 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: thomas keller <tkeller at unlinfo2.unl.edu>
CC: "Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <Pine.3.89.9702270719.A354-0100000 at unlinfo2.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
thomas keller wrote:
>
> On Wed, 26 Feb 1997, Branislav Meandzija wrote:
> > Theodore Y. Ts'o wrote:
> > > Date: Wed, 26 Feb 1997 09:04:01 -0500
> > > From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
> > > I'd say: get all the spammers to sign up with one spam-only provider,
> > > find out what IP range they got and add a capability to sendmail to
> > > block that range. Unlike, say, netcom, you don't have to worry about
> > > blocking the mail of innocent bystanders.
> >>> MIT has already put that feature (an access list for incoming IP
> >>> addresses/subnets) in our sendmail hubs.....
> >>>> To me this looks too much like censorship. I'll rather be my own
> >>>> censor.
>
> Censorship? Hardly. Spamming of this nature imposes a large and
> expensive load on the hosts of every system on the spam list. Why do you
> think that those who are paying the costs should subsidize this unsavory
> and unethical practice?
They shouldn't but neither should anybody without the recipient's
explicit permission cut the recipient off from a part of the wild, wild,
west. For example, do all the people at MIT know that Theodore Y. is
cutting them off from whoever the suspected (remember, in dubio pro rei,
I belive) spammers are.
Branislav
Received: from ietf.org by ietf.org id aa07617; 27 Feb 97 15:29 EST
Received: from apprentice.qualcomm.com by ietf.org id aa07471;
27 Feb 97 15:24 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA25654; Thu, 27 Feb 1997 12:22:32 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0310170faf3b9b02d74c at [129.46.166.223]>
In-Reply-To: <3315BDA4.6789 at atr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 12:15:04 -0800
To: treyr at atr.net
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: A legal argument against SPAM
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 12:00 PM -0500 2/27/97, Turner W Rentz III wrote:
>My math teacher once told me
>"you've got to learn to talk like a lawyer."
>
>
>Here's an armchair law student's proof that
>spamming is against the law in the State of
>Oregon.
>
So somebody in Oregon want to haul Cyber Promotions into court to see if
this stands up?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa08347; 27 Feb 97 15:48 EST
Received: from callandor.cybercash.com by ietf.org id aa08262;
27 Feb 97 15:46 EST
Received: by callandor.cybercash.com; id PAA11988; Thu, 27 Feb 1997 15:34:18 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma011963; Thu, 27 Feb 97 15:33:52 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA14572; Thu, 27 Feb 97 15:39:37 EST
Date: Thu, 27 Feb 1997 15:39:36 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
Message-Id: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hi,
Forging people's names on subscriptions to mailing lists is becoming a daily
occurance. Spamming is becoming an hourly occurance.
The IETF list needs stronger control than it apparently has. For example:
at a minimum, only allow posting from people on the list (or on a separate
list you maintain so people who post from multiple addresses don't have too
much inconvenience) and no one should be added to the list unless at least an
email loop confirmation occurs where you send mail asking for a confirmation
of the subscritpion request and get back a postitive response from the
subscription address.
I'm not saying such measures will eliminate all problems, but I think
they will help a lot.
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
---------- Forwarded message ----------
Date: Thu, 27 Feb 1997 16:14:43 +0000
From: PJJ.PC at worldnet.att.net
To: ietf at ietf.org
Subject: Remove us from the mailing list
To whom it may concern,
We are a law firm in Chicago. Somehow you have managed to get us on
a mailing list for some organization we do not belong to. We are now
receiving at least 20 messages a day with information nobody has any use
for. Please remove us form this list as soon as you receive this message.
If this is not the correct adress for which I can talk to about removing us
form the list can you please refer me to it.
Thank You
Ms. SMH
for PJJ.PC
Received: from ietf.org by ietf.org id aa08970; 27 Feb 97 15:58 EST
Received: from lynx.europe.shiva.com by ietf.org id aa08693; 27 Feb 97 15:56 EST
Received: from chryses.europe.shiva.com (chryses.europe.shiva.com [89.0.0.223])
by lynx.europe.shiva.com (8.8.5/8.8.5) with ESMTP id UAA13709;
Thu, 27 Feb 1997 20:53:38 GMT
Received: from black.europe.shiva.com (black.europe.shiva.com [134.191.8.140])
by chryses.europe.shiva.com (8.8.5/8.8.5) with SMTP id UAA09014;
Thu, 27 Feb 1997 20:53:37 GMT
Received: from localhost by black.europe.shiva.com (SMI-8.6/SMI-SVR4)
id UAA11465; Thu, 27 Feb 1997 20:53:37 GMT
Date: Thu, 27 Feb 1997 20:53:36 +0000 (GMT)
Sender:ietf-request at ietf.org
From: Malcolm Campbell <malcolmc at europe.shiva.com>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: treyr at atr.net, ietf at ietf.org
Subject: Re: A legal argument against SPAM
In-Reply-To: <v0310170faf3b9b02d74c at [129.46.166.223]>
Message-ID: <Pine.GSO.3.95.970227205133.11463A-100000 at black.europe.shiva.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997, John W. Noerenberg wrote:
> So somebody in Oregon want to haul Cyber Promotions into court to see if
> this stands up?
I havent a clue about US law, being neither American, nor a lawyer - but
someone sent me this as a suggested reply to junk mailers...
----
Under USC 47 Sec.227(b)(1)(C):
"It shall be unlawful for any person within the United States to
use any telephone facsimile machine, computer, or other device
to send an unsolicited advertisement to a telephone facsimile
machine"
where a "telephone facsimile machine" is defined in Sec.227(a)(2)(B) as:
"equipment which has the capacity to transcribe text or images
(or both) from an electronic signal received over a regular
telephone line onto paper."
Note that under this definition, my e-mail account, modem, computer
and printer constitute a fax machine.
Under Sec.227(b)(3)(B):
"A person or entity may, if otherwise permitted by the laws or
rules of court of a State, bring in an appropriate court of
that State -
(A) an action based on a violation of this subsection or the
regulations prescribed under this subsection to enjoin
such violation,
(B) an action to recover for actual monetary loss from such a
violation, or to receive $500 in damages for each such
violation, whichever is greater, or
(C) both such actions. If the court finds that the defendant
willfully or knowingly violated this subsection or the
regulations prescribed under this subsection, the court
may, in its discretion, increase the amount of the award
to an amount equal to not more than 3 times the amount
available under subparagraph (B) of this paragraph."
Received: from ietf.org by ietf.org id aa08969; 27 Feb 97 15:58 EST
Received: from apprentice.qualcomm.com by ietf.org id aa08748;
27 Feb 97 15:56 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA29998; Thu, 27 Feb 1997 12:53:45 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03101711af3b9c9535ec at [129.46.166.223]>
In-Reply-To: <Pine.3.89.9702270719.A354-0100000 at unlinfo2.unl.edu>
References: <3314797F.36C at metacomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 12:32:54 -0800
To: thomas keller <tkeller at unlinfo2.unl.edu>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: don't shoot the messenger
Cc: Branislav Meandzija <bran at metacomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 7:59 AM -0600 2/27/97, thomas keller wrote:
>On Wed, 26 Feb 1997, Branislav Meandzija wrote:
>> Theodore Y. Ts'o wrote:
>> > Date: Wed, 26 Feb 1997 09:04:01 -0500
>>>> MIT has already put that feature (an access list for incoming IP
>>>> addresses/subnets) in our sendmail hubs.....
>>>>> To me this looks too much like censorship. I'll rather be my own
>>>>> censor.
>
> Censorship? Hardly. Spamming of this nature imposes a large and
>expensive load on the hosts of every system on the spam list. Why do you
>think that those who are paying the costs should subsidize this unsavory
>and unethical practice?
But, Tom, by what rule can you say this is unsavory and unethical? Where
is the privileged position that enables you (or anyone else) to impose the
judgement this is morally unjustified?
I find the idea of a suit intriguing, because a judgement against Cyber
Promotions would say their practice is socially unacceptable. But that's
different than imposing a moral choice.
Personally, I agree with Branislav. But...
We don't do morals, and we don't do social conventions. We do technology here.
What is the proof that spamming necessarily imposes a large and expensive
load on the hosts involved?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa10550; 27 Feb 97 16:24 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa10320; 27 Feb 97 16:22 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id QAA29514;
Thu, 27 Feb 1997 16:19:30 -0500
Message-Id: <199702272119.QAA29514 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Malcolm Campbell <malcolmc at europe.shiva.com>
Cc: "John W. Noerenberg" <jwn2 at qualcomm.com>, treyr at atr.net, ietf at ietf.org
Subject: Re: A legal argument against SPAM
In-Reply-To: Your message of "Thu, 27 Feb 1997 20:53:36 GMT."
<Pine.GSO.3.95.970227205133.11463A-100000 at black.europe.shiva.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <Pine.GSO.3.95.970227205133.11463A-100000 at black.europe.shiva.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-353772832P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 27 Feb 1997 16:19:29 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-353772832P
Content-Type: text/plain; charset=us-ascii
On Thu, 27 Feb 1997 20:53:36 GMT, Malcolm Campbell said:
> Note that under this definition, my e-mail account, modem, computer
> and printer constitute a fax machine.
Umm.. don't go there. Really. You're opening a can of worms.
If you try to chase this on the grounds that e-mail is Fax, then you're
going to have to *also* deal with some of the fax-specific things - isn't
there a requirement that the originating site/phone number appear at
the top/bottom of each page of the fax, etc?
A better bet is to just live with the situation, and lobby your local
Congresscreature (or equivalent for those outside the US) to get legislation
passed that actually matches the technology, and the problems involved.
This is far from easy to get right - in fact, the *Department of Justice*
filed a brief *opposing* the original Exon amendment, because the way it
re-defined electronic communication, it *removed* all enforcement
ability of *current* legislation.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-353772832P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxX6XtQBOOoptg9JAQF/+gP/eUFRHOpEwdvc2tHA5xyFw5hoF+R+97Pm
djLcZwWqV1zIaRR5KFUW49ZJLrKwPGVR/D3qV5Ri4kG94pB0/L7dll1FEuymI2kJ
l4fw/UllWFAdF+kE0vk+dNAkobp0K97442RpzZYeizjNxKODnNZc1hniFyBZPZEP
9q6HWFJd0Bk=
=wZiw
-----END PGP MESSAGE-----
--==_Exmh_-353772832P--
Received: from ietf.org by ietf.org id aa10909; 27 Feb 97 16:31 EST
Received: from gateway-gw.pictel.com by ietf.org id aa10792; 27 Feb 97 16:28 EST
Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740)
id AA06202; Thu, 27 Feb 97 16:25:55 EST
Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1)
id AA17810; Thu, 27 Feb 97 16:25:54 EST
Received: by smtpnotes.pictel.com (4.1/SMI-4.1)
id AA16551; Thu, 27 Feb 97 16:25:52 EST
Message-Id: <9702272125.AA16551 at smtpnotes.pictel.com>
Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id
F8869DB2EFDC46EC8525644B007564BC; Thu, 27 Feb 97 21:25:52
To: ietf <ietf at ietf.org>
Sender:ietf-request at ietf.org
From: Bradley Stevenson/Engineering/PicTel <Bradley_Stevenson at smtpnotes.pictel.com>
Date: 27 Feb 97 16:22:49 EDT
Subject: remove
Mime-Version: 1.0
Content-Type: Text/Plain
Source-Info: From (or Sender) name not authenticated.
remove
unsubscribe
take me off this list
Received: from ietf.org by ietf.org id aa14707; 27 Feb 97 17:18 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa14567;
27 Feb 97 17:16 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA05432; Thu, 27 Feb 97 17:12:49 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA18017; Thu, 27 Feb 1997 17:12:43 -0500
Date: Thu, 27 Feb 1997 17:12:43 -0500
Message-Id: <9702272212.AA18017 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
Cc: thomas keller <tkeller at unlinfo2.unl.edu>,
Branislav Meandzija <bran at metacomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
In-Reply-To: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54 -0800,
<v03101711af3b9c9535ec at [129.46.166.223]>
Subject: Re: don't shoot the messenger
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Thu, 27 Feb 1997 12:32:54 -0800
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
What is the proof that spamming necessarily imposes a large and expensive
load on the hosts involved?
That's been our experience at MIT. We get the gamut between people
sending SPAM to our users, which cause them to complain to postmaster,
to people using MIT.EDU has a large-sclae SPAM reflector, to people
sending e-mail bombs through MIT.EDU. Throughout all of this do not
underestimate the amount of time it takes to handle user complaints
which get sent to postmaster.
It's those reasons in particular why we ultimately ended up implementing
IP-level blocking. One can debate whether or not users actually want to
receive the spam, but if the spam is endangering their ability to get
fast reliable mail access, blocking it so that they can get their normal
mail does seem to be what our users want.
- Ted
Received: from ietf.org by ietf.org id aa15270; 27 Feb 97 17:24 EST
Received: from [151.145.250.198] by ietf.org id aa15164; 27 Feb 97 17:22 EST
Received: (from smap at localhost) by eagle.anheuser-busch.com (8.7.5/8.6.12) id QAA14882 for <ietf at ietf.org>; Thu, 27 Feb 1997 16:11:27 -0600 (CST)
Received: from stlabcexg001.anheuser-busch.com(151.145.101.151) by eagle.anheuser-busch.com via smap (V1.3)
id sma014876; Thu Feb 27 16:11:00 1997
Received: by stlabcexg001.anheuser-busch.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC24C9.EC2A8FD0 at stlabcexg001.anheuser-busch.com>; Thu, 27 Feb 1997 16:18:52 -0600
Message-ID: <c=US%a=attmail%p=BUSCH%l=STLABCEXG01-970227221847Z-116066 at stlabcexg001.anheuser-busch.com>
Sender:ietf-request at ietf.org
From: "Rabb, Daniel" <Daniel.Rabb at anheuser-busch.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Do you want off this Mailing List ? (From www.ietf.org)
Date: Thu, 27 Feb 1997 16:18:47 -0600
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
To join the announcement list, send a request to:
ietf-announce-request at ietf.org
and enter the word subscribe in the Subject line of the message.
The IETF discussion list is open, and therefore has a wide range of
topics. However, be advised that employment opportunities and
advertising
fall well outside the range of acceptable topics.
To join the IETF general discussion list, send a request to:
ietf-request at ietf.org
and enter the word subscribe in the Subject line of the message.
An archive of mail sent to the IETF lists is available via anonymous FTP
from the directory /ietf-mail-archive/ietf on ietf.org.
To join most other Internet mailing lists, send a request to the
associated ``-request'' address (e.g., to join the list at listhost list,
send a message to list-request at listhost). Never send a subscription
message to the list itself.
General inquiries about the IETF should be sent to ietf-info at ietf.org .
-------------
In other words.. to unsubscribe yourself from this list please send a
message to ietf-request at ietf.org and enter the word unsubscribe in the
Subject line of the message.
PLEASE do not send requests to unsubsribe from this list, to the list
itself.
Thank you,
Dan Rabb
Communications and Network Services
314/865-9149
Daniel.Rabb at Anheuser-Busch.com
Received: from ietf.org by ietf.org id aa16073; 27 Feb 97 17:37 EST
Received: from audio.ecn.purdue.edu by ietf.org id aa15861; 27 Feb 97 17:34 EST
Received: from audio.ecn.purdue.edu (ali at localhost)
by audio.ecn.purdue.edu (8.6.12/3.8davy)
for delivery to "ietf at ietf.org"
id RAA20885; Thu, 27 Feb 1997 17:32:02 -0500
Message-Id: <199702272232.RAA20885 at audio.ecn.purdue.edu>
Date: Thu, 27 Feb 1997 17:32:02 -0500
Sender:ietf-request at ietf.org
From: Zafar Ali <ali at ecn.purdue.edu>
To: ietf at ietf.org
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
unsubscribe
Received: from ietf.org by ietf.org id aa17967; 27 Feb 97 17:59 EST
Received: from apprentice.qualcomm.com by ietf.org id aa17828;
27 Feb 97 17:57 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA19783; Thu, 27 Feb 1997 14:51:59 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03101719af3bb8a2cc98 at [129.46.166.223]>
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 14:28:09 -0800
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: Remove us from the mailing list
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>
>The IETF list needs stronger control than it apparently has. For example:
>at a minimum, only allow posting from people on the list (or on a separate
>list you maintain so people who post from multiple addresses don't have too
>much inconvenience)
Just because a list is public and membership unrestricted, why should that
imply posters cannot be anonymous?
>and no one should be added to the list unless at least an
>email loop confirmation occurs where you send mail asking for a confirmation
>of the subscritpion request and get back a postitive response from the
>subscription address.
What policy would your propose for subscriber addresses that are themselves
public lists with unrestricted membership?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa19686; 27 Feb 97 18:20 EST
Received: from also.media.org by ietf.org id aa19609; 27 Feb 97 18:18 EST
Received: (from carl at localhost)
by also.media.org (8.8.5/8.8.4/961211bjb)
id SAA24523; Thu, 27 Feb 1997 18:16:01 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Carl Malamud [IMS]" <carl at also.media.org>
Message-Id: <199702272316.SAA24523 at also.media.org>
Subject: Re: don't shoot the messenger
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Thu, 27 Feb 1997 18:16:01 -0500 (EST)
Cc: jwn2 at qualcomm.com, tkeller at unlinfo2.unl.edu, bran at metacomm.com,
tytso at mit.edu, schulzrinne at cs.columbia.edu, cnielsen at pbi.net,
ietf at ietf.org
In-Reply-To: <9702272212.AA18017 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Feb 27, 97 05:12:43 pm
Organization: Internet Multicasting Service
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I agree with Ted ... there is a very strong and very real cost
to spamming and mailbombing. When Santa was mailbombed at
north.pole.org, we had three people working for a a week
doing nothing but handle the situation. Likewise with spamming,
a problem we had with tpc.int where people decided they
had to fax 500 copies of a notice to 500 members of congress.
IP level blocking was the only serious way to handle these
problems. DNS blocks in sendmail or inetd were partially
effective, but we found folks that spend their time damaging
the world also tend not to have very effective network
implementations (e.g., their dns tables are inevitably screwed
up).
We weren't an ISP, merely a content provider, and I can tell
you we felt the costs in no uncertain terms.
Carl
According to Theodore Y. Ts'o:
>
> Date: Thu, 27 Feb 1997 12:32:54 -0800
> From: "John W. Noerenberg" <jwn2 at qualcomm.com>
>
> What is the proof that spamming necessarily imposes a large and expensive
> load on the hosts involved?
>
> That's been our experience at MIT. We get the gamut between people
> sending SPAM to our users, which cause them to complain to postmaster,
> to people using MIT.EDU has a large-sclae SPAM reflector, to people
> sending e-mail bombs through MIT.EDU. Throughout all of this do not
> underestimate the amount of time it takes to handle user complaints
> which get sent to postmaster.
>
> It's those reasons in particular why we ultimately ended up implementing
> IP-level blocking. One can debate whether or not users actually want to
> receive the spam, but if the spam is endangering their ability to get
> fast reliable mail access, blocking it so that they can get their normal
> mail does seem to be what our users want.
>
> - Ted
>
Received: from ietf.org by ietf.org id aa19807; 27 Feb 97 18:21 EST
Received: from callandor.cybercash.com by ietf.org id aa19716;
27 Feb 97 18:20 EST
Received: by callandor.cybercash.com; id SAA20549; Thu, 27 Feb 1997 18:09:09 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma020541; Thu, 27 Feb 97 18:08:57 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA18833; Thu, 27 Feb 97 18:14:42 EST
Date: Thu, 27 Feb 1997 18:14:41 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <v03101719af3bb8a2cc98 at [129.46.166.223]>
Message-Id: <Pine.SUN.3.91.970227180639.18109B at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997, John W. Noerenberg wrote:
> Date: Thu, 27 Feb 1997 14:28:09 -0800
> From: John W. Noerenberg <jwn2 at qualcomm.com>
>
> At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
> >
> >The IETF list needs stronger control than it apparently has. For example:
> >at a minimum, only allow posting from people on the list (or on a separate
> >list you maintain so people who post from multiple addresses don't have too
> >much inconvenience)
>
> Just because a list is public and membership unrestricted, why should that
> imply posters cannot be anonymous?
And where did I say they couldn't be? I just indicated that they should have
to go through an explicit email loop subscription cycle. As commonly
happens, the abusers make life a bit more difficult for everyone else.
> >and no one should be added to the list unless at least an
> >email loop confirmation occurs where you send mail asking for a confirmation
> >of the subscritpion request and get back a postitive response from the
> >subscription address.
>
> What policy would your propose for subscriber addresses that are themselves
> public lists with unrestricted membership?
Such subscriptions have always been problematic due to bounces from
sublist entries going back to the main list maintainer who knows nothing
about them. I believe there are some early RFCs on this.
The existence of any lists on the general Internet with no restirction or
confirmation on subscriptions is an open inviation to abuse, abuse which is
occuring with increasing frequency. There are a variety of possible
solutions or partial solutions to the email abuse problems we are
seeing. Doing nothing is not one of these.
> john noerenberg
> jwn2 at qualcomm.com
> --------------------------------------------------------------------
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa20198; 27 Feb 97 18:26 EST
Received: from singapura.singnet.com.sg by ietf.org id aa19961;
27 Feb 97 18:25 EST
Received: from localhost (mathias at localhost) by singapura.singnet.com.sg (8.8.5/8.7.2) with SMTP id HAA19275; Fri, 28 Feb 1997 07:22:23 +0800 (SST)
Date: Fri, 28 Feb 1997 07:22:20 +0800 (SST)
Sender:ietf-request at ietf.org
From: Mathias Koerber <mathias at staff.singnet.com.sg>
X-Sender: mathias at singapura.singnet.com.sg
Reply-To: mathias at staff.singnet.com.sg
To: Zafar Ali <ali at ecn.purdue.edu>
cc: ietf at ietf.org
Subject: Re: remove
In-Reply-To: <199702272232.RAA20885 at audio.ecn.purdue.edu>
Message-ID: <Pine.OSF.3.93.970228072148.15902A-100000 at singapura.singnet.com.sg>
X-Disclaimer: I don't speak for anyone except for myself (and to myself sometimes)
Organization: SingNet
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 27 Feb 1997, Zafar Ali wrote:
| Date: Thu, 27 Feb 1997 17:32:02 -0500
| From: Zafar Ali <ali at ecn.purdue.edu>
| To: ietf at ietf.org
| Subject: remove
|
| remove
| unsubscribe
|
Pls send requests like this to: ietf-REQUEST at ietf.org
NOT the list itself.
Thx
Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | mathias at koerber.org
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
Received: from ietf.org by ietf.org id aa22248; 27 Feb 97 18:56 EST
Received: from apprentice.qualcomm.com by ietf.org id aa22141;
27 Feb 97 18:55 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id PAA00671; Thu, 27 Feb 1997 15:51:59 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0310171caf3bbc2fa242 at [129.46.166.223]>
In-Reply-To: <9702272212.AA18017 at dcl.MIT.EDU>
References: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54
-0800, <v03101711af3b9c9535ec at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Thu, 27 Feb 1997 15:36:54 -0800
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: don't shoot the messenger
Cc: thomas keller <tkeller at unlinfo2.unl.edu>,
Branislav Meandzija <bran at metacomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 5:12 PM -0500 2/27/97, Theodore Y. Ts'o wrote:
> Date: Thu, 27 Feb 1997 12:32:54 -0800
> From: "John W. Noerenberg" <jwn2 at qualcomm.com>
>
> What is the proof that spamming necessarily imposes a large and expensive
> load on the hosts involved?
>
>That's been our experience at MIT. We get the gamut between people
>sending SPAM to our users, which cause them to complain to postmaster,
>to people using MIT.EDU has a large-sclae SPAM reflector, to people
>sending e-mail bombs through MIT.EDU. Throughout all of this do not
>underestimate the amount of time it takes to handle user complaints
>which get sent to postmaster.
That's practical experience and very valuable. Is there some conclusion
that can be drawn from the organization of store-and-forward nets that says
dropping a large bolus of spam in the net necessarily causes congestion (or
maybe indigestion is better here)? All the effects you cite are the result
of network congestion. IETF should be seeking a methodological explanation
for why spam is bad, or determine that none can be found presently. (This
is an invitation for anyone working on this problem to publicize
themselves.)
Btw, don't anybody for one minute think I actually like those cretin spammers.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa26201; 27 Feb 97 19:32 EST
Received: from icicle.winternet.com by ietf.org id aa26048; 27 Feb 97 19:30 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id SAA08458 for <ietf at ietf.org>; Thu, 27 Feb 1997 18:27:56 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 18:27:56 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma008425; Thu, 27 Feb 97 18:27:31 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id pa000093 for <ietf at ietf.org>; Thu, 27 Feb 1997 18:35:52 +0000
Received: by mackie.winternet.com with Microsoft Mail
id <01BC24DD.0E199060 at mackie.winternet.com>; Thu, 27 Feb 1997 18:35:50 -0600
Message-ID: <01BC24DD.0E199060 at mackie.winternet.com>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: "REMOVE" function
Date: Thu, 27 Feb 1997 18:35:19 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
I'm quite surprised that an internet technology based mailing list =
requires you to send "remove" requests to a separate e-mail address. =
I'm just a loser internet junkie with Windows NT and "NT Mail" and I'm =
spoiled on its ability to handle both actual messages and commands-if it =
understands the body as a command, it will perform it. If it looks like =
a command (1 or 2 words or whatever) but doesn't understand it, it =
ignores it. If it's a long message, it broadcasts it.
Considering there's about 1500 members on this list, it's a sad shame =
that "remove" in the body won't work. =20
Perhaps we should be the first to develop an artificially intelligent =
listserv server that can understand text like, "Please remove me from =
this list." It would then send a confirmation request to the sender to =
make sure removal is what he/she wants, or to broadcast it.
Whatever. The listserv server being used now is obviously archaic.
Jon Davis
NewBreed Communications
Received: from ietf.org by ietf.org id aa26202; 27 Feb 97 19:32 EST
Received: from cnri by ietf.org id aa26086; 27 Feb 97 19:30 EST
Received: from Turing.Stanford.EDU by CNRI.Reston.VA.US id aa27107;
27 Feb 97 19:30 EST
Received: from localhost (ole at localhost) by Turing.Stanford.EDU (8.8.5/8.8.3) with SMTP id QAA09678; Thu, 27 Feb 1997 16:26:45 -0800 (PST)
X-Authentication-Warning: Turing.Stanford.EDU: ole owned process doing -bs
Date: Thu, 27 Feb 1997 16:26:44 -0800 (PST)
Sender:ietf-request at ietf.org
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
X-Sender: ole at Turing.Stanford.EDU
To: ole at csli.stanford.edu
Subject: BOFs at Interop Las Vegas
Message-ID: <Pine.GSO.3.95.970227162351.8638C-100000 at Turing.Stanford.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
If you are interested in running a BOF at the next NetWorld+Interop in
May in Las Vegas, send a message to ldraper at interop.com for more info.
Ole
-----------------------------------------------------------------
Ole J. Jacobsen, Senior Technical Advisor, Interop Company,
Fax: Please don't, use e-mail instead.
E-mail: ole at csli.stanford.edu, ole at world.std.com, ole at interop.com
-----------------------------------------------------------------
Received: from ietf.org by ietf.org id aa26424; 27 Feb 97 19:35 EST
Received: from iggy.iwsc.com by ietf.org id aa26323; 27 Feb 97 19:34 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA254; Thu, 27 Feb 1997 16:36:38 -0800
Message-ID: <331625D2.2160 at metacomm.com>
Date: Thu, 27 Feb 1997 16:24:50 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
CC: "Theodore Y. Ts'o" <tytso at mit.edu>,
thomas keller <tkeller at unlinfo2.unl.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: John W. Noerenberg's message of Thu, 27 Feb 1997 12:32:54
-0800, <v03101711af3b9c9535ec at [129.46.166.223]> <v0310171caf3bbc2fa242 at [129.46.166.223]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
John W. Noerenberg wrote:
>
> At 5:12 PM -0500 2/27/97, Theodore Y. Ts'o wrote:
> > Date: Thu, 27 Feb 1997 12:32:54 -0800
> > From: "John W. Noerenberg" <jwn2 at qualcomm.com>
> >
> > What is the proof that spamming necessarily imposes a large and expensive
> > load on the hosts involved?
> >
> >That's been our experience at MIT. We get the gamut between people
> >sending SPAM to our users, which cause them to complain to postmaster,
> >to people using MIT.EDU has a large-sclae SPAM reflector, to people
> >sending e-mail bombs through MIT.EDU. Throughout all of this do not
> >underestimate the amount of time it takes to handle user complaints
> >which get sent to postmaster.
>
> That's practical experience and very valuable. Is there some conclusion
> that can be drawn from the organization of store-and-forward nets that says
> dropping a large bolus of spam in the net necessarily causes congestion (or
> maybe indigestion is better here)? All the effects you cite are the result
> of network congestion. IETF should be seeking a methodological explanation
> for why spam is bad, or determine that none can be found presently. (This
> is an invitation for anyone working on this problem to publicize
> themselves.)
>
> Btw, don't anybody for one minute think I actually like those cretin spammers.
>
> john noerenberg
> jwn2 at qualcomm.com
> --------------------------------------------------------------------
> She discovered, as many a living being had discovered, that
> rational decisions are far more easily made than carried out.
> -- Orson Scott Card, Speaker for the Dead, 1986
> --------------------------------------------------------------------
Perhaps what is needed is a mechanism for users to register with their
network operators what classes of e-mail (as defined by the network
operator or the IETF) they wish to receive. Those classes could allow
the selection of the type of e-mail reflectors they wish to be under.
That would solve many of the problems listed above while avoiding
censorship.
Branislav
Received: from ietf.org by ietf.org id aa28819; 27 Feb 97 20:05 EST
Received: from mercury.Sun.COM by ietf.org id aa28576; 27 Feb 97 20:03 EST
Received: from Holland.Sun.COM ([129.159.201.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA12801 for <ietf at ietf.org>; Thu, 27 Feb 1997 16:58:08 -0800
Received: from albano by Holland.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk200)
id CAA21109; Fri, 28 Feb 1997 02:01:25 +0100
Received: from glorantha.Holland.Sun.COM by albano (SMI-8.6/SMI-SVR4-se.fkk201)
id CAA28375; Fri, 28 Feb 1997 02:01:24 +0100
Received: by glorantha.Holland.Sun.COM (SMI-8.6/SMI-SVR4)
id BAA08401; Fri, 28 Feb 1997 01:58:51 +0100
Message-Id: <199702280058.BAA08401 at glorantha.Holland.Sun.COM>
Subject: re: ietf mailing list policy
To: ietf at ietf.org
Date: Fri, 28 Feb 1997 01:58:51 +0100 (MET)
Precedence: junk
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com> from "Donald E. Eastlake 3rd" at Feb 27, 97 03:39:36 pm
Sender:ietf-request at ietf.org
From: Henk.Langeveld at holland.sun.com
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake suggests stronger control on the ietf list,
and making it a closed "subscribers only" list.
Consider bouncing all messages that do not have "Cc:/To: ietf at ietf.org"
in the headers -- this would at least catch any occurrance of the
ietf being subscribed to another list.
Of course it would be naive to expect this to stop any deliberate
spammers, but it will take out many of the obvious mistakes.
Also, it should be a requirement for a mailing list to frequently post
[a pointer to] the subscription guidelines -with a Reply-To: *-request at ....
--
Henk Langeveld
Received: from ietf.org by ietf.org id aa02199; 27 Feb 97 20:50 EST
Received: from ns.jck.com by ietf.org id aa02026; 27 Feb 97 20:47 EST
Received: from tp.jck.com ("port 2935"@tp.jck.com)
by a4.jck.com (PMDF V5.1-7 #16053) with SMTP id <0E6AI64V100LYR at a4.jck.com>
for ietf at ietf.org; Thu, 27 Feb 1997 20:44:28 -0500 (EST)
Date: Thu, 27 Feb 1997 20:19:49 -0500
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: don't shoot the messenger
In-reply-to: <331625D2.2160 at metacomm.com>
X-Sender: klensin at alpha1.reston.mci.net
To: bran at metacomm.com
Cc: "John W. Noerenberg" <jwn2 at qualcomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
thomas keller <tkeller at unlinfo2.unl.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Message-id: <3.0.1.16.19970227201949.0aa768c0 at alpha1.reston.mci.net>
MIME-version: 1.0
X-Mailer: Windows Eudora Pro Version 3.0.1 (16)
Content-type: text/plain; charset="us-ascii"
References: <v03101711af3b9c9535ec at [129.46.166.223]>
<v0310171caf3bbc2fa242 at [129.46.166.223]>
Source-Info: From (or Sender) name not authenticated.
At 16:24 97.02.27 -0800, Branislav Meandzija wrote:
>Perhaps what is needed is a mechanism for users to register with their
>network operators what classes of e-mail (as defined by the network
>operator or the IETF) they wish to receive. Those classes could allow
>the selection of the type of e-mail reflectors they wish to be under.
>That would solve many of the problems listed above while avoiding
>censorship.
As long as you think the bulk mailers would observe the lists or
correctly-label material being send out. In a world in which some of them
have been accused of using "remove" replies to build new lists of people
who are "guaranteed" to read and respond to email, this is not an
obviously-safe assumption.
john
Received: from ietf.org by ietf.org id aa03662; 27 Feb 97 21:08 EST
Received: from iggy.iwsc.com by ietf.org id aa03440; 27 Feb 97 21:06 EST
Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19])
by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP
id AAA245; Thu, 27 Feb 1997 18:08:42 -0800
Message-ID: <33163B65.5B73 at metacomm.com>
Date: Thu, 27 Feb 1997 17:56:53 -0800
Sender:ietf-request at ietf.org
From: Branislav Meandzija <bran at metacomm.com>
Reply-To: bran at metacomm.com
Organization: Meta Communications, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: John C Klensin <klensin at mci.net>
CC: "John W. Noerenberg" <jwn2 at qualcomm.com>,
"Theodore Y. Ts'o" <tytso at mit.edu>,
thomas keller <tkeller at unlinfo2.unl.edu>,
Henning Schulzrinne <schulzrinne at cs.columbia.edu>,
Christopher Nielsen <cnielsen at pbi.net>, ietf at ietf.org
Subject: Re: don't shoot the messenger
References: <v03101711af3b9c9535ec at [129.46.166.223]>
<v0310171caf3bbc2fa242 at [129.46.166.223]> <3.0.1.16.19970227201949.0aa768c0 at alpha1.reston.mci.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
John C Klensin wrote:
>
> At 16:24 97.02.27 -0800, Branislav Meandzija wrote:
> >Perhaps what is needed is a mechanism for users to register with their
> >network operators what classes of e-mail (as defined by the network
> >operator or the IETF) they wish to receive. Those classes could allow
> >the selection of the type of e-mail reflectors they wish to be under.
> >That would solve many of the problems listed above while avoiding
> >censorship.
>
> As long as you think the bulk mailers would observe the lists or
> correctly-label material being send out. In a world in which some of them
> have been accused of using "remove" replies to build new lists of people
> who are "guaranteed" to read and respond to email, this is not an
> obviously-safe assumption.
>
> john
That is not what I ment. In essence, you can do the same as now but
add variations defining classes of defenses and allow those to be
user selectable.
Branislav
Received: from ietf.org by ietf.org id aa12884; 27 Feb 97 22:43 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa12497; 27 Feb 97 22:38 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id WAA24473; Thu, 27 Feb 1997 22:34:54 -0500 (EST)
Message-Id: <199702280334.WAA24473 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Jon Davis <jon at interact-net.com>
cc: "ietf at ietf.org" <ietf at ietf.org>, moore at cs.utk.edu
Subject: Re: "REMOVE" function
In-reply-to: Your message of "Thu, 27 Feb 1997 18:35:19 CST."
<01BC24DD.0E199060 at mackie.winternet.com>
Date: Thu, 27 Feb 1997 22:34:54 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> I'm quite surprised that an internet technology based mailing list
> requires you to send "remove" requests to a separate e-mail address.
Even for lists that try to filter subscribe/unsubscribe requests from
the list traffic (mine do), having separate addresses for list traffic
and requests helps decrease the incidence of mis-handled mail.
I've seen a lot of lists that were too "smart" - e.g.
+ incorrectly guessing that an ordinary message contained commands,
attempting to process such commands, and sending replies back
to the sender rather than forwarding the message to the list.
+ incorrectly guessing that a message sent to the list was the
result of a mail loop and and silently dropping the message.
+ gratuitously deleting message headers that the list robot doesn't
recognize
+ refusing to forward the message because the list robot has a
conflicting notion of how to use the Precedence field, than
the sender did. (the right answer: don't use it at al)
+ refusing to accept mail from moore at cs.utk.edu just because I happen
to be subscribed as moore+folder at cs.utk.edu
+ gratuitously adding a reply-to field on all list traffic, effectively
preventing replies to all recipients of the subject message
+ gratuitously replacing the sender-specified reply-to field with the
list's reply-to field, thereby preventing someone from including
third parties in a conversation with the list.
+ deliberately setting the SMTP MAIL FROM address (on messages redistributed
to list members) to the address of the mailing list, (rather than the
address of the list maintainer as per RFC 1123), then trying to
distinguish nondelivery report messages from normal list traffic.
Thus not only are some legitimate messages treated as nondelivery
reports, some bounced messages aren't recognized and cause mail loops.
+ gratuitously munging the subject field to add the name of the list
(thus making it harder to read the real subject of the message in
a one-line-per-message summary of messages from that list)
Which is not to say that I disagree with you -- it's a good idea to
try to filter out things that are obviously subscribe/unsubscribe requests
(say, the ones that fit majordomo or listserv syntax). And for all I
know, this is already being done. But since this matching is necessarily
based on heuristics, it's probably better to minimize the number of
improperly blocked messages, even if that means that a few requests
slip through to the list.
But I have a lot more tolerance for the occasional subscribe/unsubscribe
message sent to a list, than I have for any of the practices listed above.
Keith
Received: from ietf.org by ietf.org id aa22267; 27 Feb 97 23:35 EST
Received: from icicle.winternet.com by ietf.org id aa22166; 27 Feb 97 23:34 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA05632 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:31:32 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 22:31:32 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma005618; Thu, 27 Feb 97 22:31:22 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id sa000096 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:39:52 +0000
Received: by localhost with Microsoft Mail
id <01BC24FF.24E21CF0 at localhost>; Thu, 27 Feb 1997 22:39:51 -0600
Message-ID: <01BC24FF.24E21CF0 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: "REMOVE" function
Date: Thu, 27 Feb 1997 22:39:36 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
Point taken, noted, proven, and known all along. You couldn't be more =
right. However, in some cases-let's use mine as an example-all of a =
sudden less than 24 hours ago I came home to find my e-mail box flooded =
with e-mail. None of it was directed to me. I looked at all the e-mail =
and didn't find a single e-mail explaining "WELCOME TO WHATEVER THE HELL =
MAILING LIST THIS IS, AND ***THIS*** IS HOW TO REMOVE YOURSELF. =
(Apparently, I had subscribed to the list a couple MONTHS ago, and =
someone-rather than something-finally managed to get me signed up. I =
never received a welcome e-mail that included explanation on removal =
procedures.) =20
I was stumped. I had no way of knowing how to remove myself. So, I did =
what I had to do-I e-mailed the list, asking for removal. Now I was =
getting TWICE the e-mail, telling me not to post to the list, which I =
had no clue I was subscribed to, and so frankly I really didn't care if =
everyone got copies of my "removal" e-mail. One of those e-mails, =
however, was a note from someone telling me that I'd been removed from =
the list, but I'd still be getting occasional updates. Fine. WHY AM I =
STILL ON THIS LIST?
So, you see, something is wrong, something is terribly wrong, and I am =
observing that there are at least two different gentlemen on this planet =
on this list who are in my shoes right now.
Now tell me, all you people who e-mailed me not to waste your e-mail =
bandwidth with my complaints, now tell me that it wasn't worth it / =
wasn't important enough to speak up on it.
Jon Davis
-----Original Message-----
From: Keith Moore [SMTP:moore at cs.utk.edu]
Sent: Thursday, February 27, 1997 9:35 PM
To: Jon Davis
Cc: ietf at ietf.org; moore at cs.utk.edu
Subject: Re: "REMOVE" function=20
> I'm quite surprised that an internet technology based mailing list
> requires you to send "remove" requests to a separate e-mail address.=20
Even for lists that try to filter subscribe/unsubscribe requests from
the list traffic (mine do), having separate addresses for list traffic
and requests helps decrease the incidence of mis-handled mail. =20
I've seen a lot of lists that were too "smart" - e.g.=20
+ incorrectly guessing that an ordinary message contained commands,
attempting to process such commands, and sending replies back
to the sender rather than forwarding the message to the list.=20
+ incorrectly guessing that a message sent to the list was the
result of a mail loop and and silently dropping the message.
+ gratuitously deleting message headers that the list robot doesn't=20
recognize
+ refusing to forward the message because the list robot has a=20
conflicting notion of how to use the Precedence field, than
the sender did. (the right answer: don't use it at al)
+ refusing to accept mail from moore at cs.utk.edu just because I happen
to be subscribed as moore+folder at cs.utk.edu
+ gratuitously adding a reply-to field on all list traffic, effectively
preventing replies to all recipients of the subject message
+ gratuitously replacing the sender-specified reply-to field with the
list's reply-to field, thereby preventing someone from including=20
third parties in a conversation with the list.
+ deliberately setting the SMTP MAIL FROM address (on messages =
redistributed
to list members) to the address of the mailing list, (rather than the=20
address of the list maintainer as per RFC 1123), then trying to=20
distinguish nondelivery report messages from normal list traffic.
Thus not only are some legitimate messages treated as nondelivery=20
reports, some bounced messages aren't recognized and cause mail loops.
+ gratuitously munging the subject field to add the name of the list
(thus making it harder to read the real subject of the message in
a one-line-per-message summary of messages from that list)
Which is not to say that I disagree with you -- it's a good idea to
try to filter out things that are obviously subscribe/unsubscribe =
requests=20
(say, the ones that fit majordomo or listserv syntax). And for all I
know, this is already being done. But since this matching is =
necessarily
based on heuristics, it's probably better to minimize the number of=20
improperly blocked messages, even if that means that a few requests
slip through to the list.
But I have a lot more tolerance for the occasional subscribe/unsubscribe =
message sent to a list, than I have for any of the practices listed =
above.
Keith
Received: from ietf.org by ietf.org id aa22862; 27 Feb 97 23:41 EST
Received: from icicle.winternet.com by ietf.org id aa22763; 27 Feb 97 23:40 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA06265 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:37:36 -0600 (CST)
Posted-Date: Thu, 27 Feb 1997 22:37:36 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma006227; Thu, 27 Feb 97 22:37:14 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id ta000097 for <ietf at ietf.org>; Thu, 27 Feb 1997 22:45:39 +0000
Received: by localhost with Microsoft Mail
id <01BC24FF.F33A35B0 at localhost>; Thu, 27 Feb 1997 22:45:37 -0600
Message-ID: <01BC24FF.F33A35B0 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: "REMOVE" function
Date: Thu, 27 Feb 1997 22:45:27 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
Ahem... sorry, everybody. Temper control. Long day. Forgive me, it's =
a neat list that I'd be happy to get involved in, but it kind of hit me =
by surprise without warning and I wasn't prepared for all this e-mail.
-----Original Message-----
From: Jon Davis=20
Sent: Thursday, February 27, 1997 10:40 PM
To: ietf at ietf.org
Cc: ietf at ietf.org
Subject: RE: "REMOVE" function=20
Point taken, noted, proven, and known all along. You couldn't be more =
right. However, in some cases-let's use mine as an example-all of a =
sudden less than 24 hours ago I came home to find my e-mail box flooded =
with e-mail. None of it was directed to me. I looked at all the e-mail =
and didn't find a single e-mail explaining "WELCOME TO WHATEVER THE HELL =
MAILING LIST THIS IS, AND ***THIS*** IS HOW TO REMOVE YOURSELF. =
(Apparently, I had subscribed to the list a couple MONTHS ago, and =
someone-rather than something-finally managed to get me signed up. I =
never received a welcome e-mail that included explanation on removal =
procedures.) =20
I was stumped. I had no way of knowing how to remove myself. So, I did =
what I had to do-I e-mailed the list, asking for removal. Now I was =
getting TWICE the e-mail, telling me not to post to the list, which I =
had no clue I was subscribed to, and so frankly I really didn't care if =
everyone got copies of my "removal" e-mail. One of those e-mails, =
however, was a note from someone telling me that I'd been removed from =
the list, but I'd still be getting occasional updates. Fine. WHY AM I =
STILL ON THIS LIST?
So, you see, something is wrong, something is terribly wrong, and I am =
observing that there are at least two different gentlemen on this planet =
on this list who are in my shoes right now.
Now tell me, all you people who e-mailed me not to waste your e-mail =
bandwidth with my complaints, now tell me that it wasn't worth it / =
wasn't important enough to speak up on it.
Jon Davis
-----Original Message-----
From: Keith Moore [SMTP:moore at cs.utk.edu]
Sent: Thursday, February 27, 1997 9:35 PM
To: Jon Davis
Cc: ietf at ietf.org; moore at cs.utk.edu
Subject: Re: "REMOVE" function=20
> I'm quite surprised that an internet technology based mailing list
> requires you to send "remove" requests to a separate e-mail address.=20
Even for lists that try to filter subscribe/unsubscribe requests from
the list traffic (mine do), having separate addresses for list traffic
and requests helps decrease the incidence of mis-handled mail. =20
I've seen a lot of lists that were too "smart" - e.g.=20
+ incorrectly guessing that an ordinary message contained commands,
attempting to process such commands, and sending replies back
to the sender rather than forwarding the message to the list.=20
+ incorrectly guessing that a message sent to the list was the
result of a mail loop and and silently dropping the message.
+ gratuitously deleting message headers that the list robot doesn't=20
recognize
+ refusing to forward the message because the list robot has a=20
conflicting notion of how to use the Precedence field, than
the sender did. (the right answer: don't use it at al)
+ refusing to accept mail from moore at cs.utk.edu just because I happen
to be subscribed as moore+folder at cs.utk.edu
+ gratuitously adding a reply-to field on all list traffic, effectively
preventing replies to all recipients of the subject message
+ gratuitously replacing the sender-specified reply-to field with the
list's reply-to field, thereby preventing someone from including=20
third parties in a conversation with the list.
+ deliberately setting the SMTP MAIL FROM address (on messages =
redistributed
to list members) to the address of the mailing list, (rather than the=20
address of the list maintainer as per RFC 1123), then trying to=20
distinguish nondelivery report messages from normal list traffic.
Thus not only are some legitimate messages treated as nondelivery=20
reports, some bounced messages aren't recognized and cause mail loops.
+ gratuitously munging the subject field to add the name of the list
(thus making it harder to read the real subject of the message in
a one-line-per-message summary of messages from that list)
Which is not to say that I disagree with you -- it's a good idea to
try to filter out things that are obviously subscribe/unsubscribe =
requests=20
(say, the ones that fit majordomo or listserv syntax). And for all I
know, this is already being done. But since this matching is =
necessarily
based on heuristics, it's probably better to minimize the number of=20
improperly blocked messages, even if that means that a few requests
slip through to the list.
But I have a lot more tolerance for the occasional subscribe/unsubscribe =
message sent to a list, than I have for any of the practices listed =
above.
Keith
Received: from ietf.org by ietf.org id aa12969; 28 Feb 97 4:51 EST
Received: from ecrc.de by ietf.org id aa12587; 28 Feb 97 4:46 EST
Received: from primergy.atlantikgmbh.de (primergy.atlantikgmbh.de [194.221.55.201]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with SMTP id KAA01094 for <ietf at ietf.org>; Fri, 28 Feb 1997 10:43:38 +0100 (MET)
Received: by primergy.atlantikgmbh.de with Microsoft Exchange (IMC 4.0.837.3)
id <01BC2564.641B7690 at primergy.atlantikgmbh.de>; Fri, 28 Feb 1997 10:44:36 +0100
Message-ID: <c=DE%a=_%p=Die_Atlantik_Gru%l=PRIMERGY-970228094434Z-740 at primergy.atlantikgmbh.de>
Sender:ietf-request at ietf.org
From: J}rgen Wegner <jwegner at atlantikgmbh.de>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: membership
Date: Fri, 28 Feb 1997 10:44:34 +0100
Return-Receipt-To: <jwegner at atlantikgmbh.de>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
please remove me from the list
J.Wegner
jwegner at atlantikgmbh.de
Received: from ietf.org by ietf.org id aa26789; 28 Feb 97 8:06 EST
Received: from relay.hq.tis.com by ietf.org id aa25880; 28 Feb 97 7:55 EST
Received: by relay.hq.tis.com; id HAA09254; Fri, 28 Feb 1997 07:51:31 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2)
id xma009243; Fri, 28 Feb 97 07:51:23 -0500
Received: from [10.33.112.20] (flapdoodle.hq.tis.com [10.33.112.20]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id HAA12983; Fri, 28 Feb 1997 07:49:00 -0500 (EST)
X-Sender: lewis at pop.hq.tis.com
Message-Id: <v03007801af3c7b9cb9cc at [10.33.112.20]>
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Feb 1997 07:35:52 -0500
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Edward Lewis <lewis at tis.com>
Subject: Forging subscriptions - was Re: Remove us from the mailing list
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>Forging people's names on subscriptions to mailing lists is becoming a daily
>occurance....
Just a thought, not to start a deep technical thread on the general list.
Without being able to authenicate the subscription requestor (at this
time), could a tape-and-glue fix be as simple as: when a request for
subscription is received, a confirmation is requested (i.e., in a mail
message to the subscribing address), and until a returned confirmation is
received, the subscription is not made? I've heard that this approach is
being used with at least one (non-IETF) mail list.
A forger would have to be in the path of the forged address to see the
confirmation message. To prevent predicatability of the confirmation a
somewhat random phrase could be used in the confirmation request and reply.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis Trusted Information Systems
Phone: 301-854-5794 Email: lewis at tis.com
Received: from ietf.org by ietf.org id aa29299; 28 Feb 97 8:33 EST
Received: from ietf.ietf.org by ietf.org id aa29163; 28 Feb 97 8:30 EST
To: ietf at ietf.org
Subject: Re: "REMOVE" function
Sender:ietf-request at ietf.org
From: Dale R Worley <worley at world.std.com>
Date: Fri, 28 Feb 1997 08:30:22 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702280830.aa29163 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <01BC24FF.24E21CF0 at localhost> jon at interact-net.com (Jon Davis)
writes:
I was stumped. I had no way of knowing how to remove myself.
Append "-request" to the name of the list and send a request for
removal from that list, per Internet standards of about twenty years'
duration.
(Yes, if you're only used to Microsoft products, you won't know that,
because Microsoft does everything differently. But you're in the Real
World now, and have to learn how the Real World does things.)
(This isn't a flame, it's just to point out that there are ways to
know what you needed to know.)
Dale
Received: from ietf.org by ietf.org id aa29620; 28 Feb 97 8:34 EST
Received: from ietf.ietf.org by ietf.org id aa29500; 28 Feb 97 8:33 EST
To: ietf at ietf.org
Subject: RFC 1990
Sender:ietf-request at ietf.org
From: Jon Davis <mackie at winternet.com>
Date: Fri, 28 Feb 1997 08:33:39 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9702280833.aa29500 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Does anyone know where I can get an overview of RFC 1990 written in PLAIN
ENGLISH? I realize it's a technical outline and should only expect it to
be written in technical terms, but I was just wondering if anyone bothered
to try to rephrase the article in a clearer presentation than at
http://www.neda.com/rfc/rfc1990.txt
Thanks,
Jon Davis
Received: from ietf.org by ietf.org id aa04887; 28 Feb 97 9:23 EST
Received: from noc.msc.edu by ietf.org id aa04486; 28 Feb 97 9:19 EST
Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
id AA22968; Fri, 28 Feb 97 08:16:29 -0600
Sender:ietf-request at ietf.org
From: Tim Salo <salo at msc.edu>
Received: (salo at localhost) by uh.msc.edu (8.7.1/8.6.6) id IAA01066 for ietf at ietf.org; Fri, 28 Feb 1997 08:16:29 -0600 (CST)
Date: Fri, 28 Feb 1997 08:16:29 -0600 (CST)
Message-Id: <199702281416.IAA01066 at uh.msc.edu>
To: ietf at ietf.org
Subject: Re: "REMOVE" function
Source-Info: From (or Sender) name not authenticated.
> Subject: Re: "REMOVE" function
> From: Dale R Worley <worley at world.std.com>
> Date: Fri, 28 Feb 1997 08:30:22 -0500
>
> In article <01BC24FF.24E21CF0 at localhost> jon at interact-net.com (Jon Davis)
> writes:
> I was stumped. I had no way of knowing how to remove myself.
>
> Append "-request" to the name of the list and send a request for
> removal from that list, per Internet standards of about twenty years'
> duration.
Per one of a number of inconsistent "standards."
"The nice thing about standards is that there are so many
to choose from"
> (Yes, if you're only used to Microsoft products, you won't know that,
> because Microsoft does everything differently. But you're in the Real
> World now, and have to learn how the Real World does things.)
>
> (This isn't a flame, it's just to point out that there are ways to
> know what you needed to know.)
I suppose this _is_ intended as a flame, (of the lack of a _single_
standard in this area, not of you personally).
-tjs
Received: from ietf.org by ietf.org id aa10671; 28 Feb 97 10:31 EST
Received: from jekyll.piermont.com by ietf.org id aa10273; 28 Feb 97 10:26 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id KAA11728; Fri, 28 Feb 1997 10:22:18 -0500 (EST)
Message-Id: <199702281522.KAA11728 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: Jon Davis <mackie at winternet.com>
cc: ietf at ietf.org
Subject: Re: RFC 1990
In-reply-to: Your message of "Fri, 28 Feb 1997 08:33:39 EST."
<9702280833.aa29500 at ietf.org>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 28 Feb 1997 10:22:17 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Jon Davis writes:
> Does anyone know where I can get an overview of RFC 1990 written in PLAIN
> ENGLISH? I realize it's a technical outline and should only expect it to
> be written in technical terms, but I was just wondering if anyone bothered
> to try to rephrase the article in a clearer presentation than at
> http://www.neda.com/rfc/rfc1990.txt
It seems pretty reasonable to read to me. If you are having trouble
with it, maybe you should hire a consultant to help you doing your
implementation.
Perry
Received: from ietf.org by ietf.org id aa19960; 28 Feb 97 12:19 EST
Received: from edu.lahti.fi by ietf.org id aa19506; 28 Feb 97 12:13 EST
Received: (qmail 3585 invoked by uid 1067); 28 Feb 1997 17:14:13 -0000
Date: Fri, 28 Feb 1997 19:14:13 +0200 (EET)
Sender:ietf-request at ietf.org
From: Sampo Syreeni <decoy at nexus.edu.lahti.fi>
To: Edward Lewis <lewis at tis.com>
cc: "Donald E. Eastlake 3rd" <dee at cybercash.com>, ietf at ietf.org
Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list
In-Reply-To: <v03007801af3c7b9cb9cc at [10.33.112.20]>
Message-ID: <Pine.LNX.3.95.970228191200.3456C-100000 at nexus.edu.lahti.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 28 Feb 1997, Edward Lewis wrote:
> >Forging people's names on subscriptions to mailing lists is becoming a daily
> >occurance....
>
> Without being able to authenicate the subscription requestor (at this
> time), could a tape-and-glue fix be as simple as: when a request for
> subscription is received, a confirmation is requested (i.e., in a mail
> message to the subscribing address), and until a returned confirmation is
> received, the subscription is not made?
A good idea. Only one problem needs to be fixed: the list should note
pending confirmations and refuse to send more of them even if more
subscriptions are received. Otherwise it would be easy to flood someone
with confirmations. Of course, the confirmations would have to time out...
Sampo Syreeni (Decoy/dAWN), student, <decoy at edu.lahti.fi>
Received: from ietf.org by ietf.org id aa22983; 28 Feb 97 12:55 EST
Received: from greatkhan.netmeg.net by ietf.org id aa22783; 28 Feb 97 12:51 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w0WPk-0001V4C; Fri, 28 Feb 97 12:48 EST
Message-Id: <m0w0WPk-0001V4C at netmeg.net>
Date: Fri, 28 Feb 97 12:48 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <Pine.SUN.3.91.970227153007.13158E-100000 at cybercash.com>
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd (dee at cybercash.com) wrote:
> Forging people's names on subscriptions to mailing lists is becoming a daily
> occurance. Spamming is becoming an hourly occurance.
[ ... ]
> much inconvenience) and no one should be added to the list unless at least an
> email loop confirmation occurs where you send mail asking for a confirmation
> of the subscritpion request and get back a postitive response from the
> subscription address.
There's no harm in setting something like that up. I've seen it used
on other lists so it shouldn't require reinventing the wheel.
Another thing to consider is poking the list software to add a line or
two to the bottom of each post:
====================== IETF Mailing List ==========================
To unsubscribe, e-mail ietf-request at ietf.org, subject "unsubscribe"
I hate to cruft up each post with extra administrivia, but it's
a pretty good fallback if someone gets on against their will.
By making "IETF Mailing List" and "ietf-request" variables, they
could use the same fix for all of their lists.
Matt
Received: from ietf.org by ietf.org id aa24799; 28 Feb 97 13:15 EST
Received: from greatkhan.netmeg.net by ietf.org id aa24479; 28 Feb 97 13:12 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w0Wk8-0001V4C; Fri, 28 Feb 97 13:09 EST
Message-Id: <m0w0Wk8-0001V4C at netmeg.net>
Date: Fri, 28 Feb 97 13:09 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: "REMOVE" function
In-Reply-To: <199702281416.IAA01066 at uh.msc.edu>
Source-Info: From (or Sender) name not authenticated.
Tim Salo (salo at msc.edu) wrote:
> Dale R Worley (worley at world.std.com) wrote:
> > In article <01BC24FF.24E21CF0 at localhost> jon at interact-net.com (Jon Davis)
> > writes:
> > I was stumped. I had no way of knowing how to remove myself.
> >
> > Append "-request" to the name of the list and send a request for
> > removal from that list, per Internet standards of about twenty years'
> > duration.
>
> Per one of a number of inconsistent "standards."
>
> "The nice thing about standards is that there are so many
> to choose from"
Whatever. Lest it get lost in the noise, however, Dave was presenting
information which is very valuable to someone new to the net.
Inconsistent standards notwithstanding, it's *always* a good idea to
try the -request trick before actually posting to the list address.
Even if you don't get the command right you'll usually get something
back either telling what the commands are or how you can find out what
they are.
And, until you can get off a list, you should be able to filter the
unwanted mail out of your regular mailbox. Unix folks can check out the
Mail Filtering FAQ (it's available in a number of places, including our
mirror at http://www.netmeg.net/faq/internet/mail/filtering-faq/)...
I'm sure there must be similar software for Windows platforms, etc.
Matt
Received: from ietf.org by ietf.org id aa03364; 28 Feb 97 14:56 EST
Received: from icicle.winternet.com by ietf.org id aa02877; 28 Feb 97 14:49 EST
Received: (from adm at localhost) by icicle.winternet.com (8.7.5/8.7.5) id NAA22053 for <ietf at ietf.org>; Fri, 28 Feb 1997 13:46:36 -0600 (CST)
Posted-Date: Fri, 28 Feb 1997 13:46:36 -0600 (CST)
Received: from mackie.winternet.com(204.246.64.78) by icicle.winternet.com via smap (V2.0beta)
id xma022034; Fri, 28 Feb 97 13:46:27 -0600
Received: from www.interact-net.com by www.interact-net.com (NTMail 3.02.10) with ESMTP id da000107 for <ietf at ietf.org>; Fri, 28 Feb 1997 13:54:51 +0000
Received: by localhost with Microsoft Mail
id <01BC257E.F7109F60 at localhost>; Fri, 28 Feb 1997 13:54:50 -0600
Message-ID: <01BC257E.F7109F60 at localhost>
Sender:ietf-request at ietf.org
From: Jon Davis <jon at interact-net.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: Re: RFC 1990
Date: Fri, 28 Feb 1997 13:50:15 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at www.interact-net.com
Source-Info: From (or Sender) name not authenticated.
By the way, I do stand corrected. RFC 1990 is well-written, and I apologize, I must not have taken a very good look at it.
Jon Davis
Received: from ietf.org by ietf.org id aa10964; 28 Feb 97 16:37 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa10550; 28 Feb 97 16:31 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA28082; Fri, 28 Feb 1997 16:29:03 -0500 (EST)
Message-Id: <199702282129.QAA28082 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Matt Magri <matt at netmeg.net>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: Remove us from the mailing list
In-reply-to: Your message of "Fri, 28 Feb 1997 12:48:00 EST."
<m0w0WPk-0001V4C at netmeg.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 28 Feb 1997 16:29:03 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> Another thing to consider is poking the list software to add a line or
> two to the bottom of each post:
>
> ====================== IETF Mailing List ==========================
> To unsubscribe, e-mail ietf-request at ietf.org, subject "unsubscribe"
>
Appending something to a message is not a good idea, especially with
MIME mail...it amounts to corruption of the message.
For what it's worth, an informal group is working on a draft for
adding such information to the message header, in the form of mailto:
URLs. So if your UA recognizes embedded URLs, you can simply click on
the URL in the List-Unsubscribe header field to unsubscribe.
Presumably, more UAs will be taught about this feature if it's
standardized.
I'm trying to get them to request a BOF for the Memphis IETF.
Meanwhile, interested parties can subscribe to their list by clicking
on the following URL :) (assuming your UA supports not only URLs but
the newly-invented-but-not-yet-standardized extended mailto syntax)
mailto:list-header at arpp.carleton.ca?Subject=subscribe%20list-header
(Be forewarned: the list software they're using exhibits many of the
kinds of brain-damage I mentioned in my recent flame...note for
example the lack of a seperate -REQUEST address for requests...but
they say some of the problems are being fixed.)
-Keith
Received: from ietf.org by ietf.org id aa14345; 28 Feb 97 17:20 EST
Received: from apprentice.qualcomm.com by ietf.org id aa14201;
28 Feb 97 17:17 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA01205; Fri, 28 Feb 1997 14:10:48 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03101711af3cfaa80bb2 at [129.46.166.223]>
In-Reply-To: <Pine.SUN.3.91.970227180639.18109B at cybercash.com>
References: <v03101719af3bb8a2cc98 at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Fri, 28 Feb 1997 14:01:22 -0800
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: Remove us from the mailing list
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 6:14 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>On Thu, 27 Feb 1997, John W. Noerenberg wrote:
>
>> Date: Thu, 27 Feb 1997 14:28:09 -0800
>> From: John W. Noerenberg <jwn2 at qualcomm.com>
>>
>> At 3:39 PM -0500 2/27/97, Donald E. Eastlake 3rd wrote:
>> >
>> >The IETF list needs stronger control than it apparently has. For exampl=
e:
>> >at a minimum, only allow posting from people on the list (or on a separa=
te
>> >list you maintain so people who post from multiple addresses don't have =
too
>> >much inconvenience)
>>
>> Just because a list is public and membership unrestricted, why should tha=
t
>> imply posters cannot be anonymous?
>
>And where did I say they couldn't be? I just indicated that they should ha=
ve
>to go through an explicit email loop subscription cycle. As commonly
>happens, the abusers make life a bit more difficult for everyone else.
You didn't, and I know, Donald, that you would not seek to prevent
anonymity. But the consequence is unavoidable. Whatever identity is
chosen is recorded and becomes a property of the list -- and publicly
known. One could argue this identity is itself anonymous, but that is an
infinite regress. At best, one could say this identity is a pseudonym.
That's not the same as anonymity. If one is truly interested in
preserving one's anonymity, it is necessary to minimize the amount of
information about your identity that is revealed. Which means not giving
any identity. If our goal is to permit the free, unrestricted
dissemination of information, the requirement that information include some
identity is inconsistent. After all, an identity on the net is only some
set of information. You can't condition one set on a second and call the
first unrestricted.
>
>The existence of any lists on the general Internet with no restirction or
>confirmation on subscriptions is an open inviation to abuse, abuse which is
>occuring with increasing frequency. There are a variety of possible
>solutions or partial solutions to the email abuse problems we are
>seeing. Doing nothing is not one of these.
>
I quite agree.
best,
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa16094; 28 Feb 97 17:40 EST
Received: from greatkhan.netmeg.net by ietf.org id aa15822; 28 Feb 97 17:36 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w0ars-0001V4C; Fri, 28 Feb 97 17:33 EST
Message-Id: <m0w0ars-0001V4C at netmeg.net>
Date: Fri, 28 Feb 97 17:33 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <199702282129.QAA28082 at ig.cs.utk.edu>
Source-Info: From (or Sender) name not authenticated.
> > Another thing to consider is poking the list software to add a line or
> > two to the bottom of each post:
> >
> > ====================== IETF Mailing List ==========================
> > To unsubscribe, e-mail ietf-request at ietf.org, subject "unsubscribe"
>
> Appending something to a message is not a good idea, especially with
> MIME mail...it amounts to corruption of the message.
Hm, one might argue that someone posting MIME messages to a general
mailing list should expect to have problems. At any rate, the
insertion could be more sophisticated if there was some desire to
make it friendly to MIME attachments.
> For what it's worth, an informal group is working on a draft for
> adding such information to the message header, in the form of mailto:
> URLs. So if your UA recognizes embedded URLs, you can simply click on
> the URL in the List-Unsubscribe header field to unsubscribe.
Assuming they see it up in the headers when they're being bombarded
by a bunch of messages from some strange source. Still, it sounds like
a promising long-term solution.
Matt
Received: from ietf.org by ietf.org id aa16441; 28 Feb 97 17:44 EST
Received: from cnri by ietf.org id aa16371; 28 Feb 97 17:43 EST
Received: from inet2.tek.com by CNRI.Reston.VA.US id aa21493;
28 Feb 97 17:43 EST
Received: from icebox.vnd.tek.com by inet2.tek.com id <OAA13583 at inet2.tek.com>; Fri, 28 Feb 1997 14:41:19 -0800
Received: from icebox (localhost [127.0.0.1]) by icebox.vnd.tek.com (8.7.5/8.7.3) with ESMTP id OAA18735; Fri, 28 Feb 1997 14:48:33 -0800 (PST)
Message-Id: <199702282248.OAA18735 at icebox.vnd.tek.com>
To: "voccnet.com" <info at voccnet.com>
Cc: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: "Ted Brunner 503.627.1317" <ted.brunner at tek.com>
Subject: remove
In-reply-to: Your message of Sun, 23 Feb 1997 05:08:17 -0800.
<199702231308.FAA10781 at georgia.sallynet.com>
Date: Fri, 28 Feb 1997 14:48:33 -0800
X-Orig-Sender: tedb at vnd.tek.com
Source-Info: From (or Sender) name not authenticated.
Ted Brunner Video and Networking Division
Tektronix
MS 50-490
ted.brunner at tek.com 14150 SW Karl Braun
503.627.1317 Beaverton OR 97005
Received: from ietf.org by ietf.org id aa17535; 28 Feb 97 17:55 EST
Received: from apprentice.qualcomm.com by ietf.org id aa17310;
28 Feb 97 17:53 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id OAA06442; Fri, 28 Feb 1997 14:49:37 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v0310170caf3cdd0a162b at [129.46.166.223]>
In-Reply-To: <199702272316.SAA24523 at also.media.org>
References: <9702272212.AA18017 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at
Feb 27, 97 05:12:43 pm
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1b23-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Fri, 28 Feb 1997 14:23:29 -0800
To: "Carl Malamud [IMS]" <carl at also.media.org>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: don't shoot the messenger
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>, tkeller at unlinfo2.unl.edu,
bran at metacomm.com, schulzrinne at cs.columbia.edu, cnielsen at pbi.net,
ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 6:16 PM -0500 2/27/97, Carl Malamud [IMS] wrote:
>I agree with Ted ... there is a very strong and very real cost
>to spamming and mailbombing. When Santa was mailbombed at
>north.pole.org, we had three people working for a a week
>doing nothing but handle the situation. Likewise with spamming,
>a problem we had with tpc.int where people decided they
>had to fax 500 copies of a notice to 500 members of congress.
>
>IP level blocking was the only serious way to handle these
>problems. DNS blocks in sendmail or inetd were partially
>effective, but we found folks that spend their time damaging
>the world also tend not to have very effective network
>implementations (e.g., their dns tables are inevitably screwed
>up).
I'm not denying the costs. They are real, substantial, and the cause is
truly onerous.
But there can no doubt that appropriate use of the net is a social concern.
Those of us who have grown up on the net are used to an environment free
from the invasions of crass commercialism that characterizes the behavior
of spammers, and the social ineptitude of those who would disrupt the net's
operation in other ways. But there is no getting away from the fact that
the population of the net is becoming more like the population of the world
around us. Inasmuch as managing and directing human behavior is the
province of social institutions that range from villages to nations, then
social institutions must be the vehicle for sanctioning and disciplining
behavior that is inappropriate.
However, the net is a fundamentally different place. Never before has
there existed a means of sweeping aside the constraints that mark the
borders of every other human endeavor. The equivalent of villages or
nations do not exist on the net. The barriers on which we rely to define
interactions with other individuals and other communities do not exist.
Many others, including you, Carl, have written eloquently on how the net
has changed our perception of what human society can be and the
individual's place in it.
Yet here we are reporting techniques and debating the merits of methods
that do create barriers and do limit the dissemination of information,
information which many of us in this community find objectionable, no
doubt. But building walls! Putting up fences!!! Is this truly what we
seek? John Gilmore once said, "The Net treats censorship as damage and
routes around it."
The question about technical alternatives is not an idle one.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa17494; 28 Feb 97 17:55 EST
Received: from ietf.ietf.org by ietf.org id aa15878; 28 Feb 97 17:37 EST
To: IETF-Announce: ;
Subject: Hotel Reservation Update
Date: Fri, 28 Feb 1997 17:37:20 -0500
Sender:ietf-announce-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Message-ID: <9702281737.aa15878 at ietf.org>
1. If you are on the waiting list at the Peabody Hotel, the hotel
should call you when a room becomes available. Per the IETF contract,
you are entitled to the IETF group rate ($119 single; $129 double)
if a room is available at any time up to the start of the meeting.
2. As of this date, we have been informed that there are still rooms
available at the alternate hotel:
Holiday Inn Select
160 Union Avenue
Memphis, TN 38103
Phone: 901-525-5491 (you must call the hotel directly)
CI 1500; CO 1100
75 Rooms reserved until Monday, March 17, 1997
US$ 99.00/single; US$99.00/double
(please add 13.25% tax)
Specify: IETF or Internet Engineering Task Force
One night's room and tax to be submitted at time of
reservation. This deposit is refundable if the
reservation is canceled by 5:00pm CST on the day
prior to arrival. Deposit or guarantee may be in
the form of check or credit card.
3. We recognize that the primary hotel room block has filled
relatively quickly for the past several meetings. While we
typically must negotiate the block size up to two years in
advance, we are looking at ways to increase the size for the
meetings following Memphis.
Received: from ietf.org by ietf.org id aa06028; 28 Feb 97 20:38 EST
Received: from zephyr.isi.edu by ietf.org id aa05506; 28 Feb 97 20:31 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00785>; Fri, 28 Feb 1997 17:28:18 -0800
Message-Id: <199703010128.AA00785 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2113 on Router Alert Option
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 28 Feb 97 17:28:18 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2113:
Title: IP Router Alert Option
Author: D. Katz
Date: February 1997
Mailbox: dkatz at cisco.com
Pages: 4
Characters: 7924
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2113.txt
This memo describes a new IP Option type that alerts transit routers
to more closely examine the contents of an IP packet. This is useful
for, but not limited to, new protocols that are addressed to a
destination but require relatively complex processing in routers along
the path.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970228172439.RFC at ISI.EDU>
SEND /rfc/rfc2113.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2113.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970228172439.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13364; 28 Feb 97 22:01 EST
Received: from shell1.aimnet.com by ietf.org id aa12858; 28 Feb 97 21:56 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id SAA24121; Fri, 28 Feb 1997 18:54:01 -0800 (PST)
Date: Fri, 28 Feb 1997 18:54:01 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Matt Magri <matt at netmeg.net>
cc: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <m0w0ars-0001V4C at netmeg.net>
Message-ID: <Pine.SOL.3.95.970228185222.23818A-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 28 Feb 1997, Matt Magri wrote:
> Assuming they see it up in the headers when they're being bombarded
> by a bunch of messages from some strange source. Still, it sounds like
> a promising long-term solution.
And assuming that their UA even shows the header. The decent UAs I've
seen don't by default blast that confusing junk on the screen.
Dave Morris
Received: from ietf.org by ietf.org id aa19297; 2 Mar 97 14:05 EST
Received: from Ostrogoth.gv-itf.unisource.nl by ietf.org id aa12978;
2 Mar 97 12:50 EST
Received: from ostrogoth.gv-itf.unisource.nl (ostrogoth.gv-itf.unisource.nl [194.151.95.241]) by ostrogoth.gv-itf.unisource.nl (8.7.6/8.7.3) with SMTP id OAA00818; Fri, 28 Feb 1997 14:55:18 +0100
Date: Fri, 28 Feb 1997 14:55:18 +0100 (MET)
Sender:ietf-request at ietf.org
From: Frank de Lange <frank at animalhouse.ml.org>
X-Orig-Sender: frank at ostrogoth.gv-itf.unisource.nl
Reply-To: Frank de Lange <frank at animalhouse.ml.org>
Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list
To: Edward Lewis <lewis at tis.com>
cc: ietf at ietf.org
In-Reply-To: <v03007801af3c7b9cb9cc at [10.33.112.20]>
Message-ID: <ML-3.0.857138118.3978.frank at ostrogoth.gv-itf.unisource.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> >Forging people's names on subscriptions to mailing lists is becoming a
> >daily occurance....
>
> Just a thought, not to start a deep technical thread on the general list.
>
> Without being able to authenicate the subscription requestor (at this
> time), could a tape-and-glue fix be as simple as: when a request for
> subscription is received, a confirmation is requested (i.e., in a mail
> message to the subscribing address), and until a returned confirmation is
> received, the subscription is not made? I've heard that this approach is
> being used with at least one (non-IETF) mail list.
>
> A forger would have to be in the path of the forged address to see the
> confirmation message. To prevent predicatability of the confirmation a
> somewhat random phrase could be used in the confirmation request and reply.
This does indeed work, a mechanism like this is in use at several sites (an
example of which is ml.org (Monolith), which uses a three-way handshake to
authenticate `subscribers' to their services (free DNS listings, but the same
principle is valid in any other service).
Frank
WWWWW ___________________________
## o o\ / Frank de Lange \
}# \| / +31-70-3712708 day \
##---# _/ +31-320-252965 night \
#### \frank.de.lange at inet.unisource.nl/
\ frank.de.lange at net.info.nl /
------------------------------
Received: from ietf.org by ietf.org id aa18841; 1 Mar 97 13:57 EST
Received: from box.nl by ietf.org id aa17732; 1 Mar 97 13:40 EST
Received: from cs-gj3-a4.hro.nl (cs-gj3-a4.hro.nl [145.24.129.136]) by box.nl (8.7.5/8.6.9) with SMTP id TAA23798 for <ietf at ietf.org>; Sat, 1 Mar 1997 19:37:29 +0100
Date: Sat, 1 Mar 1997 19:37:29 +0100
Message-Id: <199703011837.TAA23798 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: "New Ideas for a WWW standard"
Source-Info: From (or Sender) name not authenticated.
Since I posted my "New Ideas for a WWW standard" the response has been
strong, and the argument vigorous. This being said, I'd like to make my
position more clear on certain issues raised in the argument, and also lay
out more clearly my purpose in writing the document.
I plan to revise my proposal in the coming days, in light of the argument
and my own further research. If anyone would like to collaborate let me know.
The original document plus comments can be found at
http://www.box.nl/~unit/mike/prop.htm
sincerely,
Michael Roetto
Clarifying points:
Web content should not be 'programmed'; a programming language is not suitable.
My suggestion was not that HTML be replaced. The idea was that a more
structural/function-based 'shell' be available to those who desire it. Of
course there are already possibilities: Java, Active-X, CGI/Perl, etc. But
what we have now is a hodgepodge. From a designer/programmer's point of
view this is not optimal. The point was raised that most web content is
static, and therefore a 'programming' approach is unneccesary. I would
suggest that most web content is static *because* of the lack of adequate
language resources. An ideal language should be one that allows for a high
degree of compatibility between the different language/script components.
For the user, dynamic content will always be more interesting. People
re-visit sites with dynamic content. Also for the programmer/designer,
dynamic content is a preferable situation. Even with good tools, manually
updating static content is slow and error-prone. I can really forsee a time
when dynamic content is the norm for the Web.
Naturally, changing standards in midstream would be a disaster. Of course a
new standard will not prevent vendor-specific enhancements. No standard has
ever prevented that. But, in my opinion the so-called standards of the W3C
have suffered the influence of Netscape/MS. Considering the fact that the
Web has become such a grass-roots phenomenon, it might be interesting to see
what would happen if the front-line designer/programmers were given some
input in the standards-adoptions process.
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from cnri by ietf.org id aa11265; 1 Mar 97 19:43 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13449;
1 Mar 97 19:43 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA17174 at pad-thai.cam.ov.com>; Sat, 1 Mar 1997 22:59:24 GMT
Message-Id: <9703012259.AA20824 at MIT.EDU>
Date: 01 Mar 1997 17:35 EST
To: cat-ietf at mit.edu
From: Alex Brown <alex at nortel.ca>
Subject: Unsubscribe
Precedence: bulk
unsubscribe cat-ietf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Desktop Systems Integration, Global Enterprise Services |
| Nortel Technology, Ottawa, Ontario, Canada |
| Email: alex at bnr.ca Phone (613) 763-3731 Fax: (613) 763-3283 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received: from ietf.org by ietf.org id aa10164; 2 Mar 97 12:26 EST
Received: from edu.lahti.fi by ietf.org id aa03281; 2 Mar 97 11:06 EST
Received: (qmail 11810 invoked by uid 1067); 2 Mar 1997 16:07:38 -0000
Date: Sun, 2 Mar 1997 18:07:38 +0200 (EET)
Sender:ietf-request at ietf.org
From: Sampo Syreeni <decoy at nexus.edu.lahti.fi>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: IETF list <ietf at ietf.org>
Subject: Re: don't shoot the messenger
In-Reply-To: <v0310170caf3cdd0a162b at [129.46.166.223]>
Message-ID: <Pine.LNX.3.95.970302180037.11788A-100000 at nexus.edu.lahti.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 28 Feb 1997, John W. Noerenberg wrote:
> Those of us who have grown up on the net are used to an environment free
> from the invasions of crass commercialism that characterizes the behavior
> of spammers, and the social ineptitude of those who would disrupt the net's
> operation in other ways. But there is no getting away from the fact that
> the population of the net is becoming more like the population of the world
> around us.
And this is exactly why the principle of absolute freedom of speech
doesn't work anymore. Anarchy works as long as all the participants have
some minimum amount of respect for each other. It is seen in the society
that certain regulation is necessary for keeping the minority that doesn't
respect the society's rules in order. Traditionally this minority has kept
itself outside the Net community. As this is changing, there is a need to
change the rules on which the Net functions.
> The barriers on which we rely to define
> interactions with other individuals and other communities do not exist.
Do you define spamming as interaction? It's just as interactive as
slamming strangers in the face when you see them on the street.
But this is already way off the topic of this list.
Sampo Syreeni (Decoy/dAWN), student, <decoy at edu.lahti.fi>
Received: from ietf.org by ietf.org id aa19011; 2 Mar 97 21:21 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa14894;
2 Mar 97 20:01 EST
Received: from Ikkoku-Kan.Panda.COM (john at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id QAA09695; Sun, 2 Mar 1997 16:58:13 -0800 (PST)
Received: from localhost (jms at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id QAA17662; Sun, 2 Mar 1997 16:58:10 -0800 (PST)
Date: Sun, 2 Mar 1997 16:12:59 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: don't shoot the messenger
To: Sampo Syreeni <decoy at edu.lahti.fi>
cc: IETF list <ietf at ietf.org>
In-Reply-To: <Pine.LNX.3.95.970302180037.11788A-100000 at nexus.edu.lahti.fi>
Message-ID: <MailManager.857347979.17009.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 2 Mar 1997 18:07:38 +0200 (EET), Sampo Syreeni wrote:
> And this is exactly why the principle of absolute freedom of speech
> doesn't work anymore. Anarchy works as long as all the participants have
> some minimum amount of respect for each other. It is seen in the society
> that certain regulation is necessary for keeping the minority that doesn't
> respect the society's rules in order. Traditionally this minority has kept
> itself outside the Net community. As this is changing, there is a need to
> change the rules on which the Net functions.
I believe that the appropriate term is "the tragedy of the commons".
The underlying problem is the contemporary fashion of "in your face" exercise
of freedom; the most egregious examples of which (alas) are found in the USA.
"In your face" is the flamboyant and unnecessary exercise of a "freedom" in a
way calculated to cause maximum offense; a refusal to recognize the freedom of
others *from* the exercise of that freedom.
I do not, however, believe that regulation will help. The only thing that
will help is the replacement of the current "receiver pays" model of email
with a "sender pays" model. I have some neat ideas about how to accomplish
this in Internet email, and hope to come up with an Internet Draft later this
year.
Received: from ietf.org by ietf.org id aa04893; 3 Mar 97 0:03 EST
Received: from net1.unety.net by ietf.org id aa25017; 2 Mar 97 22:30 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by net1.unety.net (8.7.3/8.7.3) with SMTP id UAA29582; Mon, 3 Mar 1997 20:56:53 -0600 (CST)
Received: by webster.unety.net with Microsoft Mail
id <01BC274F.ECBDE9A0 at webster.unety.net>; Sun, 2 Mar 1997 21:23:08 -0600
Message-ID: <01BC274F.ECBDE9A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Sampo Syreeni <decoy at edu.lahti.fi>, 'Mark Crispin' <MRC at panda.com>
Cc: IETF list <ietf at ietf.org>
Subject: RE: don't shoot the messenger
Date: Sun, 2 Mar 1997 21:23:07 -0600
Encoding: 43 TEXT
Source-Info: From (or Sender) name not authenticated.
On Sunday, March 02, 1997 10:12 AM, Mark Crispin[SMTP:MRC at panda.com] wrote:
@ On Sun, 2 Mar 1997 18:07:38 +0200 (EET), Sampo Syreeni wrote:
@ > And this is exactly why the principle of absolute freedom of speech
@ > doesn't work anymore. Anarchy works as long as all the participants have
@ > some minimum amount of respect for each other. It is seen in the society
@ > that certain regulation is necessary for keeping the minority that doesn't
@ > respect the society's rules in order. Traditionally this minority has kept
@ > itself outside the Net community. As this is changing, there is a need to
@ > change the rules on which the Net functions.
@
@ I believe that the appropriate term is "the tragedy of the commons".
@
@ The underlying problem is the contemporary fashion of "in your face" exercise
@ of freedom; the most egregious examples of which (alas) are found in the USA.
@ "In your face" is the flamboyant and unnecessary exercise of a "freedom" in a
@ way calculated to cause maximum offense; a refusal to recognize the freedom of
@ others *from* the exercise of that freedom.
@
@ I do not, however, believe that regulation will help. The only thing that
@ will help is the replacement of the current "receiver pays" model of email
@ with a "sender pays" model. I have some neat ideas about how to accomplish
@ this in Internet email, and hope to come up with an Internet Draft later this
@ year.
@
In my opinion, once the Internet moves to a model
based on "platforms" instead of "protocols" based
on object technology and agents many of these
problems will go away.
With standard service reference models and
more emphasis on computers doing the work
vs. people, life for people will improve...
..of course, the life (or life span) for computers will diminish...
--
Jim Fleming
Unir Corporation
e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)
Received: from cnri by ietf.org id aa08235; 3 Mar 97 0:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01579;
3 Mar 97 0:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA12362 at pad-thai.cam.ov.com>; Mon, 3 Mar 1997 03:59:39 GMT
X-Organisation: Indian Institute of Technology, New Delhi.
Date: Mon, 3 Mar 1997 09:27:08 +0530 (IST)
From: Alok Srivastava <alok at henna.iitd.ernet.in>
Subject: unsubscribe
To: cat-ietf at mit.edu
Message-Id: <Pine.3.07.9703030908.A24651-5100000 at henna>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
unsubscribe cat-ietf
Received: from ietf.org by ietf.org id aa08574; 3 Mar 97 1:03 EST
Received: from dot.netrex.net by ietf.org id aa04134; 2 Mar 97 23:43 EST
Received: from host226 (usr15-dialup34.mix2.Boston.mci.net [166.55.70.162]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id XAA00168; Sun, 2 Mar 1997 23:39:44 -0500 (EST)
Message-Id: <3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Sun, 02 Mar 1997 19:49:15 -0500
To: Matt Magri <matt at netmeg.net>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Remove us from the mailing list
In-Reply-To: <m0w0ars-0001V4C at netmeg.net>
References: <199702282129.QAA28082 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 05:33 PM 2/28/97 EST, Matt Magri wrote:
>
>Hm, one might argue that someone posting MIME messages to a general
>mailing list should expect to have problems. At any rate, the
>insertion could be more sophisticated if there was some desire to
>make it friendly to MIME attachments.
What about digitally signed MIME? Multipart-signed might actually happen
some day....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from cnri by ietf.org id aa18387; 3 Mar 97 3:49 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03569;
3 Mar 97 3:49 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA18408 at pad-thai.cam.ov.com>; Mon, 3 Mar 1997 07:37:02 GMT
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Mon, 3 Mar 1997 08:36:41 +0100
X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed;
Mon, 3 Mar 1997 08:36:41 +0100
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 3 Mar 1997 08:36:39 +0100
X400-Received: by /PRMD=CCETT/ADMD=ATLAS/C=FR/; Relayed;
Mon, 3 Mar 1997 08:34:02 +0100
Date: Mon, 3 Mar 1997 08:34:02 +0100
X400-Originator: rpoulet at ccett.fr
X400-Recipients: non-disclosure:;
X400-Mts-Identifier: [/PRMD=CCETT/ADMD=ATLAS/C=FR/;857374347 at ccett.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: unsubscribe
Alternate-Recipient: Allowed
From: R?mi POULET <rpoulet at ccett.fr>
Message-Id: <01BC27AD.A5B131D0 at pcpoulet.ccett.fr>
To: "cat-ietf at mit.edu" <cat-ietf at mit.edu>
Subject: unsubscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Precedence: bulk
unsubscribe
Remi POULET
FT-CNET/DSM/AMI/TCA
3, rue du Clos-Courtel
BP 58
35 512 CESSON SEVIGNE Cedex
FRANCE
Tel : (33) 2-99-12-48-78
fax :(33) 2-99-12-40-98
Received: from ietf.org by ietf.org id aa06776; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03708; 3 Mar 97 9:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-08.txt
Date: Mon, 03 Mar 1997 09:23:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030923.aa03708 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-08.txt
Pages : 14
Date : 02/27/1997
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol includes
a command for identifying and authenticating a user to a server and for
optionally negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the protocol
and the connection. This document describes how a protocol specifies such
a command, defines several mechanisms for use by the command, and defines
the protocol used for carrying a negotiated security layer over the
connection.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-auth-sasl-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-08.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-08.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970227100115.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227100115.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06759; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03787; 3 Mar 97 9:24 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-civanlar-bmpeg-01.txt
Date: Mon, 03 Mar 1997 09:24:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03787 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RTP Payload Format for Bundled MPEG
Author(s) : R. Civanlar, G. Cash, B. Haskell
Filename : draft-civanlar-bmpeg-01.txt
Pages : 6
Date : 02/27/1997
This document describes a payload type for bundled, MPEG-2 encoded video
and audio data to be used with RTP, version 2. Bundling has some advantages
for this payload type particularly when it is used for video-on-demand
applications. This payload type is to be used when its advantages are
important enough to sacrifice the modularity of having separate audio and
video streams.
A technique to improve packet loss resilience based on "out-of-band"
transmission of MPEG-2 specific, vital information is described also.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-civanlar-bmpeg-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-civanlar-bmpeg-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-civanlar-bmpeg-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970227140419.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-civanlar-bmpeg-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-civanlar-bmpeg-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227140419.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06769; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03752; 3 Mar 97 9:24 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-sasl-pop3-01.txt
Date: Mon, 03 Mar 1997 09:24:07 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03752 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : POP3 AUTHentication command
Author(s) : J. Myers
Filename : draft-myers-sasl-pop3-01.txt
Pages : 6
Date : 02/27/1997
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a security layer for
subsequent protocol interactions. This extension is a profile of the
Simple Authentication and Session Layer [SASL].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-sasl-pop3-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-sasl-pop3-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-sasl-pop3-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970227100739.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-sasl-pop3-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-sasl-pop3-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227100739.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa06730; 3 Mar 97 10:03 EST
Received: from ietf.ietf.org by ietf.org id aa03781; 3 Mar 97 9:24 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-01.txt
Date: Mon, 03 Mar 1997 09:24:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03781 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-01.txt
Pages : 5
Date : 02/27/1997
This document describes issues relating to user identification in provision
of "roaming capability" for dialup Internet users. "Roaming capability"
may be loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-provided corporate
network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-nai-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-nai-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970227140016.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227140016.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa08496; 3 Mar 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa03724; 3 Mar 97 9:24 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-myers-auth-sasl-08.txt
Date: Mon, 03 Mar 1997 09:24:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703030924.aa03724 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Authentication and Security Layer (SASL)
Author(s) : J. Myers
Filename : draft-myers-auth-sasl-08.txt
Pages : 14
Date : 02/27/1997
This document describes a method for adding authentication support to
connection-based protocols. To use this specification, a protocol includes
a command for identifying and authenticating a user to a server and for
optionally negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the protocol
and the connection. This document describes how a protocol specifies such
a command, defines several mechanisms for use by the command, and defines
the protocol used for carrying a negotiated security layer over the
connection.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-myers-auth-sasl-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-myers-auth-sasl-08.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-auth-sasl-08.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970227100115.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-myers-auth-sasl-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-auth-sasl-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970227100115.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11690; 3 Mar 97 10:52 EST
Received: from auntie.bbcnc.org.uk by ietf.org id aa11203; 3 Mar 97 10:40 EST
Received: from auntie.bbcnc.org.uk by bbcnc.org.uk id aa02895;
3 Mar 97 15:37 GMT
Received: (naomi at localhost) by auntie.bbcnc.org.uk (8.6.12/8.6.12) id PAA02890; Mon, 3 Mar 1997 15:37:04 GMT
Date: Mon, 3 Mar 1997 15:37:04 +0000 (GMT)
Sender:ietf-request at ietf.org
From: Naomi Troski <naomi at tecc.co.uk>
X-Sender: naomi at auntie.bbcnc.org.uk
To: ietf <ietf at ietf.org>
Subject: Re: remove
In-Reply-To: <9702272125.AA16551 at smtpnotes.pictel.com>
Message-ID: <Pine.SUN.3.91.970303153634.1705L-100000 at auntie.bbcnc.org.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
remove
unsubscribe
take me off this list
Received: from ietf.org by ietf.org id aa15274; 3 Mar 97 11:26 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa14468; 3 Mar 97 11:21 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA24104
for <ietf at ietf.org>; Mon, 3 Mar 1997 11:18:29 -0500
Message-Id: <199703031618.LAA24104 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: Your message of "Sun, 02 Mar 1997 19:49:15 EST."
<3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199702282129.QAA28082 at ig.cs.utk.edu>
<3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1007198018P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Mon, 03 Mar 1997 11:18:26 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1007198018P
Content-Type: text/plain; charset=us-ascii
On Sun, 02 Mar 1997 19:49:15 EST, you said:
> What about digitally signed MIME? Multipart-signed might actually happen
> some day....
Might happen some day? ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1007198018P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxr5z9QBOOoptg9JAQGJxgP/Si231O4yaRDXiwrgspdbODPk9yZbiR6N
Y3TUf96lU0Y3CLBqCUaVQFaRcDplf4arclT5Nu97m0Df1xnpefbzUzA4vYy6mKiY
ybQyzoOMgtin1MDpDzut8+arZI2ZkBIcBiRVqD+sq1suddPNC8dzkqR4R4PZCoSf
2Ew1a0lspy4=
=OpRz
-----END PGP MESSAGE-----
--==_Exmh_-1007198018P--
Received: from ietf.org by ietf.org id aa17009; 3 Mar 97 11:53 EST
Received: from fnal.fnal.gov by ietf.org id aa16404; 3 Mar 97 11:47 EST
Received: from gungnir.fnal.gov ("port 35308"@gungnir.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG2A3XADWG0002TP at FNAL.FNAL.GOV> for
ietf at ietf.org; Mon, 03 Mar 1997 10:45:15 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4)
id KAA27447; Mon, 03 Mar 1997 10:45:15 -0600
Date: Mon, 03 Mar 1997 10:45:14 -0600
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: don't shoot the messenger
In-reply-to: "26 Feb 1997 09:04:01 EST." <"331442D1.10E1"@cs.columbia.edu>
X-Orig-Sender: crawdad at gungnir.fnal.gov
To: ietf at ietf.org
Message-id: <199703031645.KAA27447 at gungnir.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> I'd say: get all the spammers to sign up with one spam-only provider,
> find out what IP range they got and add a capability to sendmail to
> block that range. Unlike, say, netcom, you don't have to worry about
> blocking the mail of innocent bystanders.
I like my own plan even better: Put a wrapper around sendmail such
that if the connection is from the bad guys, you accept it with a
1-byte receive window and only issue a read() about once a minute.
And you always respond to the final "." with a transient failure
code.
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A
Received: from ietf.org by ietf.org id aa20279; 3 Mar 97 12:36 EST
Received: from greatkhan.netmeg.net by ietf.org id aa20057; 3 Mar 97 12:35 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w1bay-0001UWC; Mon, 3 Mar 97 12:32 EST
Message-Id: <m0w1bay-0001UWC at netmeg.net>
Date: Mon, 3 Mar 97 12:32 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
In-Reply-To: <3.0.1.32.19970302194915.00a238c0 at dilbert.is.chrysler.com>
Source-Info: From (or Sender) name not authenticated.
Robert Moskowitz <rgm3 at chrysler.com> wrote:
> Matt Magri wrote:
> >mailing list should expect to have problems. At any rate, the
> >insertion could be more sophisticated if there was some desire to
> >make it friendly to MIME attachments.
>
> What about digitally signed MIME? Multipart-signed might actually happen
> some day....
The problem is that innocent folks are getting attacked _today_. While
I have some sympathy with the idea of not getting in the way of
something that "might actually happen some day", I think it's pretty
obvious that any band-aid added to help the folks who need it today
can be removed when a better solution comes along. As far as the
band-aids that have been proposed so far in this thread go, I haven't
seen anything which isn't already happily in use on other mailing lists
I'm subscribed to. By all means, come up with the best long-term
solution possible but, in the meantime, let's not forget the folks that
need some kind of solution now. As long as the short-term solution
works in the current context *and* doesn't preclude the long-term
solution, then there's little harm to it. As I said, when it comes to a
workable short-term solution, you need look no farther than what's
already being used on other mailing lists.
Matt
Received: from ietf.org by ietf.org id aa20280; 3 Mar 97 12:36 EST
Received: from greatkhan.netmeg.net by ietf.org id aa20071; 3 Mar 97 12:35 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w1bb6-0001UbC; Mon, 3 Mar 97 12:32 EST
Message-Id: <m0w1bb6-0001UbC at netmeg.net>
Date: Mon, 3 Mar 97 12:32 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: don't shoot the messenger
In-Reply-To: <MailManager.857347979.17009.mrc at Ikkoku-Kan.Panda.COM>
Source-Info: From (or Sender) name not authenticated.
Mark Crispin <MRC at panda.com> wrote:
>On Sun, 2 Mar 1997 18:07:38 +0200 (EET), Sampo Syreeni wrote:
>> And this is exactly why the principle of absolute freedom of speech
>> doesn't work anymore. Anarchy works as long as all the participants have
>> some minimum amount of respect for each other. It is seen in the society
>> that certain regulation is necessary for keeping the minority that doesn't
>> respect the society's rules in order. [ ... ]
If you mean regulation in the gov't sense I couldn't disagree more. If
you mean regulation in the net.sense, it's already happening, as it
has for the net's whole existence. It uses the same mechanism that it
always has: "If you don't cooperate I, at least, won't talk to you." This
method was certainly in use as early as ten years ago, which was about
as far back as I go on the net. Back then the concern was largely with
protocols, but the principle is the same.
>> [ ... ] Traditionally this minority has kept
>> itself outside the Net community. As this is changing, there is a need to
>> change the rules on which the Net functions.
Changes have been made all along to deal with changes in net traffic.
This not only includes technical changes to routers and connection
capacities, it also includes adding threading and killfiles to
newsreaders, hardening your server against SYN attacks, and, yes, IP
blocking of rogue sites. At the same time, it also includes educating
advertisers on net.friendly ways of getting their message out.
>I believe that the appropriate term is "the tragedy of the commons".
I was under the impression that that referred to the overuse of
resources which are not owned, resulting in a situation where the
future value of the resource is not worth more to the user than the
current value.
The difference here is that each piece of the net is owned. The owners
of each of these thousands and thousands of pieces have always been
expected to decide how their piece will interact with the rest of the
net. In the past the net was subject to an AUP which restricted
commercial traffic. When ownership changed, that was no longer a
net-wide policy, but one which is currently relegated to a few specific
parts of the net, owned by people who choose to have such a policy.
Each of the other parts of the net have policies, as well, and those
policies are implemented in software and administrative practices, just
as they have always been. As new types of traffic appear on the net,
policies are amended and implemented as needed. If enough of the
thousands and thousands of owners of the various pieces decide to
implement a particular policy, that policy will become, in effect,
net-wide. Currently, a number of owners are implementing policies to
help prevent spam from entering or leaving their pieces of the net. It
remains to be seen how many of the other owners will join them.
>I do not, however, believe that regulation will help. The only thing that
>will help is the replacement of the current "receiver pays" model of email
>with a "sender pays" model. I have some neat ideas about how to accomplish
>this in Internet email, and hope to come up with an Internet Draft later this
>year.
I'll be curious to see what you come up with. I'm not very happy with
the current scheme of simply blocking spam-friendly sites since it puts
such a burden on nonabusive users of the sites, as well. That *is* a
sender pays model, tho, since the price a provider pays to do interact
is to restrict, as much as is technically feasible, the release of
UCE's and other forms of spam from that site. And, I have to admit, if
there was no burden on the nonabusive users of that site, there'd also
be no incentive for the owners of that site to change their policy.
Anyway, if you can come up with a system that increases the cost of
wrong use without placing a bigger burden on right use then more power
to you. We could use some more neat ideas.
Of course, the new cyberpromo site which set off this thread is not a
provider in the traditional sense... it's _devoted_ to bulk UCE. IMHO,
blocking a site like that is a no-brainer.
Matt
Received: from ietf.org by ietf.org id aa22044; 3 Mar 97 12:55 EST
Received: from spinoza.terena.nl by ietf.org id aa21750; 3 Mar 97 12:50 EST
Received: (from root at localhost) by spinoza.terena.nl (8.7.6/8.7.3) id SAA25767 for nato-anw97-interest-list; Mon, 3 Mar 1997 18:46:03 +0100 (MET)
Date: Mon, 3 Mar 1997 18:46:03 +0100 (MET)
Message-Id: <199703031746.SAA25767 at spinoza.terena.nl>
Sender:ietf-request at ietf.org
From: John Martin <martin at terena.nl>
To: Recipients.suppressed at spinoza.terena.nl
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: NATO Advanced Networking Workshop - 5-9 May 1997
Reply-To: nato-anw97 at terena.nl
Source-Info: From (or Sender) name not authenticated.
Dear Colleague,
Please find attached the application form for this year's NATO Advanced
Networking Workshop to be held in Edinburgh, UK, 5-9 May 1997.
Note that applications should be sent to nato-anw97 at terena.nl and *not*
to me directly.
Please feel free to distribute this to appropriate fora.
Regards,
John Martin
*************************************************************************
* John Martin *
* Trans-European Research and Education Networking Association *
* http://www.terena.nl/ *
* *
* TERENA Tel : +31 20 639 1131 *
* Singel 466-468 Fax : +31 20 639 3289 *
* NL-1017 AW Amsterdam UK : +44 141 339 9239 *
*************************************************************************
--
Application for NATO Advanced Networking Workshop - Migrating
Towards a High Speed Networking Service
5-9th May 1997
Introduction
------------
Adjacent to the TERENA Joint European Networking Conference in
Edinburgh in May 1997, a NATO Advanced Networking Workshop has
been organised with the theme: "Migrating Towards a High Speed
Networking Service". It is aimed at those who are currently
running national network services but who will, in the near
future, be moving to new technologies to provide new
applications, higher bandwidth and a more reliable service. The
workshop will be practical and technology-oriented but will also
provide some experience of network management and an exploration
of the application-level issues which arise with the newer
technology.
The event will be a single-track workshop with possibly a limited
number of parallel sessions. There will be classroom-style
lectures complemented by hands-on technical sessions where
appropriate and practicable.
For more details about the workshop, please see:
http://www.terena.nl/conf/nato-anw97/
------8<------8<------ cut here ------8<------8<------
Application
-----------
Please complete *all* sections as fully as possible and return
to:
nato-anw97 at terena.nl
Any additional information should be appended in plain ASCII
format.
A. Personal data:
FAMILY NAME:
First Name:
Sex[1]: Male / Female (please delete)
Employer:
Business Address:
Country[2]:
Business Telephone:
Business Fax:
E-mail:
B. Administration:
1. Accomodation: Please note that participants will be
required to share twin hotel rooms for the duration of the
workshop and conference. If you have any objections to this,
please let us know the reasons here:
2. Travel: Please indicate the approximate cost in US$ of
the cheapest method of travel from your place of residence
to Edinburgh, UK[3]:
C. Description of the candidate's role in National Networking
Activities:
1. Please give a brief summary of your educational
background:
2. Please supply a description of your current employer,
position, duties and responsibilities and how they relate to
current and future networking activities in your country:
3. Please outline details of work you have done with inter-
networking, and what you hope to achieve in the future with
the help of the knowledge gained at the workshop:
4. Upon your return from the workshop, how would you expect
to disseminate the knowledge you gain through attendance at
the workshop:
5. Please give details of any NATO Advanced Networking
Workshops you have participated in previously:
D. Please append any additional information in support of your
application here, in plain ascii text:
------8<------8<------ cut here ------8<------8<------
Notes:
[1] Please note that participants will be required to share twin
hotel rooms for the duration of the workshop and conference.
[2] Please note that only residents of NATO Co-operation Partner
(CP) countries are eligible to attend this workshop and receive
assistance from NATO. Eligible countries are: Albania, Armenia,
Azerbaijan, Belarus, Bulgaria, Czech Republic, Estonia, Georgia,
Hungary, Kazakhstan, Kyrgyzstan, Latvia, Lithuania, Moldova,
Poland, Romania, Russian Federation, Slovak Republic, Slovenia,
Tajikistan, the former Yugoslav Republic of Macedonia,
Turkmenistan, Ukraine, Uzbekistan
NATO countries: Belgium, Canada, Denmark, France, Germany,
Greece, Iceland, Italy, Luxembourg, Netherlands, Norway,
Portugal, Spain, Turkey, United Kingdom, United States.
[3] The period of stay will include a weekend and the dates of
travel should be so that you arrive on / before Sunday 4th May
and depart on / after Saturday 17th May. NB: Should you choose to
spend any additional time in Edinburgh before travelling home,
you must assume any costs incurred.
--end
Received: from ietf.org by ietf.org id aa23597; 3 Mar 97 13:14 EST
Received: from ietf.ietf.org by ietf.org id aa23446; 3 Mar 97 13:12 EST
To: ietf at ietf.org
Subject: MUX Modems (was Re: RFC 1990)
Sender:ietf-request at ietf.org
From: Jon Davis <mackie at winternet.com>
Date: Mon, 03 Mar 1997 13:12:54 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031312.aa23446 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
I'm a student, not a company. What I'm doing is trying to speculate a
similar (but more basic and more broadly supported) "implementation" so to
speak of a single mux modem. Please see
http://www.interact-net.com/think/mux/MUXMODEM.html (and note that I'm 20
years old, somewhat unfamiliar with low-level networking technospeak, and I
had not read RFC 1990 at the time the mux modem model web page above was
produced). It's not an original concept, but it amazes me that modem
companies are not considering the support of multiplexing technology over
POTS connections. Forget the requirement of server-side compatibility
keeping it from happening, if US Robotics can successfully pull off x2,
they should be able to successfully pull off POTS multiplexing.
The mux modem model, therefore, would allow the average consumer to come
home with a single modem, plug it in, do basic software-based configuration
(plug-n-play), and connect to the Internet or BBS or a friend's computer at
twice the bandwidth. The idea here is obviously not multiplexing, which
has been around for decades--maybe as long as a century or more--but rather
*single POTS device* and its *marketability for the average consumer*.
I need professional comments on this (as I merely an internet
junkie/hobbiest). Should I study networking technology more and keep
working on this, or am I wasting my time? And why?
Thanks,
Jon
"Perry E. Metzger" <perry at piermont.com> wrote in article
<199702281522.KAA11728 at jekyll.piermont.com>...
>
> Jon Davis writes:
> > Does anyone know where I can get an overview of RFC 1990 written in
PLAIN
> > ENGLISH? I realize it's a technical outline and should only expect it
to
> > be written in technical terms, but I was just wondering if anyone
bothered
> > to try to rephrase the article in a clearer presentation than at
> > http://www.neda.com/rfc/rfc1990.txt
>
> It seems pretty reasonable to read to me. If you are having trouble
> with it, maybe you should hire a consultant to help you doing your
> implementation.
>
> Perry
>
Received: from ietf.org by ietf.org id aa23678; 3 Mar 97 13:15 EST
Received: from ietf.ietf.org by ietf.org id aa23547; 3 Mar 97 13:14 EST
To: ietf at ietf.org
Subject: Re: New Ideas for a WWW standard (fwd)
Sender:ietf-request at ietf.org
From: Jon Davis <mackie at winternet.com>
Date: Mon, 03 Mar 1997 13:14:15 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031314.aa23547 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
I'm curious to see what Microsoft's plan with dynamic HTML is going to look
like before watching yet another "web standard" pop up.
Jeff Jones <jdjones at sprynet.com> wrote in article
<199702151439.GAA19860 at m3.sprynet.com>...
> > From MegaZone:
> >
> > I hardly think it is dying. The UNIX base is growing.
> As a share of the market in servers and workstations, the facts are
> otherwise.
>
>
> > >convinced, it will not happen. While a team of programmers can use
HTML
> > >3.2, CGI, Java, and CSS1 on their UNIX system for months to build a
web
> > >project, I or any good VB programmer can do the same project, with
> > >equivalent or better performance in just a few weeks. To the customer
> >
> > I completely disagree with this.
> I have no problem with you disagreeing. That is what an open forum is
> about. Unfortunately, I say this based on a past history of successfully
> doing this in the VB/Win32 world in competition with UNIX programmers and
> HTML/Java/CGI programmers. I doubt I am the only one capable of doing
> this.
>
> >
> > First, HTML and CSS1 are cake - anyone should be able to use them with
> ease.
> > And there are several good tools on the market - such as HoTMetaL PRO.
> Yes, there are. Especially the free ones or the shareware ones nobody is
> honest enough to pay for, like HoTMetaL. I use Frontpage in tandem with
> VB4. It is not the only solution, but it works for me, and I turn out my
> projects in less time that others with similar projects.
>
> >
> > Second, pick a language - let's say Perl - a skilled Perl programmer
can
> > create the same application just as fast as a silling VB programmer can
> > do it in VB. And with Perl 5 there are literally hundreds of modules
you
> > can plug together like legos - it greatly reduces the coding time. And
> any
> > full time webmaster is going to write their own Perl library to make
life
> > easier - then you just use your ready-made routines.
> People should use what they want. My argument was in support of a
> standard, like HTML has a published standard today. How about a
specified
> project, given to Perl & VB programmers to do, and a contest to judge the
> results based on quality and time to production? It would certainly
> generate some interest, given all the nasty-grams I get for even
mentioning
> VB to "REAL" programmers.
>
> >
> > Actually programming page content is a completely warped, completely
> terrible
> > idea no matter what you use. It adds completely pointless overhead to
> > the process that is not worth it. When you can mark up a file with
HTML
> > and Style Sheets, and MOST of the web is NOT dynamic content so this
> > covers it, it doesn't make sense to turn to a more programatic syntax.
> If you like HTML, Perl, FastCGI, then you must like some degree of
> overhead. Java is interpreted code, like VB4. Please keep in mind that
I
> am not recommending VB4 as a substitute for a standard. I am merely
> pointing out that the success of a future standard is measured by how
> broadly it is adopted inside and outside of the techie world. The
success
> of VB4, the wide audience for BASIC, and the methodology of how VB has
> incorporated other languages certainly provides a starting point for that
> standard.
>
> >
> > >looking at the life cycle cost, the VB approach always wins. One must
> look
> >
> > That is flat out incorrect. It wins SOME of the time, NOTHING wins all
> of
> > the time. VB doesn't even win most of the time.
> Then specify a scenario - perhaps in the contest above. Specify a real
> world system, with web server, database support, encryption, client side
> features, etc. Require a life cycle cost analysis in the contest. Then
> let's see. A lot of creative minds could tackle this with the religious
> fervor that seems to permeate the UNIX and NT faithful. My real world
> experience, competing against mini and mainframe systems, is that VB
wins.
> Everytime it is tried.
> >
> > >beyond the technology to the intended result and resources. That is
why
> I
> > >simply suggest that standardizing on MS's Basic syntax, or a
reasonable
> >
> > When you have a hammer, everything looks like a nail. You know VB, so
> > you want to standardize on that. I know other Windows programmers who
> would
> > say you're high and C++ is the way to go. My personal fave is Perl,
> followed
> > by C. Someone else will say we're all obviously clueless and Java is
the
> > standard to use.
> Actually, I have changed languages several times over the years to allow
me
> to produce the best product I can for my customers. I started with
machine
> code in the late 70's on Barber-Colman systems, then to Fortran IV and
77,
> then to xBase & Clipper in the DOS world, then to VB in the Windows
world.
> C (and C++) are the ideal, but impractical for development unless you
have
> a huge ROI that pays for it (as in major commercial applications or
writing
> multi-platform operating systems). Hardly a Johnny-one-note in
> programming. The same holds true for my network design. I started with
a
> slow serial net in the early 80s (Barber Colman), then on to Token Ring
and
> Ethernet, to FDDI, Fast Ethernet, and gigabit Ethernet. I went from
> applying repeaters on thinnet to hubs and routers, to switches. From 300
> baud dial up to ISDN, SMDS, and frame relay. I adopt the technology in
any
> field that best suits the short and long term needs.
> >
> > >Perhaps selling MS, Sun, and Netscape on CSS1 would be another good
> idea.
> >
> > As I said, at least MS and NS have already committed to it. MSIE 3.x
has
> > a decent level of support, and MSIE 4.0 and NS 4.0 will supposedly
> support
> > the entire spec. Sun/Java doesn't really enter into it, since applets
> > control their area on their own. Though CSS1 can be used to position
it,
> etc.
> I wholeheartedly agree.
>
> >
> > For the various needs:
> > HTML is for document structure, and some basic layout.
> >
> > CSS1 and following levels will provide increasing levels of fine
> > presentational control.
> >
> > Server Side - define an interface and let people code what they like,
> THAT
> > is the most efficient way. CGI is in need of an overhaul, FastCGI
looks
> > like an effective replacement.
> >
> > Client side - This is a weak spot. A real standardized scripting
> language
> > would be welcome. To be practical I think that should be JavaScript as
> that
> > is the one most widely used and more fully developed. If only MS would
> stop
> > diluting their efforts wit VBScript and JS - and NS would make it an
open
> > spec instead of screwing with it at whim.
> >
> > If anything needs to be worked on, it is the client side scripting.
> >
> > Structure is well in hand and the future is bright, same for
> presentation.
> > CGI and other server issues can be written in the most appropriate
> language
> > for the task and platform - as I strongly feel it should be.
> >
> > Things are really just starting to congeal with the feature war in the
> > browsers really calming down and MS and NS both publically stating that
> > they will abide by the W3C recomendatins on things like HTML and Style
> > Sheets.
> >
> > -MZ
> I agree with this, also. I appreciate how you argue intelligently, and
> avoid the ad hominums that others have made in reply. I learn something
> new from each of your postings.
>
> Jeff Jones
> Remote Monitoring System Services Manager
> UB Networks CSMC Atlanta
> 888-80UBNET
>
> "ALLOPINONS EXPRESSED ARE MY OWN AND NOT NECESSARILY THOSE OF UB
NETWORKS"
>
Received: from ietf.org by ietf.org id aa23732; 3 Mar 97 13:15 EST
Received: from ietf.ietf.org by ietf.org id aa23626; 3 Mar 97 13:14 EST
To: ietf at ietf.org
Subject: Re: Remove us from the mailing list
Sender:ietf-request at ietf.org
From: "Dale R. Worley" <worley at ariadne.com>
Date: Mon, 03 Mar 1997 13:14:56 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031314.aa23626 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <Pine.SOL.3.95.970228185222.23818A-100000 at shell1.aimnet.com>
dwm at xpasc.com ("David W. Morris") writes:
> Assuming they see it up in the headers when they're being bombarded
> by a bunch of messages from some strange source. Still, it sounds like
> a promising long-term solution.
And assuming that their UA even shows the header. The decent UAs I've
seen don't by default blast that confusing junk on the screen.
Although, of course, any decent UA will display the complete headers
upon request.
Dale
--
Dale R. Worley Ariadne Internet Services
Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley at ariadne.com
"Internet-based electronic commerce solutions to real business problems."
Received: from ietf.org by ietf.org id aa25926; 3 Mar 97 13:38 EST
Received: from zephyr.isi.edu by ietf.org id aa25429; 3 Mar 97 13:29 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA04576>; Mon, 3 Mar 1997 10:26:14 -0800
Message-Id: <199703031826.AA04576 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2114 on DCAP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 03 Mar 97 10:26:14 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2114:
Title: Data Link Switching Client Access Protocol
Author: S. Chiang, J. Lee, H. Yasuda
Date: February 1997
Mailbox: schiang at cisco.com, jolee at cisco.com,
yasuda at eme068.cow.melco.co.jp
Pages: 22
Characters: 50872
Updates/Obsoletes: 2106
URL: ftp://ds.internic.net/rfc/rfc2114.txt
This memo describes the Data Link Switching Client Access Protocol
that is used between workstations and routers to transport SNA/
NetBIOS traffic over TCP sessions.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970303102031.RFC at ISI.EDU>
SEND /rfc/rfc2114.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2114.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970303102031.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29155; 3 Mar 97 14:20 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa28974;
3 Mar 97 14:18 EST
Received: from Ikkoku-Kan.Panda.COM (senf at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id LAA10626; Mon, 3 Mar 1997 11:15:37 -0800 (PST)
Received: from localhost (sdennis at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id LAA20814; Mon, 3 Mar 1997 11:15:33 -0800 (PST)
Date: Mon, 3 Mar 1997 10:59:04 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: don't shoot the messenger
To: Matt Magri <matt at netmeg.net>
cc: ietf at ietf.org
In-Reply-To: <m0w1bb6-0001UbC at netmeg.net>
Message-ID: <MailManager.857415544.17009.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 3 Mar 97 12:32 EST, Matt Magri wrote:
> >> It is seen in the society
> >> that certain regulation is necessary for keeping the minority that
> >> doesn't respect the society's rules in order.
> If you mean regulation in the gov't sense I couldn't disagree more. If
> you mean regulation in the net.sense, it's already happening, as it
> has for the net's whole existence.
For most of the net's existance, it was "regulated in the gov't sense." By
the US Department of Defense, first under ARPA, later under DCA. Then under
the National Science Foundation. Such regulation ended only a few years ago.
> It uses the same mechanism that it
> always has: "If you don't cooperate I, at least, won't talk to you."
This is a relatively recent phenomenum. In the past, abuse complaints went to
DCA, who would call the offender on the carpet (as in "show cause why the
order to pull the plug on your net connection in 4 hours should be reversed").
> This
> method was certainly in use as early as ten years ago, which was about
> as far back as I go on the net.
The net has been around for over 25 years. Some of us go back that far. But
even as recently as 10 years ago, there was a thing called an AUP (Acceptable
Use Policy) in force.
Received: from ietf.org by ietf.org id aa02698; 3 Mar 97 15:05 EST
Received: from greatkhan.netmeg.net by ietf.org id aa02502; 3 Mar 97 15:03 EST
Received: by greatkhan.netmeg.net (Smail3.1.29.1 #1)
id m0w1duC-0001UWC; Mon, 3 Mar 97 15:00 EST
Message-Id: <m0w1duC-0001UWC at netmeg.net>
Date: Mon, 3 Mar 97 15:00 EST
Sender:ietf-request at ietf.org
From: Matt Magri <matt at netmeg.net>
To: ietf at ietf.org
Subject: Re: don't shoot the messenger
In-Reply-To: <MailManager.857415544.17009.mrc at Ikkoku-Kan.Panda.COM>
Source-Info: From (or Sender) name not authenticated.
Mark Crispin <MRC at Panda.COM> wrote:
>On Mon, 3 Mar 97 12:32 EST, Matt Magri wrote:
>> >> It is seen in the society
>> >> that certain regulation is necessary for keeping the minority that
>> >> doesn't respect the society's rules in order.
>>
>> If you mean regulation in the gov't sense I couldn't disagree more. If
>> you mean regulation in the net.sense, it's already happening, as it
>> has for the net's whole existence.
>
>For most of the net's existance, it was "regulated in the gov't sense." By
>the US Department of Defense, first under ARPA, later under DCA. Then under
>the National Science Foundation. Such regulation ended only a few years ago.
That is, of course, not what I was referring to as "regulated in the
gov't sense." We can rehash history about what the management actually
consisted of at that time, but that's only necessary if you harbor some
belief that regulation of the net today would bear any resemblence to
the historical version. I submit to you that it not only would not, it
could not.
>> It uses the same mechanism that it
>> always has: "If you don't cooperate I, at least, won't talk to you."
>
>This is a relatively recent phenomenum. In the past, abuse complaints went to
>DCA, who would call the offender on the carpet (as in "show cause why the
>order to pull the plug on your net connection in 4 hours should be reversed").
You're focusing too tightly on the recent phenomenon. As I said, the
issue then was not primarily "abuse", it was being broken. If my servers
hadn't spoken the protocols properly back then, what would have happened?
Or, to use a more recent, and less dire, example, if I created my own
comp.* group, would it have been propagated? The basic mechanism is to
avoid that which is broken and protect your site from any damage that
brokeness may cause, as much as is technically possible. You are correct
that, at the time, there always existed the ultimate penalty of having
a central authority pull the plug, but in practice that was not as
simple a process as you imply.
>> This
>> method was certainly in use as early as ten years ago, which was about
>> as far back as I go on the net.
>
>The net has been around for over 25 years. Some of us go back that far.
Sigh. Hence my caveat about the limit to my personal experience. I'm
sorry if you interpreted that as some sort of bragging. I would have
thought that it would have been taken as a gesture of respect for those
who actually do go back that far. At any rate, since I was giving
examples from within the last 10 years then I hope my meager experience
will prove sufficient.
> [ ... ] But
>even as recently as 10 years ago, there was a thing called an AUP (Acceptable
>Use Policy) in force.
As I mentioned in my last post. It's existence was, in fact, a key
point in the argument I was making that placing limits on the kind of
traffic an owner wants to accept is not groundbreaking. I'm sorry if
the reference wasn't clear enough.
Matt
Received: from ietf.org by ietf.org id aa04882; 3 Mar 97 15:31 EST
Received: from ietf.ietf.org by ietf.org id aa04427; 3 Mar 97 15:21 EST
To: IETF-Announce: ;
Subject: WG ACTION: Multiprotocol Label Switching (mpls)
Date: Mon, 03 Mar 1997 15:20:59 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9703031521.aa04427 at ietf.org>
A new working group has been formed in the Routing Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
Multiprotocol Label Switching (mpls)
------------------------------------
Chair(s):
Vijay Srinivasan <vijay at raleigh.ibm.com>
George Swallow <swallow at cisco.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Area Advisor
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:mpls at external.cisco.com
To Subscribe: mpls-request at cisco.com
In Body: in body: subscribe
Archive: ftp://ftp.cisco.com/ftp/mpls
Description of Working Group:
Problem Statement:
Recently the use of label-swapping based forwarding ("label switching")
in conjunction with network layer routing has attracted much attention.
Several vendors have proposed techniques based on this paradigm. Among
the problems this paradigm is expected to address are the following:
1. Scalability of network layer routing
Using labels as a means to aggregate forwarding information, while
working in the presence of routing hierarchies.
2. Greater flexibility in delivering routing services
Using labels to identify particular traffic which are to receive
special services, e.g. QoS.
Using labels to provide forwarding along an explicit path different
from the one constructed by destination-based forwarding.
3. Increased performance
Using the label-swapping paradigm to optimize network performance.
4. Simplify integration of routers with cell switching based
technologies
a) making cell switches behave as peers to routers (thus reducing
the number of routing peers that a router has to maintain),
b) by making information about physical topology available to
Network Layer routing procedures, and
c) by employing common addressing, routing, and management
procedures.
High Level Requirements
1. The solution should be general with respect to data link
technologies. Specific optimizations for particular media will be
considered.
2. The solution must be compatible with existing internetwork
technologies and routing protocols.
3. The solution should be capable of operating independently of the
underlying routing protocol. It has been observed that
considerable optimizations can be achieved in some cases by small
enhancements of existing protocols. Such enhancements will be
considered in the case of IETF standard routing protocols, and if
appropriate, coordinated with the relevant working group.
4. The solution should support a wide range of forwarding
granularities associated with a given label, from a single
application flow to a group of topologically related destinations.
5. The solution should support operations, administration, and
maintenance facilities at least as extensive as those supported in
IP networks.
6. Routing protocols that could be used in conjuction with MPLS
could be based on distributed computation. As such, during routing
transients these protocols may construct forwarding paths that
contain loops. The protocols defined by MPLS must provide protocol
mechanism(s) to either prevent the formation of loops and/or
contain the amount of (networking) resources that could be consumed
due to the presence of such loops.
7. The standard must clearly state how the protocol operates in a
hierarchical network.
8. Scalability issues will be considered and analyzed. Very scalable
solutions will be sought. For example, in the case of ATM
technologies, the solution will attempt to conserve VC usage.
Charter Statement:
Currently, none of the solutions that that employ label-swapping based
forwarding ("label switching") in conjunction with network layer
routing are based on standard technology. In order to be able to
achieve the benefits of this new technology, a standard solution is
necessary.
The working group is responsible for standardizing a base technology
for using label swapping forwarding paradigm (label switching) in
conjunction with network layer routing and for the implementation of
that technology over various link level technologies, which may include
Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as
Gigabit Ethernet, etc.), Token Ring,...
This includes procedures and protocols for the distribution of labels
between routers, encapsulations, multicast considerations, use of
labels to support higher layer resource reservation and QoS mechanisms,
and definition of host behaviors.
Objectives:
1. Specify standard protocol(s) for maintenance and distribution of label
binding information to support unicast destination-based routing with
forwarding based on label-swapping.
2. Specify standard protocol(s) for maintenance and distribution of label
binding information to support multicast routing with
forwarding based on label-swapping.
3. Specify standard protocol(s) for maintenance and distribution of label
binding information to support hierarchy of routing knowledge (e.g.,
complete segregation of intra and inter-domain routing) with forwarding
based on label-swapping.
4. Specify standard protocol(s) for maintenance and distribution of label
binding information to support explicit paths different from the one
constructed by destination-based forwarding with forwarding based on
label-swapping.
5. Specify standard procedures of carrying label information over various
link level technologies.
6. Specify a standard way to use the ATM user plane
a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.)
ATM control plane and/or standard ATM hardware
b) Specify a 'label swapping' control plane
c) Take advantage of possible mods/improvements in ATM
hardware, for example the ability to merge VCs
7. Discuss support for QOS (e.g. RSVP).
8. Define standard protocol(s) to allow direct host (e.g. server)
participation.
Coordination:
The working group will coordinate its activities with other working
groups as appropriate.
Goals and Milestones:
Mar 97 Produce Framework Document Internet-Draft to contain goals with
detailed motivations and description of solution space,
possible approaches
May 97 Submit Framework Document to IESG (Informational RFC)*
May 97 Freeze Internet Draft for carrying label information over
serial lines (p2p links) and over LAN media (e.g., Ethernet,
Token Ring, FDDI)
Jun 97 Submit Achitecture Document to IESG (Informational RFC)
Aug 97 Submit specifications for the protocol to distribute label
binding information for unicast routes to IESG (Standards
Track)
Oct 97 Submit specifications for handling label binding information
(including distribution of this information) for multicast
routes to IESG (Standards Track)
Dec 97 Submit specifications for Operation over ATM to IESG (Standards
Track)
Dec 97 Submit specifications for carrying label information over
serial lines (p2p links) and over LAN media (e.g., Ethernet,
Token Ring, FDDI) to IESG (Standards Track)
Apr 98 Submit procedures for Host Behavior to IESG (Standards Track)
Apr 98 AD review status of WG efforts and determine whether to close
down or not. If not, identify next set of milestones.
Received: from ietf.org by ietf.org id aa07869; 3 Mar 97 16:09 EST
Received: from hiway1.exit109.com by ietf.org id aa07739; 3 Mar 97 16:07 EST
Received: from ppp70-rb.exit109.com (ppp3-rb.exit109.com [205.164.176.130]) by hiway1.exit109.com (8.8.5/8.7.3) with SMTP id QAA17993; Mon, 3 Mar 1997 16:04:39 -0500 (EST)
Received: by ppp70-rb.exit109.com with Microsoft Mail
id <01BC27EC.84AB1160 at ppp70-rb.exit109.com>; Mon, 3 Mar 1997 16:04:05 -0500
Message-ID: <01BC27EC.84AB1160 at ppp70-rb.exit109.com>
Sender:ietf-request at ietf.org
From: "Herman R. Silbiger" <hsilbiger at hiway1.exit109.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>, 'Jon Davis' <mackie at winternet.com>
Subject: RE: MUX Modems (was Re: RFC 1990)
Date: Mon, 3 Mar 1997 15:56:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Jon, =20
I suggest that you look at ITU-T Recommendation V.70 (08/96) - =
Procedures for the simultaneous transmission of data and digitally =
encoded voice signals over the GSTN, or over 2-wire leased =
point-to-point telephone type circuits. This standard describes digital =
simultaneous voice and data (DSVD) modems based on the V.34 modem using =
multiplexing and control techniques for use on the switched telephone =
network. Some of these DSVD modems are already commercially available. =
A related standard for a procedure using V.70 for transmitting =
simultaneous voice and facsimile (T.svf) is slated for approval in =
October, 1997.
Herman R. Silbiger
Principal,
APPLICOM
Application and Communication Consultants
T: +1 908 542 1916
F: +1 908 542 5041
hsilbiger at exit109.com
----------
From: Jon Davis[SMTP:mackie at winternet.com]
Sent: Monday, March 03, 1997 1:12 PM
To: ietf at ietf.org
Subject: MUX Modems (was Re: RFC 1990)
I'm a student, not a company. What I'm doing is trying to speculate a
similar (but more basic and more broadly supported) "implementation" so =
to
speak of a single mux modem. Please see
http://www.interact-net.com/think/mux/MUXMODEM.html (and note that I'm =
20
years old, somewhat unfamiliar with low-level networking technospeak, =
and I
had not read RFC 1990 at the time the mux modem model web page above was
produced). It's not an original concept, but it amazes me that modem
companies are not considering the support of multiplexing technology =
over
POTS connections. Forget the requirement of server-side compatibility
keeping it from happening, if US Robotics can successfully pull off x2,
they should be able to successfully pull off POTS multiplexing.
The mux modem model, therefore, would allow the average consumer to come
home with a single modem, plug it in, do basic software-based =
configuration
(plug-n-play), and connect to the Internet or BBS or a friend's computer =
at
twice the bandwidth. The idea here is obviously not multiplexing, which
has been around for decades--maybe as long as a century or more--but =
rather
*single POTS device* and its *marketability for the average consumer*.
I need professional comments on this (as I merely an internet
junkie/hobbiest). Should I study networking technology more and keep
working on this, or am I wasting my time? And why?
Thanks,
Jon
"Perry E. Metzger" <perry at piermont.com> wrote in article
<199702281522.KAA11728 at jekyll.piermont.com>...
>
> Jon Davis writes:
> > Does anyone know where I can get an overview of RFC 1990 written in
PLAIN
> > ENGLISH? I realize it's a technical outline and should only expect =
it
to
> > be written in technical terms, but I was just wondering if anyone
bothered
> > to try to rephrase the article in a clearer presentation than at
> > http://www.neda.com/rfc/rfc1990.txt
>
> It seems pretty reasonable to read to me. If you are having trouble
> with it, maybe you should hire a consultant to help you doing your
> implementation.
>
> Perry
>
Received: from ietf.org by ietf.org id aa12134; 3 Mar 97 16:58 EST
Received: from cnri by ietf.org id aa11885; 3 Mar 97 16:56 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa16889; 3 Mar 97 16:56 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21292 for <@sgi.engr.sgi.com:ietf at nri.reston.va.us>; Mon, 3 Mar 1997 13:54:03 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA16441 for ietf at nri.reston.va.us; Mon, 3 Mar 1997 14:53:54 -0700
Date: Mon, 3 Mar 1997 14:53:54 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199703032153.OAA16441 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: don't shoot the messenger
Source-Info: From (or Sender) name not authenticated.
> From: Mark Crispin <MRC at panda.com>
> ...
> > It uses the same mechanism that it
> > always has: "If you don't cooperate I, at least, won't talk to you."
>
> This is a relatively recent phenomenum. In the past, abuse complaints went to
> DCA, who would call the offender on the carpet (as in "show cause why the
> order to pull the plug on your net connection in 4 hours should be reversed").
While that is true of IP connectivity, it is not true of netnews and
UUCP. In that other universe, "go away if you won't play fair" has
been the basic mechanism since the early 1980's.
Even in the ancient IP days, such purely peer-to-peer sanctions were
also used. What is a password for FTP or Telnet except a way to
identify the other guy, and what is killing the connection without the
right password except a form of "play by the rules or a I won't play
with you"?
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa14808; 3 Mar 97 17:39 EST
Received: from cnri by ietf.org id aa14592; 3 Mar 97 17:37 EST
Received: from research.circ.gwu.edu by CNRI.Reston.VA.US id aa17650;
3 Mar 97 17:37 EST
Received: from gwis2.circ.gwu.edu (root at gwis2.circ.gwu.edu [128.164.127.252]) by research.circ.gwu.edu (8.8.4/8.6.12) with ESMTP id RAA20044; Mon, 3 Mar 1997 17:33:58 -0500 (EST)
Received: from nimbus ([128.164.12.176]) by gwis2.circ.gwu.edu (8.8.4/8.6.12) with SMTP id RAA04910; Mon, 3 Mar 1997 17:34:24 -0500 (EST)
Message-ID: <331B504A.118F at gwis2.circ.gwu.edu>
Date: Mon, 03 Mar 1997 17:27:22 -0500
Sender:ietf-request at ietf.org
From: Marylin Krupsaw <seap at gwis2.circ.gwu.edu>
Reply-To: seap at gwis2.circ.gwu.edu
Organization: Science & Engineering Apprentice Program
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: ietf at CNRI.Reston.VA.US
CC: seap at gwis2..circ.gwu.edu
Subject: firewalls
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I'm a student at GWU doing research on firewalls. Please send any
information you have that will help me in assessing how safe firewalls
are for protection. Are firewalls enough to keep hackers and the likes
out.
Received: from ietf.org by ietf.org id aa15243; 3 Mar 97 17:48 EST
Received: from ietf.ietf.org by ietf.org id aa15096; 3 Mar 97 17:45 EST
To: IETF-Announce: ;
Subject: IETF PGP Key Signing Party announcement
Sender:ietf-announce-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Mon, 03 Mar 1997 17:45:17 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703031745.aa15096 at ietf.org>
Once again, we will be holding a PGP Key signing party at the IETF
meeting in Memphis. We have been scheduled to meet at 2230 (10:30pm) on
the evening of Wednesday, April 9, 1997, in the Lansdown room. The
procedure we will use is the following:
o People who wish to participate should email an ASCII extract of their
PGP public key to <tytso at mit.edu> by 6:00pm on Wednesday of the week
of the IETF meeting. Please include a subject line of "IETF PGP
KEY".
Sending your key to me before the IETF meeting is appreciated, since
it reduces the number of keys that I have to collect during the
meeting. (In fact, why don't you send me your key right now if you
know will be attending, so you won't forget?)
o By 10pm on Wednesday, you will be able to ftp a complete key ring
from tsx-11.mit.edu with all of the keys that were submitted; it will
be in the file /pub/tytso/ietf.asc and /pub/tytso/ietf.pgp.
o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP
public key; we will have handouts with all of the key fingerprints of
the keys that people have mailed in.
o In turn, readers at the front of the room will recite people's keys;
as your key fingerprint is read, stand up, and at the end of reading
of your PGP key fingerprint, acknowledge that the fingerprint as read
was correct.
o Later that evening, or perhaps when you get home, you can sign the
keys corresponding to the fingerprints which you were able to verify
on the handout; note that it is advisable that you only sign keys of
people when you have personal knowledge that the person who stood up
during the reading of his/her fingerprint really is the person which
he/she claimed to be.
o Submit the keys you have signed to the PGP keyservers. A good one to
use is the one at MIT: simply send mail containing the ascii armored
version of your PGP public key to <pgp at pgp.mit.edu>.
Note that you don't have to have a laptop with you; if you don't have
any locally trusted computing resources during the key signing party,
you can make notes on the handout, and then take the handout home and
sign the keys later.
- Ted
Received: from ietf.org by ietf.org id aa20313; 3 Mar 97 19:10 EST
Received: from cnri by ietf.org id aa20199; 3 Mar 97 19:08 EST
Received: from interlock.mgh.com by CNRI.Reston.VA.US id aa19392;
3 Mar 97 19:08 EST
Received: by interlock.mgh.com id AA26843
(InterLock SMTP Gateway 3.0 for ietf at CNRI.Reston.VA.US);
Mon, 3 Mar 1997 19:04:38 -0500
Message-Id: <199703040004.AA26843 at interlock.mgh.com>
Received: by interlock.mgh.com (Protected-side Proxy Mail Agent-1);
Mon, 3 Mar 1997 19:04:38 -0500
Date: Mon, 03 Mar 97 18:33:57 edt
Sender:ietf-request at ietf.org
From: dnewman at mcgraw-hill.com
To: ietf at CNRI.Reston.VA.US
Cc: seap at gwis2..circ.gwu.edu
Subject: Re: firewalls
Source-Info: From (or Sender) name not authenticated.
Sean,
As with all things in engineering, the answer is "it depends." Most
commercial firewalls, when configured properly, do an excellent job of
repelling well-known forms of attack. But that is not the same thing
as saying a network is safe. New attacks are invented all the time,
firewalls are often misconfigured, and disgruntled or unwitting users
may find ways to circumvent a firewall altogether.
This is a complex area, but there are good many good resources
available. The two standard references are "Repelling the Wily
Hacker," by Cheswick and Bellovin (Addison-Wesley), and "Building
Internet Firewalls" by Chapman and Zwicky (O'Reilly and Associates).
I'd also recommend subscribing to the firewalls-digest mailing list
maintained by Brent Chapman. It has a pretty bad signal-to-noise ratio
(lots of pointless religious debate about OSs) but the good stuff
there is very good indeed. To sign up, send e-mail to
majordomo at greatcircle.com with the text "subscribe firewalls-digest"
in the body of the message.
Regards
David Newman
Data Communications magazine
______________________________ Reply Separator _________________________________
Subject: firewalls
Author: seap at gwis2.circ.gwu.edu at CCNODE
Date: 3/3/97 6:00 PM
I'm a student at GWU doing research on firewalls. Please send any
information you have that will help me in assessing how safe firewalls
are for protection. Are firewalls enough to keep hackers and the likes
out.
Received: from ietf.org by ietf.org id aa20470; 3 Mar 97 19:12 EST
Received: from cnri by ietf.org id aa20419; 3 Mar 97 19:12 EST
Received: from interlock.mgh.com by CNRI.Reston.VA.US id aa19484;
3 Mar 97 19:12 EST
Received: by interlock.mgh.com id AA26505
(InterLock SMTP Gateway 3.0 for ietf at CNRI.Reston.VA.US);
Mon, 3 Mar 1997 18:59:41 -0500
Message-Id: <199703032359.AA26505 at interlock.mgh.com>
Received: by interlock.mgh.com (Protected-side Proxy Mail Agent-1);
Mon, 3 Mar 1997 18:59:41 -0500
Date: Mon, 03 Mar 97 18:33:57 edt
Sender:ietf-request at ietf.org
From: dnewman at mcgraw-hill.com
To: ietf at CNRI.Reston.VA.US
Cc: seap at gwis2..circ.gwu.edu
Subject: Re: firewalls
Source-Info: From (or Sender) name not authenticated.
Sean,
As with all things in engineering, the answer is "it depends." Most
commercial firewalls, when configured properly, do an excellent job of
repelling well-known forms of attack. But that is not the same thing
as saying a network is safe. New attacks are invented all the time,
firewalls are often misconfigured, and disgruntled or unwitting users
may find ways to circumvent a firewall altogether.
This is a complex area, but there are good many good resources
available. The two standard references are "Repelling the Wily
Hacker," by Cheswick and Bellovin (Addison-Wesley), and "Building
Internet Firewalls" by Chapman and Zwicky (O'Reilly and Associates).
I'd also recommend subscribing to the firewalls-digest mailing list
maintained by Brent Chapman. It has a pretty bad signal-to-noise ratio
(lots of pointless religious debate about OSs) but the good stuff
there is very good indeed. To sign up, send e-mail to
majordomo at greatcircle.com with the text "subscribe firewalls-digest"
in the body of the message.
Regards
David Newman
Data Communications magazine
______________________________ Reply Separator _________________________________
Subject: firewalls
Author: seap at gwis2.circ.gwu.edu at CCNODE
Date: 3/3/97 6:00 PM
I'm a student at GWU doing research on firewalls. Please send any
information you have that will help me in assessing how safe firewalls
are for protection. Are firewalls enough to keep hackers and the likes
out.
Received: from ietf.org by ietf.org id aa24122; 3 Mar 97 20:32 EST
Received: from cnri by ietf.org id aa23998; 3 Mar 97 20:27 EST
Received: from m3.sprynet.com by CNRI.Reston.VA.US id aa20450;
3 Mar 97 20:27 EST
Received: from jjones (host-159-49.UB.com [128.203.159.49]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id RAA07873; Mon, 3 Mar 1997 17:24:53 -0800
Message-ID: <331B79AF.BCE at sprynet.com>
Date: Mon, 03 Mar 1997 20:23:59 -0500
Sender:ietf-request at ietf.org
From: Jeff Jones <jdjones at sprynet.com>
Reply-To: jdjones at sprynet.com
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: seap at gwis2.circ.gwu.edu
CC: ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
References: <331B504A.118F at gwis2.circ.gwu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Marylin Krupsaw wrote:
>
> I'm a student at GWU doing research on firewalls. Please send any
> information you have that will help me in assessing how safe firewalls
> are for protection. Are firewalls enough to keep hackers and the likes
> out.
>
dnewman at mcgraw-hill.com had some good advice for you. I would add to
that some other thoughts. IMHO, no firewall is 100%. Therefore, there
exists some probability that with any firewall you choose, someone can
get through it. The point, from a security rather than systems view, is
to create a higher path of resistance through your firewall than through
other means.
Firewalls, properly applied (and this takes a thorough plan and
knowledge of the firewall and the system you are trying to protect),
create a very difficult and almost (but not quite) impenetrable point of
entry. Keep in mind what the hacker is looking for.
A. To increase his/her self-esteem by cracking your fortress
B. Espionage (industrial, technological, governmental, etc.) to gain
what you have or cripple your system,
C. Extreme emotional motivation (e.g. revenge of the formerly employed)
A is very rare, but if bright and knowledgable enough, can get through
any firewall. The probability is very low unless your system is a
high-profile system (to help him/her gain notoriety). For example, I
walked into a federal building today, and saw the IP address of a data
server from a terminal being displayed while talking to a clerk.
Knowing that IP address, it becomes infinitely easier to find a way in.
I could tell from the program how they accessed it (Telnet). I did not
write down the address or try to get in because I do not want to spend
time in jail. But it illustrates how very easy some systems people make
it.
B is more likely to go the low tech route, such as gaining access to
your facility as a trojan horse (cleaning person, repairman, etc.) or if
the stakes are high enough, to bribe late night workers (generally
cheaper than paying a hacker).
C is the most dangerous, because they are more likely to know your
system. The best firewall in the world doesn't help if the systems
people are slow to disable remote access. And you would be suprised at
how often administrator passwords are shared discreetly, and find their
way to non-systems people.
Sometimes these profiles are combined in a given individual.
Therefore, when looking for an answer to your question, see the firewall
not as the protection, but as one very important part in an overall
security strategy. Some firewalls may offer marginally better
protection, but not integrate as well as others into an overall security
scheme. One firewall may be the 99% solution, and another the 98%
solution, but the 98% solution, if it worksd better with the existing
systems, system support, and overall security system, would be better
than the 99% solution.
Good luck.
Jeff Jones
Services Manager, CSMC Atlanta
UB Networks
--
=====================================
"He is no fool who gives up what
he cannot keep to gain that
which he cannot lose." - Jim Elliot
=====================================
jdjones at sprynet.com
Received: from ietf.org by ietf.org id aa11800; 4 Mar 97 4:35 EST
Received: from cnri by ietf.org id aa11246; 4 Mar 97 4:25 EST
Received: from sonne.darmstadt.gmd.de by CNRI.Reston.VA.US id aa04039;
4 Mar 97 4:25 EST
Received: from libra.darmstadt.gmd.de (libra [141.12.35.17]) by sonne.darmstadt.gmd.de (8.8.5/8.8.2) with ESMTP id KAA21436; Tue, 4 Mar 1997 10:23:00 +0100 (MET)
Received: from libra (localhost [127.0.0.1]) by libra.darmstadt.gmd.de (8.7.3/8.7.3) with SMTP id KAA27317; Tue, 4 Mar 1997 10:13:52 +0100 (MET)
X-Orig-Sender: schneiw at darmstadt.gmd.de
Message-ID: <331BE7CF.409A at darmstadt.gmd.de>
Date: Tue, 04 Mar 1997 10:13:51 +0100
Sender:ietf-request at ietf.org
From: Wolfgang Schneider <schneiw at darmstadt.gmd.de>
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: seap at gwis2.circ.gwu.edu
CC: ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
References: <331B504A.118F at gwis2.circ.gwu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Marylin,
we prepared an extensive report on firewall technology in the European
ICE-TEL project. You'll find it in
http://www.darmstadt.gmd.de/ice-tel/deliverables
Regards
Wolfgang Schneider
Marylin Krupsaw wrote:
>
> I'm a student at GWU doing research on firewalls. Please send any
> information you have that will help me in assessing how safe firewalls
> are for protection. Are firewalls enough to keep hackers and the likes
> out.
Received: from ietf.org by ietf.org id aa20244; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18589; 4 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-duerst-ruby-01.txt
Date: Tue, 04 Mar 1997 09:49:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18589 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Ruby in the Hypertext Markup Language
Author(s) : M. Duerst
Filename : draft-duerst-ruby-01.txt
Pages : 7
Date : 03/03/1997
The Hypertext Markup Language (HTML) is a markup language used to create
hypertext documents that are platform independent. Initially HTML was
designed primarily for Western European languages; most of the issues of
basic internationalization to make HTML better usable for other languages
have in the meantime been addressed. Ruby are important phonetic
annotations used mainly for ideographic characters in East Asia. This
document proposes markup for ruby in HTML and explains its usage.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-duerst-ruby-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-duerst-ruby-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-duerst-ruby-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303110109.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-duerst-ruby-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-duerst-ruby-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303110109.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20258; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19322; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-actng-00.txt
Date: Tue, 04 Mar 1997 10:01:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19322 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Accounting Problem in Roaming
Author(s) : B. Aboba
Filename : draft-ietf-roamops-actng-00.txt
Pages : 13
Date : 03/03/1997
This document describes the accounting problems that arise in the provision
of inter-provider services, such as provision of dialup roaming
capabilities. These include issues relating to standardization of
accounting record formats, and inter-provider transfers of accounting
record bundles. Work relevant to the solution of these problems are
reviewed, and recommendations are made on the direction of future
standardization work.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-actng-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-actng-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-actng-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303134501.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-actng-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-actng-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303134501.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20249; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19230; 4 Mar 97 10:00 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-v6exts-05.txt
Date: Tue, 04 Mar 1997 10:00:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041000.aa19230 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Extensions for DHCPv6
Author(s) : C. Perkins
Filename : draft-ietf-dhc-v6exts-05.txt
Pages : 22
Date : 03/03/1997
The Dynamic Host Configuration Protocol for IPv6 [3] (DHCPv6) provides a
framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are
carried in typed data items that are stored in the "extensions" field of
the DHCPv6 message. The data items themselves are also called
"extensions."
This document specifies the current set of DHCPv6 extensions. This
document will be periodically updated as new extensions are defined. Each
superseding document will include the entire current list of valid
extensions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-v6exts-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-v6exts-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-v6exts-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303133039.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-v6exts-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-v6exts-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303133039.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20260; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18638; 4 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-lewis-dnskey-handling-00.txt
Date: Tue, 04 Mar 1997 09:49:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18638 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Zone KEY RRSet Signing Procedure
Author(s) : E. Lewis, O. Gudmundsson
Filename : draft-lewis-dnskey-handling-00.txt
Pages : 7
Date : 03/03/1997
Under the security extensions to DNS, as defined in RFC 2065 and
draft-ietf-dnssec-update-04.txt, a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. This document
covers the manner in which this RRSet is generated, signed, and inserted
into the name servers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-lewis-dnskey-handling-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lewis-dnskey-handling-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lewis-dnskey-handling-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303125934.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lewis-dnskey-handling-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lewis-dnskey-handling-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303125934.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20263; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18661; 4 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: hubmib at hprnd.rose.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-hubmib-mau-mib-04.txt
Date: Tue, 04 Mar 1997 09:50:04 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040950.aa18661 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IEEE 802.3 Hub MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs) using SMIv2
Author(s) : K. De Graaf, D. Romascanu, D. McMaster,
K. McCloghrie, S. Roberts
Filename : draft-ietf-hubmib-mau-mib-04.txt
Pages : 48
Date : 03/03/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing 10 and 100
Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section
30, "10 & 100 Mb/s Management," October 26, 1995.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-hubmib-mau-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-hubmib-mau-mib-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-hubmib-mau-mib-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303130344.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-hubmib-mau-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-hubmib-mau-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303130344.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20265; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18678; 4 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldap-rpcschema-00.txt
Date: Tue, 04 Mar 1997 09:50:16 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040950.aa18678 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol: Schema for
Storing RPC Entries in a Directory Service
Author(s) : S. Judd, S. Thatte, P. Leach, W. Hopkins
Filename : draft-ietf-asid-ldap-rpcschema-00.txt
Pages : 11
Date : 03/03/1997
The Lightweight Directory Access Protocol [1][2] defines a standard
protocol for accessing diverse directory services. One common use of a
directory service is the location of application services, among which are
RPC services.
This document defines a set of object classes and attributes for storing
metadata and binding information for RPC services that are DCE-compliant
or closely follow the DCE model, in directories that support LDAP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldap-rpcschema-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-rpcschema-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldap-rpcschema-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303131123.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldap-rpcschema-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldap-rpcschema-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303131123.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20264; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19371; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-mib-01.txt
Date: Tue, 04 Mar 1997 10:01:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19371 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Definitions of Managed Objects for Classical IP and ARP
Over ATM Using SMIv2
Author(s) : M. Greene, J. Luciani, K. White, T. Kuo
Filename : draft-ietf-ion-mib-01.txt
Pages : 34
Date : 03/03/1997
The purpose of this memo is to define the Management Information Base (MIB)
for supporting Classical IP and ARP over ATM as specified in Classical IP
and ARP over ATM, refer to reference [3]. Support of an ATM interface by an
IP layer will require implementation of objects from several Managed
Information Bases (MIBs) as well as their enhancement in order to enable
usage of ATM transports. It is the intent of this MIB to fully adhere to
all prerequisite MIBs unless explicitly stated. Deviations will be
documented in corresponding conformance statements. The specification of
this MIB will utilize the Structure of Management Information (SMI) for
Version 2 of the Simple Network Management Protocol Version (refer to
RFC1902, reference [1]).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303141517.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303141517.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20268; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18720; 4 Mar 97 9:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-dhcpv6-09.txt
Date: Tue, 04 Mar 1997 09:50:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040951.aa18720 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Author(s) : J. Bound, C. Perkins
Filename : draft-ietf-dhc-dhcpv6-09.txt
Pages : 38
Date : 03/03/1997
The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for
passing configuration information, via extensions, to IPv6 nodes. It
offers the capability of automatic allocation of reusable network addresses
and additional configuration flexibility. This protocol should be
considered a stateful counterpart to the IPv6 Stateless Address
Autoconfiguration protocol specification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-dhcpv6-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcpv6-09.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-dhcpv6-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303132707.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcpv6-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcpv6-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303132707.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20261; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa19438; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-madman-mail-monitor-mib-03.txt
Date: Tue, 04 Mar 1997 10:01:29 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19438 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : Mail Monitoring MIB
Author(s) : N. Freed
Filename : draft-ietf-madman-mail-monitor-mib-03.txt
Pages : 32
Date : 03/03/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.
Specifically, this memo extends the basic Network Services Monitoring MIB
[8] to allow monitoring of Message Transfer Agents (MTAs). It may also be
used to monitor MTA components within gateways.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-madman-mail-monitor-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-mail-monitor-mib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-madman-mail-monitor-mib-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303143542.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-mail-monitor-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-mail-monitor-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303143542.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20270; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18609; 4 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pktway at myri.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pktway-protocol-spec-03.txt
Date: Tue, 04 Mar 1997 09:49:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18609 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the PacketWay Working Group of
the IETF.
Title : Proposed Specification for the PacketWay Protocol
Author(s) : D. Cohen, C. Lund, T. Skjellum,
T. McMahon, R. George
Filename : draft-ietf-pktway-protocol-spec-03.txt
Pages : 37
Date : 03/03/1997
PacketWay's goal is to move data from a "Source" (a node on a System Area
Network) to a "Destination" (another node, probably on another System Area
Network) at the high performance available on these SANs. Sources and
Destinations can be physical things (a processor or a smart memory board).
They can also be "logical" things, such as a group of cooperating
processes.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pktway-protocol-spec-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pktway-protocol-spec-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pktway-protocol-spec-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303112516.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pktway-protocol-spec-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pktway-protocol-spec-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303112516.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21150; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa19294; 4 Mar 97 10:00 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-radius at livingston.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-radius-tunnel-imp-00.txt
Date: Tue, 04 Mar 1997 10:00:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041000.aa19294 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : Implementation of Mandatory Tunneling via RADIUS
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-radius-tunnel-imp-00.txt
Pages : 17
Date : 03/03/1997
This document discusses implementation issues arising in the provisioning
of mandatory tunneling in dial-up networks using the PPTP and L2TP
protocols. This provisioning may be accomplished via the integration of
RADIUS and tunneling protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-tunnel-imp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-imp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-tunnel-imp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303134140.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-tunnel-imp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-tunnel-imp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303134140.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21179; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20409; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-freed-smtp-pipeline-01.txt
Date: Tue, 04 Mar 1997 10:08:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20409 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extension for Command Pipelining
Author(s) : N. Freed
Filename : draft-freed-smtp-pipeline-01.txt
Pages : 9
Date : 03/03/1997
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-freed-smtp-pipeline-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-freed-smtp-pipeline-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-freed-smtp-pipeline-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303145546.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-freed-smtp-pipeline-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-freed-smtp-pipeline-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303145546.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab21150; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa19355; 4 Mar 97 10:01 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-01.txt
Date: Tue, 04 Mar 1997 10:01:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041001.aa19355 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (RR) Record in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-01.txt
Pages : 15
Date : 03/03/1997
This document describes the use of the Roaming Relationship (RR) record in
the DNS for the description of roaming relationships. In the absence of DNS
security, RR records may be used for determining the existence of a roaming
relationship path between the local ISP and the user's home domain, as well
as the location of an appropriate accounting agent. However, since the RR
records are not secured, other methods (such as hierarchical authentication
routing) must be used in order to validate the roaming relationship path.
When DNS security is implemented, the roaming relationship path is
authenticated via digital signatures, and as a result, additional services
may be provided, such as non-repudiation of proxied authentications and
signed receipts for accounting record transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-dnsrr-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303140946.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303140946.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21344; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20471; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-fqdn-opt-02.txt
Date: Tue, 04 Mar 1997 10:08:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20471 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : An option for FQDNs in DHCP options
Author(s) : Y. Rekhter, R. Droms
Filename : draft-ietf-dhc-fqdn-opt-02.txt
Pages : 4
Date : 03/03/1997
DHCP [DHCP] can be used to automate the process of configuring TCP/IP host
computers. However, some of the DHCP options carry IP addresses rather
than Fully Qualified Domain Names (FQDN). Use of IP addresses constrains
the DHCP client to use the addresses that were in use at the time the
client received its configuration information; these addresses may change
over time, (e.g., a server may be assigned a new IP address), so that the
IP addresses used by the client may become invalid.
An alternative to passing IP addresses is to pass FQDNs instead of
(numeric) IP addresses. Doing this allows to defer binding between a
particular network entity (e.g., a server) and its IP address until run
time. As stated in [Carpenter:96], "Deferring the binding avoids the risk
of changed mapping between IP addresses and specific network entities (due
to changing addressing information). Moreover, reliance on FQDNs (rather
than IP addresses) also localizes to the DNS the changes needed to deal
with changing addressing information due to renumbering."
This document defines a new DHCP option that allows the use of FQDNs
instead of IP addresses in DHCP options.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-fqdn-opt-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-fqdn-opt-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-fqdn-opt-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303170819.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-fqdn-opt-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-fqdn-opt-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303170819.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21436; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20436; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rosen-tag-stack-01.txt
Date: Tue, 04 Mar 1997 10:08:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20436 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Label Switching: Label Stack Encodings
Author(s) : E. Rosen, Y. Rekhter, D. Tappan,
D. Farinacci, G. Fedorkow
Filename : draft-rosen-tag-stack-01.txt
Pages : 17
Date : 03/03/1997
"Label Switching" [1] requires a set of procedures for augmenting network
layer packets with "Label Stacks" (formerly called "Tag Stacks"), thereby
turning them into "Labeled packets". This document specifies the encoding
to be used, on PPP data links and LAN data links, in order to produce a
Labeled packet from a Label Stack and a network layer packet.
This document also specifies rules and procedures for processing the
various fields of the Label Stack encoding.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rosen-tag-stack-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rosen-tag-stack-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rosen-tag-stack-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303152448.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rosen-tag-stack-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rosen-tag-stack-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303152448.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20262; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18612; 4 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-02.txt
Date: Tue, 04 Mar 1997 09:49:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18612 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : The Internet IP Security Domain of Interpretation
for ISAKMP
Author(s) : D. Piper
Filename : draft-ietf-ipsec-ipsec-doi-02.txt
Pages : 20
Date : 03/03/1997
The Internet Security Association and Key Management Protocol (ISAKMP)
defines a framework for security association management and cryptographic
key establishment for the Internet. This framework consists of defined
exchanges and processing guidelines that occur within a given Domain of
Interpretation (DOI). This document details the Internet IP Security DOI,
which is defined to cover the IP security protocols that use ISAKMP to
negotiate their security associations.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ipsec-doi-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303120116.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ipsec-doi-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303120116.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20259; 4 Mar 97 10:10 EST
Received: from ietf.ietf.org by ietf.org id aa18572; 4 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-floyd-distributed-search-01.txt
Date: Tue, 04 Mar 1997 09:49:31 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703040949.aa18572 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Distributed Search Management Protocol
Author(s) : J. Floyd
Filename : draft-floyd-distributed-search-01.txt
Pages : 15
Date : 03/03/1997
There are a number of instances in which the search for a particular value
(for instance, a cryptographic key) can be distributed across a large
number of machines, however there is not currently a standard protocol for
doing so. A great many algorithms may be used for searches; because these
algorithms may differ greatly, the protocol used must be flexible enough to
be easily extended.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-floyd-distributed-search-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-floyd-distributed-search-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-floyd-distributed-search-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303100406.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-floyd-distributed-search-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-floyd-distributed-search-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303100406.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21439; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20376; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-freed-pvcsc-02.txt
Date: Tue, 04 Mar 1997 10:08:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20376 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Parameter Value and Encoded Word Extensions:
Character Sets, Languages, and Continuations
Author(s) : N. Freed, K. Moore
Filename : draft-freed-pvcsc-02.txt
Pages : 10
Date : 03/03/1997
This memo defines extensions to the RFC 2045 media type and RFC CDISP
disposition parameter value mechanisms to provide (1) a means to specify
parameter values in character sets other than US-ASCII, (2) to specify
the language to be used should the value be displayed, and (3)
a continuation mechanism for long parameter values to avoid
problems with header line wrapping.
This memo also defines an extension to the encoded words defined in RFC
2047 to allow the specification of the language to be used for display as
well as the character set.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-freed-pvcsc-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-freed-pvcsc-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-freed-pvcsc-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303145238.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-freed-pvcsc-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-freed-pvcsc-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303145238.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21481; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20498; 4 Mar 97 10:09 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: frs-mib at newbridge.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-frnetmib-dcp-00.txt
Date: Tue, 04 Mar 1997 10:09:02 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041009.aa20498 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Frame Relay Service MIB
Working Group of the IETF.
Title : Management Information Base for Frame Relay DTE
Extensions for Data Compression over Frame Relay
Author(s) : M. Kashef, J. Colom
Filename : draft-ietf-frnetmib-dcp-00.txt
Pages : 8
Date : 03/03/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Data Compression over a Frame
Relay virtual circuit. This memo does not specify a standard for the
Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-frnetmib-dcp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-dcp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-frnetmib-dcp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303171503.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-frnetmib-dcp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-dcp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303171503.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21473; 4 Mar 97 10:11 EST
Received: from ietf.ietf.org by ietf.org id aa20453; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-syntax-03.txt
Date: Tue, 04 Mar 1997 10:08:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20453 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Names
Working Group of the IETF.
Title : URN Syntax
Author(s) : R. Moats
Filename : draft-ietf-urn-syntax-03.txt
Pages : 7
Date : 03/03/1997
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This document sets forward the
canonical syntax for URNs. A discussion of both existing legacy and new
namespaces and requirements for URN presentation and transmission are
presented. Finally, there is a discussion of URN equivalence and how to
determine it.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-urn-syntax-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-syntax-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303164344.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-syntax-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-syntax-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303164344.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22723; 4 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa20329; 4 Mar 97 10:08 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-madman-nsm-mib-04.txt
Date: Tue, 04 Mar 1997 10:08:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703041008.aa20329 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : Network Services Monitoring MIB
Author(s) : N. Freed
Filename : draft-ietf-madman-nsm-mib-04.txt
Pages : 22
Date : 03/03/1997
A networked application is a realization of some well defined service on
one or more host computers that is accessible via some network, uses some
network for its internal operations, or both.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-madman-nsm-mib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-nsm-mib-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-madman-nsm-mib-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970303144906.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-nsm-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-nsm-mib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970303144906.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29555; 4 Mar 97 11:25 EST
Received: from ietf.ietf.org by ietf.org id aa29194; 4 Mar 97 11:21 EST
To: ietf at ietf.org
Subject: Re: Forging subscriptions - was Re: Remove us from the mailing list
Sender:ietf-request at ietf.org
From: Frank de Lange <frank at animalhouse.ml.org>
Date: Tue, 04 Mar 1997 11:21:21 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703041121.aa29194 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
> >Forging people's names on subscriptions to mailing lists is becoming a
> >daily occurance....
>
> Just a thought, not to start a deep technical thread on the general list.
>
> Without being able to authenicate the subscription requestor (at this
> time), could a tape-and-glue fix be as simple as: when a request for
> subscription is received, a confirmation is requested (i.e., in a mail
> message to the subscribing address), and until a returned confirmation is
> received, the subscription is not made? I've heard that this approach is
> being used with at least one (non-IETF) mail list.
>
> A forger would have to be in the path of the forged address to see the
> confirmation message. To prevent predicatability of the confirmation a
> somewhat random phrase could be used in the confirmation request and reply.
This does indeed work, a mechanism like this is in use at several sites (an
example of which is ml.org (Monolith), which uses a three-way handshake to
authenticate `subscribers' to their services (free DNS listings, but the same
principle is valid in any other service).
Frank
WWWWW ___________________________
## o o\ / Frank de Lange \
}# \| / +31-70-3712708 day \
##---# _/ +31-320-252965 night \
#### \frank.de.lange at inet.unisource.nl/
\ frank.de.lange at net.info.nl /
------------------------------
Received: from ietf.org by ietf.org id aa04759; 4 Mar 97 12:21 EST
Received: from cnri by ietf.org id aa04586; 4 Mar 97 12:19 EST
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa12384;
4 Mar 97 12:19 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id MAA21708;
Tue, 4 Mar 1997 12:16:14 -0500
Message-Id: <199703041716.MAA21708 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: jdjones at sprynet.com
Cc: seap at gwis2.circ.gwu.edu, ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
In-Reply-To: Your message of "Mon, 03 Mar 1997 20:23:59 EST."
<331B79AF.BCE at sprynet.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <331B504A.118F at gwis2.circ.gwu.edu>
<331B79AF.BCE at sprynet.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1659436632P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 04 Mar 1997 12:16:13 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1659436632P
Content-Type: text/plain; charset=us-ascii
On Mon, 03 Mar 1997 20:23:59 EST, Jeff Jones said:
> entry. Keep in mind what the hacker is looking for.
> A. To increase his/her self-esteem by cracking your fortress
> B. Espionage (industrial, technological, governmental, etc.) to gain
> what you have or cripple your system,
> C. Extreme emotional motivation (e.g. revenge of the formerly employed)
>
> A is very rare, but if bright and knowledgable enough, can get through
> any firewall. The probability is very low unless your system is a
Umm.. you overlooked (D) the lamer d00d with a bunch of hacking
scriptz that he doesn't even understand, just plug-and-chug hacking
because they don't have a life. Fortunately, most of them never
graduate from category (D) to category (A), and a reasonable *and well
implemented* security policy will stop most of them. On the other
hand, I have heard from a number of sources that Kevin Mitnick's TCP
sequence number hacks were written by somebody else, and Mitnick just
social-engineered the a copy of the script for himself. So care *is*
needed.
Unfortunately, I work in a university environment, where there's a lot
of machines in departments that don't have a clue. And it's
politically impossible to require proof of clue ownership (beyond
being able to plug in a 10BaseT connector) before letting users on the
net....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_1659436632P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxxY29QBOOoptg9JAQHliwP/Y0t+CRs/p2TXDbyzegNhui4QnrFE8SYv
tfx6jUE6QDTPBr0TYHx85lfnPx37oB0oKmxX86nuKDRFeSEXuO8p6JRvthPUbAiG
aumxmXsLUbFm2WmkExuGcHA9BGTxxI6rX3Yu3sHBZvpehwlsmj3n78L4HGbf8AqC
5OdwN5/0vlY=
=wXxq
-----END PGP MESSAGE-----
--==_Exmh_1659436632P--
Received: from ietf.org by ietf.org id aa06246; 4 Mar 97 12:41 EST
Received: from cnri by ietf.org id aa06118; 4 Mar 97 12:38 EST
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa13091;
4 Mar 97 12:38 EST
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id SAA20405
; Tue, 4 Mar 1997 18:26:55 +0100 (MET)
Sender:ietf-request at ietf.org
From: 2IN97 at prism.uvsq.fr
Received: from davoult.prism.uvsq.fr (davoult.prism.uvsq.fr [193.51.25.134])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id RAA19259
for <congres>; Tue, 4 Mar 1997 17:48:43 +0100 (MET)
Message-ID: <331C5126.56FA at prism.uvsq.fr>
Date: Tue, 04 Mar 1997 17:43:18 +0100
Organization: Prism
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: congres at prism.uvsq.fr
Subject: Call for papers 2IN97
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by soleil.uvsq.fr id SAA20405
Source-Info: From (or Sender) name not authenticated.
________________________________________________________________________
We apologize for multiple copies=20
________________________________________________________________________
CALL FOR PAPERS
1997 International Conference
Intelligent Networks and Intelligence in Networks
=20
(2IN97)
Paris - France=20
September 2-5, 1997
Organizer : IFIP TC WG 6.7 - Intelligent Networks
Sponsorship requested : Alcatel, Ericsson, France Telecom, Nokia, Nordic
teleoperators, Siemens, Telecom Finland, Lab. PRiSM
Aim of the conference
To identify and study current issues related to the development of
intelligent capabilities in networks. These issues include the
development and distribution of services in broadband and mobile
networks.
This conference belongs to a series of IFIP conference on Intelligent
Network. The first one took place in Lappeeranta August 94, the second
one in Copenhagen, August 95. The proceedings of both events have been
published by Chapman&Hall.
IFIP Working Group 6.7 on IN has concentrated with the research and
development of Intelligent Networks architectures. First the activities
have concentrated in service creation, service management, database
issues, feature interaction, IN performance and advanced signaling for
broadband services. Later on the research activities have turned towards
the distribution of intelligence in networks and IN applications to
multimedia and mobility. The market issues of new services have also
been studied. From the system development point of view, topics from OMG
and TINA-C have been considered.
Main fields of interest to 2IN97:
IN Markets and trends
- Value added services market=20
- Development in telecom area
- Multimedia IN
- IN and the Internet
Standardization/integration and legacies
- Standardization aspects
- TINA
- IN and B-ISDN
- IN and mobile networks
- Intelligence in ATM networks
Service types, service architecture and=20
- Service creation, distribution and management
- IN service architecture
- Service creation architecture applied in multimedia services (voice,
data, mobile)
- Multimedia services
Tools
- Intelligent control schemes
- Multimedia call models
- Multimedia call control protocols
- Intelligent routing
- Continuous media
- Performance issues
- Intelligent agents
- Distributed artificial intelligence and multi-agent systems for
networks
- JAVA technology for IN services
IN systems and platforms
- IN architecture
- Intelligence and Network Management
- Real time data bases and caches for services
Workshop organization
Lab PRiSM (University of Versailles)
Place of the conference : French Ministry of Telecommunication, Avenue
de Segur, Paris, France
Conference chair:=20
Olli Martikainen FIN=20
Guy Pujolle F
Program committee chair :
Dominique Ga=EFti F
Program committee members
James Aitken UK
Almeida Maria J.B. BR
Andy Bihain USA
Gilles Bregant F
Carla Capellmann, GER
Christian Chabernaud F
Peter Delgado UK
Heinz Dibold GER
Jacques Ferber F
Frank Gallivan USA
Philip Ginzboorg FIN
Shri Goyal USA
Serge Haddad F
Heikki Hammainen FIN
Villy Baek Iversen DK
Bijan Jabbari USA
Jorma Jormakka FIN
Koos Koen RSA
Ulf K=F6rner S
Paul K=FChn GER
Roberto Kung F
Jacques Labetoulle F
Xuejia Lai CH
Martine Lapierre F
Kari Lautanala FIN
Aurel A. Lazar USA
Olli Martikainen FIN=20
Valeri A. Naoumov RF
Karl W. Neunast GER
Jorgen Norgaard DK
Herv=E9 Precioso F
Guy Pujolle F
Kimmo Raatikainen FIN
Konstantin E. Samouylov RF
Manfred Schneps-Schneppe RUS
Lennart S=F6derberg S
Haitao Tang CN
Organization chair :
Nadia Boukhatem F
Thierry Hua F
Important dates:
March 21, 1997: Deadline for Paper Submission
May 15, 1997: Notification of Acceptance
July 1, 1997: Final Version Due
September 2, 1997: Tutorial
September 3-5, 1997: Conference
Instructions:
Submit five copies of a full paper by March 21, 1997. Papers should be
no longer than 20 double spaced typewritten pages, including tables and
figures. The proceedings will be published by Chapman&Hall
All correspondence should be addressed:
- by email (postcript version of the paper) - 2IN97 at prism.uvsq.fr
- or by mail to
2IN97 Conference
Lab PRiSM - University of Versailles
45 av. des Etats-Unis
78035 Versailles Cedex - France
------------------------------------------------------------------------
2IN'97
1st Name: ..............................................................
Last Name:..............................................................
email:..................................................................
Title:..................................................................
Organization:...........................................................
Postal address:.........................................................
........................................................................
City:..............................Postal code:.........................
Country:................................................................
Telephone:..............................................................
Fax:....................................................................
O Topics I am interested in:............................................
O I wish to attend the ICCC'97 conference.
O I wish to present a paper and will submit a paper by March 21, 1997.=20
Title of the paper :
........................................................................
........................................................................
........................................................................
________________________________________________________________________
________________________________________________________________________
Received: from ietf.org by ietf.org id aa14344; 4 Mar 97 13:52 EST
Received: from cnri by ietf.org id aa14244; 4 Mar 97 13:50 EST
Received: from m3.sprynet.com by CNRI.Reston.VA.US id aa15070;
4 Mar 97 13:50 EST
Received: from jjones (host-159-49.UB.com [128.203.159.49]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id KAA08150; Tue, 4 Mar 1997 10:48:19 -0800
Message-ID: <331C6E3C.5BD4 at sprynet.com>
Date: Tue, 04 Mar 1997 13:47:24 -0500
Sender:ietf-request at ietf.org
From: Jeff Jones <jdjones at sprynet.com>
Reply-To: jdjones at sprynet.com
X-Mailer: Mozilla 3.0 (WinNT; I)
MIME-Version: 1.0
To: Valdis.Kletnieks at vt.edu
CC: ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
References: <331B504A.118F at gwis2.circ.gwu.edu>
<331B79AF.BCE at sprynet.com> <199703041716.MAA21708 at black-ice.cc.vt.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Valdis.Kletnieks at vt.edu wrote:
>
> On Mon, 03 Mar 1997 20:23:59 EST, Jeff Jones said:
> > entry. Keep in mind what the hacker is looking for.
> > A. To increase his/her self-esteem by cracking your fortress
> > B. Espionage (industrial, technological, governmental, etc.) to gain
> > what you have or cripple your system,
> > C. Extreme emotional motivation (e.g. revenge of the formerly employed)
> >
> > A is very rare, but if bright and knowledgable enough, can get through
> > any firewall. The probability is very low unless your system is a
>
> Umm.. you overlooked (D) the lamer d00d with a bunch of hacking
> scriptz that he doesn't even understand, just plug-and-chug hacking
> because they don't have a life. Fortunately, most of them never
> graduate from category (D) to category (A), and a reasonable *and well
> implemented* security policy will stop most of them. On the other
> hand, I have heard from a number of sources that Kevin Mitnick's TCP
> sequence number hacks were written by somebody else, and Mitnick just
> social-engineered the a copy of the script for himself. So care *is*
> needed.
>
> Unfortunately, I work in a university environment, where there's a lot
> of machines in departments that don't have a clue. And it's
> politically impossible to require proof of clue ownership (beyond
> being able to plug in a 10BaseT connector) before letting users on the
> net....
>
> --
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
>
> ---------------------------------------------------------------
>
> Part 1.2 Type: application/pgp-signature
--
I agree - I guess I just lumped D's with A's - an insult to A's
everywhere. Consider me dutifully penitent.
Jeff Jones
=====================================
"He is no fool who gives up what
he cannot keep to gain that
which he cannot lose." - Jim Elliot
=====================================
jdjones at sprynet.com
Received: from ietf.org by ietf.org id aa14343; 4 Mar 97 13:52 EST
Received: from cnri by ietf.org id aa13904; 4 Mar 97 13:49 EST
Received: from postbox.dai.ed.ac.uk by CNRI.Reston.VA.US id aa15040;
4 Mar 97 13:49 EST
Received: from sole (sole.dai.ed.ac.uk [192.41.107.4]) by postbox.dai.ed.ac.uk (8.6.13/8.6.12) with ESMTP id SAA06568; Tue, 4 Mar 1997 18:36:29 GMT
Sender:ietf-request at ietf.org
From: michael at dai.ed.ac.uk
Date: Tue, 4 Mar 1997 18:34:31 GMT
Message-Id: <7578.199703041834 at sole>
To: BENKING at faw.uni-ulm.de, E.Slarke at unsw.edu.au, EricT at cov.ac.uk,
Guy.VanBelle at rug.ac.be, IETF at CNRI.Reston.VA.US,
J.L.Leach at maths.bath.ac.uk, M.North at lcad.ac.uk, N.G.Cross at open.ac.uk,
N.Oloughlin at lcad.ac.uk, Pcrofts at chelt.ac.uk, Peter.Thomas at csm.uwe.ac.uk,
S.M.Loke at u.ac.shef.ac.uk, WGODWIN at chelt.ac.uk, alg at comm.toronto.edu,
armin at mic.atr.co.jp, atm at bbn.com, bota at race.u-tokyo.ac.jp,
cabernet-general at newcastle.ac.uk, ccrc at dworkin.wustl.edu,
cost237-transport at comp.lancs.ac.uk, ed1 at mdx.ac.uk, enternet at bbn.com,
fokus-user at fokus.gmd.de, giga at tele.pitt.edu, hipparch at sophia.inria.fr,
hoffmann at osiris.iemar.tuwien.ac.at, isadsoc at fokus.gmd.de,
jwworth at jupiter.informatik.umu.se, knishi at mic.atr.co.jp,
multicomm at cc.bellcore.com, osimcast at bbn.com,
performance at haven.epm.ornl.gov, rafaelp at cogs.susx.ac.uk, rem-conf at es.net,
reres at laas.fr, sbell at bmth.ac.uk, schmid at dfki.uni-kl.de,
sigmedia at bellcore.com, sugi at rd.nacsis.ac.jp, tccc at cs.umass.edu,
urban at egd.igd.fhg.de, xtp-relay at cs.concordia.ca, yevin at sam.imash.ras.ru
Subject: EuropIA
Source-Info: From (or Sender) name not authenticated.
europia`97
@EDINBURGH
------------------
DESIGN and the NET
------------------
http://www.caad.ed.ac.uk/europia/
Details and Provisional Programme
---------------------------------
Sixth International Conference on the Application/Implications of Computer
Networking in Architecture, Construction, Design, Civil Engineering and
Urban Planning
Sixime Confrence Internationale sur les applications/implications des
nouvelles technologies de communication en Architecture, Construction,
Design, Ingnierie et Planification urbaine
2-3 April 1997
Department of Architecture
University of Edinburgh
Edinburgh EH1 1JZ Scotland
http://www.caad.ed.ac.uk/europia/
This conference brings together researchers in design, architecture,
engineering, construction management, cognitive science, computer science,
artificial intelligence, sociology, geography and education as well as
industry partners, practitioners and other users of networked
communications.
The focus for this diverse group is design - how we design with and for
networked communications - appropriating recent exciting developments in
medium and broad band local area and wide area networks, new protocols for
interaction and new communications tools such as Web browsers and network
aware multimedia tools.
DATES
Conference 2-3 April 1997
REGISTRATION FEE
Authors 175 pounds stirling
Non-authors 250 pounds stirling
Conference Dinner 27 pounds stirling
VENUE
UnivEd Training and Conference Centre
11 South College Street
Edinburgh EH8 9AA
SEND QUEURIES ABOUT REGISTRATION AND ACCOMMODATION TO
Ronnie Galloway
Conference Manager
Ronnie.Galloway at ed.ac.uk
UnivEd Technologies Limited
11 South College Street, Edinburgh, EH8 9AA
Ph +44 131 650 9020
Fax +44 131 650 9019
EuropIA'97 Design and the Net 2-3 April 1997
+++++++++++++++++++++++++++++++++++++++++
Provisional Programme
=====================
(4/3/97)
Wednesday
9.15-9.30 Welcome
Working with the web: Networked CAD applications
9.30-10.00 . Common libraries for networked engineering
applications
Tuttle et al
10.00-10.30 . The VRML model of the city of Bath
Bourdakis and Day
10.30-11.00 break
11.00-11.30 . Shared information system for urban and architectural
design
Caneparo
11.30-12.00 . Communication in distributed statistical frameworks
for historic building documentation: The abbey of
Valmagne
Warden & Vasquez
12.00-12.30 . CAD On-line
Coyne & Lee
12.30-2.00 lunch
Working with the web: Innovation and technology
2.00-2.30 . A method for organising and sharing architectural
project information in the WWW
Ofluoglu & Kalisperis
2.30-3.00 . Designing learning environments using java
Pang & Edmonds
3.00-3.30 . A web -based design support environement for knowledge
discovery and machine learning
Branki, Bridges, Wallis & Aird
3.30-4.00 break
4.00-4.30 . Ways of aiding navigation in VRML worlds
Caritos and Rutherford
4.30-5.00 . Multilevel representations of architectural designs
Koutamanis
5.00-5.30 . A network aid for design project management
Roussel & Zriek
Thursday
The web in practice: Education in cyberspace
9.30-10.00 . The tex-mex virtual design studio
Vasquez & Trigo
10.00-10.30 . Networked based decision support for building design
Burry & Smithers
10.30-11.00 . Digital design: students communicating experiential
spatial qualities in a networked computing environment
Burley, Megza & Bauer
11.00-11.30 break
The web in practice: The emerging webculture
11.30-12.00 . HQ video conferencing and its application to the
teaching of architecture
Lindsay & Grant
12.00-12.30 . Sedimented practices of 'reading' design descriptions:
from paper to screen
Tweed
12.30-1.00 . The architect's role in the information age
Rossis
1.00-2.00 lunch
2.00-2.30 . Collaborative design by discovery and the web
Peng
2.30-3.00 . Method DTN: Design through the net
Reze
3.00-3.30 . A cyberspace in time
Szalapaj & Filho
3.30-4.30 Poster Session
The web in practice: The emerging webculture (cont.)
4.30-5.00 . A virtual monoculture of visual communication
Newton & Shi
5.00-5.30 . Design information and the superhighway:
roadworks ahead?
Ramscar & Lee
5.30-6.00 Plenary Session
Poster Session
. A web based experience of a collaborative
argumentation system design
Chen, Branki & Newman
. Networked collaborative design implementation
Burry, Coll & Serrano
. Up the down staircase...
Brady
. Broadband videoconference workstation
Brandt et al
. DesignNet electronic journal
Westphal & Burley
. Cybernetic theory & architecture
Hunt
. Intranets as tools for strategy
Thomas
. Building an intranet model for CAAD
Paranandi
Received: from cnri by ietf.org id aa21459; 4 Mar 97 15:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17238;
4 Mar 97 15:40 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA00194 at pad-thai.cam.ov.com>; Tue, 4 Mar 1997 18:27:48 GMT
Message-Id: <3.0.32.19970304102541.006aa868 at pop-srvr>
X-Sender: arim at pop-srvr
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 04 Mar 1997 10:25:42 -0800
To: cat-ietf at mit.edu
From: Ari Medvinsky <ari.medvinsky at cybersafe.com>
Subject: Re: Memphis agenda and discussion solicitation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Hello,
Recently Matt Hur, Clifford Neuman and I published an internet draft:
Public Key Utilizing Tickets for Application Servers (PKTAPP:=20
draft-ietf-cat-pktapp-00.txt ). We plan on giving a presentation at the
next CAT group meeting, and would like to solicit comments and discussion=
=20
prior to the IETF.=20
Abstract:
Public key based Kerberos for Distributed Authentication, (PKDA)=20
proposed by Sirbu & Chuang, describes PK based authentication that=20
eliminates the use of a centralized key distribution center while=20
retaining the advantages of Kerberos tickets. This draft describes how,
without any modification, the PKINIT specification may be used to=20
implement the ideas introduced in PKDA. The benefit is that only a=20
single PK Kerberos extension is needed to address the goals of PKINIT &=20
PKDA.
Given that PKINIT has progressed through the CAT working group of the=20
IETF, with plans for non-commercial distribution (via MIT's v5 Kerberos) =
=20
as well as plans for commercial support, we believe that it is worthwhile=
to=20
provide PKDA functionality under the PKINIT umbrella.
Regards,
-Ari
a copy of the PKTAPP draft is provided below:
---------------------------------------------------------------
INTERNET-DRAFT Ari Medvinsky
Common Authentication Technology Working Group Matthew Hur
draft-ietf-cat-pktapp-00.txt CyberSafe Corporation
B. Clifford Neuman
USC/ISI
Jan. 97 (Expires July-97)
Public Key Utilizing Tickets for Application Servers (PKTAPP)
0. Status Of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
1. Abstract
Public key based Kerberos for Distributed Authentication[1], (PKDA)=20
proposed by Sirbu & Chuang, describes PK based authentication that=20
eliminates the use of a centralized key distribution center while=20
retaining the advantages of Kerberos tickets. This draft describes how,
without any modification, the PKINIT specification[2] may be used to=20
implement the ideas introduced in PKDA. The benefit is that only a=20
single PK Kerberos extension is needed to address the goals of PKINIT &=20
PKDA.
=20
2. Introduction
With the proliferation of public key cryptography, a number of public=20
key extensions to Kerberos have been proposed to provide=20
interoperability with the PK infrastructure and to improve the Kerberos=20
authentication system [4]. Among these are PKINIT[2] (under development=20
in the CAT working group) and more recently PKDA [1] proposed by Sirbu &=20
Chuang of CMU. One of the principal goals of PKINIT is to provide for=20
interoperability between a PK infrastructure and Kerberos. Using=20
PKINIT, a user can authenticate to the KDC via a public key certificate. =
=20
A ticket granting ticket (TGT), returned by the KDC, enables a PK user=20
to obtain tickets and authenticate to kerberized services. The PKDA=20
=0C
proposal goes a step further. It supports direct client to server=20
authentication, eliminating the need for an online key distribution=20
center. In this draft, we describe how, without any modification, the=20
PKINIT protocol may be applied to achieve the goals of PKDA. For direct=20
client to server authentication, the client will use PKINIT to=20
authenticate to the end server (instead of a central KDC), which then,=20
will issue a ticket for itself. The benefit of this proposal, is that a=20
single PK extension to Kerberos can address the goals of PKINIT and=20
PKDA.
3. PKDA background
PKDA is based upon concepts first introduced in [5]. The PKDA proposal=20
provides direct client to server authentication, thus eliminating the=20
need for an online key distribution center. A client and server take=20
part in an initial PK based authentication exchange, with an added
caveat that the server acts as a Kerberos ticket granting service and
issues a traditional Kerberos ticket for itself. In subsequent
communication, the client makes use of the Kerberos ticket, thus
eliminating the need for public key operations on the server. This
approach has an advantage over SSL in that the server does not need to
save state (cache session keys). Furthermore, an additional benefit,
is that Kerberos tickets can facilitate delegation (see [3]).=20
Below is a brief overview of the PKDA protocol. For a more detailed=20
description see [1].=20
SCERT_REQ: Client -> Server
The client requests a certificate from the server. If the server=92s=20
certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.
SCERT_REP: Server -> Client
The server returns its certificate to the client.
PKTGS_REQ: Client -> Server
The client sends a request for a service ticket to the server. To=20
authenticate the request, the client signs, among other fields, a time=20
stamp and a newly generated symmetric key. The time stamp is used to=20
foil replay attacks; the symmetric key is used by the server to secure=20
the PKTGS_REP message.=20
The client provides a certificate in the request (the certificate=20
enables the server to verify the validity of the client=92s signature) an=
d=20
seals it along with the signed information using the server=92s public=20
key. =20
=20
PKTGS_REP: Server -> Client
The server returns a service ticket (which it issued for itself) along=20
with the session key for the ticket. The session key is protected by=20
the client-generated key from the PKTGS_REQ message. =20
AP_REQ: Client -> Server
After the above exchange, the client can proceed in a normal fashion,=20
using the conventional Kerberos ticket in an AP_REQ message.
=0C
4. PKINIT background
One of the principal goals of PKINIT is to provide for interoperability=20
between a public key infrastructure and Kerberos. Using a public key=20
certificate, a client can authenticate to the KDC and receive a TGT=20
which enables the client to obtain service tickets to kerberized=20
services. In PKINIT, the AS-REQ and AS-REP messages remain the same;=20
new preauthentication data types are used to conduct the PK exchange. =20
Client and server certificates are exchanged via the preauthentication=20
data. Thus, the exchange of certificates, PK authentication, and=20
delivery of a TGT can occur in two messages.
Below is a brief overview of the PKINIT protocol. For a more detailed=20
description see [2].=20
PreAuthentication data of AS-REQ: Client -> Server
The client sends a list of trusted certifiers, a signed PK=20
authenticator, and its certificate. The PK authenticator, based on the=20
Kerberos authenticator, contains the name of the KDC, a timestamp, and a=20
nonce.
PreAuthentication data of AS-REP: Server -> Client
The server responds with its certificate and the key used for decrypting=20
the encrypted part of the AS-REQ. This key is encrypted with the=20
client=92s public key.
AP_REQ: Client -> Server
After the above exchange, the client can proceed in a normal fashion,=20
using the conventional Kerberos ticket in an AP_REQ message.
5. Application of PKINIT to achieve equivalence to PKDA
While PKINIT is normally used to retrieve a TGT, it may also be used to
request an end service ticket. When used in this fashion, PKINIT is
functionally equivalent to PKDA. We introduce the concept of a local
ticket granting server (LTGS) to illustrate how PKINIT may be used for
issuing end service tickets based on public key authentication. It is
important to note that the LTGS may be built into an application server,
or it may be a stand-alone server used for issuing tickets within a
well-defined realm, such as a single machine. We will discuss both of
these options.
5.1. The LTGS
The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT=20
preauthentication data. When a client submits an AS-REQ to the LTGS, it=20
specifies an application server in order to receive an end service=20
ticket instead of a TGT.
5.1.1. The LTGS as a standalone server
The LTGS may run as a separate process that serves applications which=20
reside on the same machine. This consolidates administrative functions
and provide an easier migration path for a heterogeneous environment
consisting of both public key and Kerberos. The LTGS would use one
=0C
well-known port (port #88 - same as the KDC) for all message traffic
and would share a symmetric key with each service. After the client=20
receives a service ticket, it contacts the application server=20
directly. This approach is similar to the one suggested by Sirbu, et=20
al [1].
5.1.2. The LTGS as part of an application server
The LTGS may be combined with an application server. This accomplishes=20
direct client to application server authentication; however, it requires=20
that applications be modified to process AS-REQ and AS-REP messages. =20
The LTGS would communicate over the port assigned to the application=20
server or over the well known Kerberos port for that particular=20
application.
6. Protocol differences between PKINIT and PKDA
Both PKINIT and PKDA will accomplish the same goal of issuing end=20
service tickets, based on initial public key authentication. A PKINIT-
based implementation and a PKDA implementation would be functionally=20
equivalent. The primary differences are that 1)PKDA requires the client=20
to create the symmetric key while PKINIT requires the server to create=20
the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes=20
in four messages.
7. Discussion
The concept of Kerberos names (i.e. domain based names) is orthogonal to=20
the concept of public key names, in that X.500 distinguished names do=20
not reside within a particular realm. The assumption is that all user=20
principals will use X.500 distinguished names and that PKINIT will=20
support both X.500 and Kerberos names for application servers. However,=20
it is our recommendation that X.500 be the default naming convention for
application servers.
8. Summary
The PKINIT protocol can be used, without modification, to facilitate=20
client to server authentication without the use of a central KDC. The=20
approach described in this draft (and originally proposed in PKDA[1])=20
is essentially a public key authentication protocol which retains the=20
advantages of Kerberos tickets.
Given that PKINIT has progressed through the CAT working group of the=20
IETF, with plans for non-commercial distribution (via MIT=92s v5 Kerberos=
) =20
as well as plans for commercial support, it is worthwhile to provide
PKDA functionality under the PKINIT umbrella.
9. Bibliography
[1] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos Using=20
Public Key Cryptography. Symposium On Network and Distributed System=20
Security, 1997.
=0C
[2] B.C. Neuman, B. Tung, J. Wray, . Trostle. Public Key Cryptography=20
for Initial Authentication in Kerberos. Internet Draft, October 1996.=20
(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-02.txt)
[3] B.C. Neuman, Proxy-Based Authorization and Accounting for=20
Distributed Systems. In Proceedings of the 13th International=20
Conference on Distributed Computing Systems, May 1993
[4] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38.
September 1994.
[5] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction=20
Protocol. In Proceedings of the USENIX Workshop on Electronic Commerce,
July 1995.
Authors' Addresses
Ari Medvinsky <ari.medvinsky at cybersafe.com>
Matthew Hur <matt.hur at cybersafe.com>
CyberSafe Corporation=20
1605 NW Sammamish Road
Suite 310
Issaquah, WA 98027-5378
Phone: (206) 391-6000
Fax: (206) 391-0508
http:/www.cybersafe.com
B. Clifford Neuman
USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: +1 310 822 1511
E-mail: bcn at isi.edu
=0C
Received: from ietf.org by ietf.org id aa24722; 4 Mar 97 16:21 EST
Received: from ietf.ietf.org by ietf.org id aa23835; 4 Mar 97 16:08 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: SMTP Service Extension for Command Pipelining to Draft
Standard
Reply-to: iesg at ietf.org
Date: Tue, 04 Mar 1997 16:08:49 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703041608.aa23835 at ietf.org>
The IESG has received a request to consider SMTP Service Extension for
Command Pipelining <draft-freed-smtp-pipeline-01.txt> as a Draft
Standard. This document updates RFC1854, currently a Proposed
Standard. This has been reviewed in the IETF but is not the product of
an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by April 3, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa04425; 4 Mar 97 17:54 EST
Received: from cnri by ietf.org id aa03991; 4 Mar 97 17:50 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa20562;
4 Mar 97 17:50 EST
Received: by ginger.lcs.mit.edu
id AA24731; Tue, 4 Mar 97 17:38:18 -0500
Date: Tue, 4 Mar 97 17:38:18 -0500
Sender:ietf-request at ietf.org
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9703042238.AA24731 at ginger.lcs.mit.edu>
To: Valdis.Kletnieks at vt.edu, jdjones at sprynet.com
Subject: Re: firewalls
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
Source-Info: From (or Sender) name not authenticated.
From: Valdis.Kletnieks at vt.edu
Unfortunately, I work in a university environment, where there's a lot of
machines in departments that don't have a clue. And it's politically
impossible to require proof of clue ownership ... before letting users on
the net....
No doubt they don't bother to keep backups either - typical for this grade
of user.
Just think of the whole situation as evolution in action...
Noel
Received: from ietf.org by ietf.org id aa07174; 4 Mar 97 18:02 EST
Received: from cnri by ietf.org id aa06593; 4 Mar 97 18:01 EST
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa20880;
4 Mar 97 18:01 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id RAA21064;
Tue, 4 Mar 1997 17:58:49 -0500
Message-Id: <199703042258.RAA21064 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: jdjones at sprynet.com, ietf at CNRI.Reston.VA.US
Subject: Re: firewalls
In-Reply-To: Your message of "Tue, 04 Mar 1997 17:38:18 EST."
<9703042238.AA24731 at ginger.lcs.mit.edu>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <9703042238.AA24731 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1313945564P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 04 Mar 1997 17:58:44 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1313945564P
Content-Type: text/plain; charset=us-ascii
On Tue, 04 Mar 1997 17:38:18 EST, Noel Chiappa said:
> No doubt they don't bother to keep backups either - typical for this grade
> of user.
>
> Just think of the whole situation as evolution in action...
I can think of at least one case where I got over to campus, only to
find out that the machine in question:
a) Had no tape drive (and thus no backups)
b) No bootable disk remaining
c) No CD-ROM or floppy to boot an emergency system from
d) A Very Important Professor's Very Important Work on it.
Tenured professors - only way to get rid of them is to induce a heart
attack. Didn't suceeed in this case though ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1313945564P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMxypHdQBOOoptg9JAQG7nAP5AVmDbPI326IrB1hS00k6eajhVQ+24DIY
Gsq8WT3HOtfA4J8Sitd4xSJSI6ikTaXfD6PV0uRYtPk6AsTF/kuNwXDAFALiEixN
CHaiiujtDyhMKYkdQlUYAU/ZIijefqtyApeUGw00uK+OYQDG0CKWyLx7t/OEeK9c
8DzakzKqCY0=
=8tob
-----END PGP MESSAGE-----
--==_Exmh_-1313945564P--
Received: from ietf.org by ietf.org id aa08568; 5 Mar 97 8:31 EST
Received: from cnri by ietf.org id aa07613; 5 Mar 97 8:08 EST
Received: from soleil.uvsq.fr by CNRI.Reston.VA.US id aa06710; 5 Mar 97 8:08 EST
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with ESMTP id OAA17532
; Wed, 5 Mar 1997 14:04:32 +0100 (MET)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with ESMTP id NAA01995
for <congres at prism.uvsq.fr>; Wed, 5 Mar 1997 13:49:07 +0100 (MET)
Received: from mailer1.lut.ac.uk (mailhost.lut.ac.uk [158.125.1.202])
by soleil.uvsq.fr (8.8.5/jtpda-5.2) with SMTP id NAA16949
for <congres at prism.uvsq.fr>; Wed, 5 Mar 1997 13:48:58 +0100 (MET)
Received: from sun-cc201.lboro.ac.uk [158.125.1.201] (root)
by mailer1.lut.ac.uk with smtp (Exim 1.596 #1)
id 0w2G7k-0000D2-00; Wed, 5 Mar 1997 12:48:48 +0000
Received: from [194.66.220.37] [194.66.220.37]
by sun-cc201.lboro.ac.uk with smtp (Exim 1.596 #1)
id 0w2G7h-00019Z-00; Wed, 5 Mar 1997 12:48:45 +0000
X-Sender: acno at hpcin.lboro.ac.uk
Message-Id: <v01510101af431c26e83b at [194.66.220.37]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: congres at prism.uvsq.fr
Sender:ietf-request at ietf.org
From: Niall O'Loughlin <N.Oloughlin at lcad.ac.uk>
Subject: 21N97
Date: Wed, 5 Mar 1997 12:48:45 +0000
Source-Info: From (or Sender) name not authenticated.
I have just received part of a message about a call for papers but the
important part is missing. Would you send the message again, please?
Regards,
Niall O'Loughlin
Dr Niall O'Loughlin
Loughborough College of Art and Design
Epinal Way, Loughborough, Leicestershire
LE11 3GE U.K.
Telephone 01509-261515 ext 176
International +44-1509-261515 ext 176
Fax 01509-265515
International +44-1509-265515
e-mail: N.Oloughlin at lcad.ac.uk
Received: from ietf.org by ietf.org id aa11859; 5 Mar 97 9:38 EST
Received: from ietf.ietf.org by ietf.org id aa11649; 5 Mar 97 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-newman-url-imap-06.txt
Date: Wed, 05 Mar 1997 09:32:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050932.aa11649 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Note: This revision reflects comments received during the last call period.
Title : IMAP URL Scheme
Author(s) : C. Newman
Filename : draft-newman-url-imap-06.txt
Pages : 10
Date : 03/04/1997
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It
provides an ideal mechanism for accessing public mailing list archives as
well as private and shared message stores. This document defines a URL
scheme for referencing objects on an IMAP server.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-newman-url-imap-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-newman-url-imap-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-newman-url-imap-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970304135937.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-newman-url-imap-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-newman-url-imap-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304135937.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12308; 5 Mar 97 9:45 EST
Received: from ietf.ietf.org by ietf.org id aa11686; 5 Mar 97 9:33 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-iwps-schema-spec-04.txt
Date: Wed, 05 Mar 1997 09:33:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050933.aa11686 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : A Common Schema for the Internet White Pages Service
Author(s) : T. Genovese, B. Jennings
Filename : draft-ietf-ids-iwps-schema-spec-04.txt
Pages : 6
Date : 03/04/1997
The work is the result of the IETF Integrated Directory Services (IDS)
Working Group which proposes to establish a specification for a simple
Internet white pages service. To facilitate this effort it would be
helpful to have a common schema used by the various white page servers.
This document is designed to specify the basic set of attributes to be used
for a white page entry for an individual. It describes how new objects can
be defined and registered. This schema is independent of specific
implementations of the White Page service.
This document does not describe how to represent other objects in the
White page service. Further it does not address the search/sort
expectations within a particular service.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ids-iwps-schema-spec-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-iwps-schema-spec-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305092913.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-iwps-schema-spec-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-iwps-schema-spec-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305092913.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12309; 5 Mar 97 9:45 EST
Received: from ietf.ietf.org by ietf.org id aa11632; 5 Mar 97 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-sanghi-pmtudisc-ext-00.txt
Date: Wed, 05 Mar 1997 09:32:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050932.aa11632 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Extended Path MTU Discovery for IP version 6
Author(s) : D. Sanghi, S. Shah
Filename : draft-sanghi-pmtudisc-ext-00.txt
Pages : 6
Date : 03/04/1997
This draft discusses extensions to the present Path MTU Discovery mechanism
[PMTUDISC]. It provides applications finer control over the delay and
losses incurred during the PMTU Discovery process. The document proposes
two extension header options that allow PMTU Discovery with minimal
overheads.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-sanghi-pmtudisc-ext-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-sanghi-pmtudisc-ext-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-sanghi-pmtudisc-ext-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970304115840.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-sanghi-pmtudisc-ext-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-sanghi-pmtudisc-ext-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304115840.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12311; 5 Mar 97 9:45 EST
Received: from ietf.ietf.org by ietf.org id aa11668; 5 Mar 97 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-lantz-00.txt
Date: Wed, 05 Mar 1997 09:32:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703050932.aa11668 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Usage of H.323 on the Internet
Author(s) : P. Lantz
Filename : draft-rfced-info-lantz-00.txt
Pages : 16
Date : 03/04/1997
The H.323 standard defined by the International Telecommunication Union
(ITU) describes "Visual telephone systems and equipment for local area
networks which provide a non-guaranteed quality of service", that is to
say, video conferencing over Local Area Networks and the Internet.
Although it has been generally accepted that H.323 is an appropriate
standard for audio/video telephony on the Internet, it is a complex
standard. It describes a broad and complex set of capabilities, including
interoperation with other types of video conferencing systems, and contains
references to a number of other ITU standards.
This document describes the parts of the standard that are necessary
for Internet telephony and multipoint conferencing. It describes the
messages that are necessary to work with other H.323 implementations.
In a separate section, it also lists the messages that must be implemented
to be H.323 compliant.
This document is a guide to make the standard more accessible. It is not
intended to duplicate information in the standard. It does not contain
specifications of the messages or details of the protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-lantz-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-lantz-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-lantz-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970304144548.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-lantz-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-lantz-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304144548.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa25739; 5 Mar 97 13:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12264;
5 Mar 97 13:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA15298 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 15:46:47 GMT
Message-Id: <9703051543.AA17771 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 10:43:00 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: gss_export_sec_context()
Precedence: bulk
In my (hopefully) final cleanup pass over the GSSAPI C-bindings, I noticed an
ambiguity with gss_export_sec_context(). This routine takes a context handle
(identifying the context to be exported), and returns an interprocess token in
a buffer for the application to pass to another process.
The routine description says that, on return from this routine, the context
identified by the context handle can no longer be accessed by the calling
process.
i) What happens to the context if the routine fails for some reason (maybe the
implementation doesn't support transferrable contexts)? Should the input
context still be made inaccessible?
ii) Do we really want a successful call to make the context totally
inaccessible? In particular, should this routine delete all process-wide
resources associated with the original context, or should that responsibility
lie with the application (in which case the context isn't totally inaccessible,
but can only be accessed by the application to delete it)?
John
Received: from cnri by ietf.org id aa27184; 5 Mar 97 13:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13129;
5 Mar 97 13:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA17261 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 16:34:21 GMT
Message-Id: <9703051624.AA21675 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 11:24:18 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1105" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: OIDs and OID sets (again)
Precedence: bulk
I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
The consensus from the San Jose meeting was that we should remove the str<->oid
functions from the GSSAPI spec with the purpose of making all GSSAPI-created
OIDs static (non-freeable), and we subsequently seem to have reached agreement
that OID-sets should be dynamically allocated (i.e. the application must call
gss_release_oid_set() to free them).
How about the OID elements within a OID-set? Since OIDs are put into OID-sets
by gss_add_oid_set_member(), this routine has two options: it can either put a
pointer to the existing OID into the set, or create a heap-allocated copy of
the OID (which would then be deallocated with gss_release_oid_set()). The
first method means that an application must make sure that any OID that it puts
into an OID-set stays around for at least as long as the OID-set, whereas the
second method makes the OID-set a self-contained object.
I don't think there are any backwards-compatibilty problems with either
solution, since the V1 spec didn't provide the add_oid_set_member function, and
therefore OID-sets could be implemented either way transparently to the
application. Now we've provided a way for apps to generate OID-sets containing
their own OID values, we have to pick a particualr storage model.
I prefer the second method, where the OIDs within a set are "owned" by the set,
and are freed by gss_release_oid_set(). Mixing application-managed and
GSSAPI-managed storage within a single data structure seems to be asking for
memory-leaks.
John
Received: from cnri by ietf.org id aa29406; 5 Mar 97 15:20 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa14671;
5 Mar 97 15:20 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id NAA02107 for telnet-ietf-list at bsdi.com; Wed, 5 Mar 1997 13:15:25 -0700 (MST)
Received: from deis38.deis.unibo.it. (deis38.deis.unibo.it [137.204.57.38]) by external.BSDI.COM (8.8.5/8.8.2) with SMTP id NAA02096 for <telnet-ietf at bsdi.com>; Wed, 5 Mar 1997 13:15:19 -0700 (MST)
Received: by deis38.deis.unibo.it. (SMI-8.6/SMI-SVR4)
id VAA17832; Wed, 5 Mar 1997 21:18:12 +0100
Date: Wed, 5 Mar 1997 21:18:12 +0100
From: Sebastien Boving <seb at deis38.deis.unibo.it>
Message-Id: <199703052018.VAA17832 at deis38.deis.unibo.it.>
To: telnet-ietf at bsdi.com
Subject: encrypting 1 char at a time?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: qmmEoca5JxhruJD4pynTlA==
Hi *,
As you might remember i'm working on telnet to make it work with SESAME
authentication/encryption.
I just finished the authentication part (BTW, i had to make some changes
to auth_wait(), i guess the AUTH_VALID option with automatic login wasn't
completed implemented?), and will attack the encryption part one
of these days.
Before i start, i'd like to have your advice on a few things:
- Except for the kludge linemode (LINEMODE option is not supported for Solaris),
telnet sends one char at the time from client to server. Encrypting one
char is not very secure since an attacker could recognize some of them
quite easily (i mean the 'j' would always be enciphered the same way, and
'j' f.i. is also repeatedly used in elm, vi, etc...). Changing the session
key after every char brings too much overhead, so except working in the
kludged linemode, what can i do? How do other encryption software do this?
- Implementing authentication was quite easy since the source contained
some examples (especially SPX, since it also works with a GSS-API). The main
problem was making the underlying security mechanism (SESAME) working and
configuring it. For implementing the encryption, the only practical document
i have is the internet-draft on the AUTH_ENCRYPT option (though this option
will not be added). Are there any other interesting documents i should be
aware of? (Especially modified telnet source for other security mechanisms
would be welcome).
TIA,
Sebastien Boving.
Received: from cnri by ietf.org id aa29623; 5 Mar 97 15:29 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14812;
5 Mar 97 15:29 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA20689 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 17:55:52 GMT
From: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Message-Id: <9703051747.AA16193 at ronde.frcl.bull.fr>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 18:47:42 +0100 ("MET)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051543.AA17771 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 10:43:00 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Precedence: bulk
> i) What happens to the context if the routine fails for some reason (maybe the
> implementation doesn't support transferrable contexts)? Should the input
> context still be made inaccessible?
In such a case, the context should not be modified at all and therefore
accessible to all GSS routines.
> ii) Do we really want a successful call to make the context totally
> inaccessible? In particular, should this routine delete all process-wide
> resources associated with the original context, or should that responsibility
> lie with the application (in which case the context isn't totally
> inaccessible, but can only be accessed by the application to delete it)?
I'd recommend the application to invoke gss_delete_sec_context to actually
delete the context.
--
Jacques LEBASTARD mailto:J.Lebastard at frcl.bull.fr
BULL SA - ISM AccessMaster http://www-ism.bull.com/ism/
Rue Jean Jaures - A5/146 Tel: +33 (0)1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 (0)1 30 80 77 99
Received: from cnri by ietf.org id aa00396; 5 Mar 97 16:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15475;
5 Mar 97 16:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA24612 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:23:01 GMT
Date: Wed, 5 Mar 1997 14:22:56 -0500
Message-Id: <9703051922.AA06547 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
Subject: Re: OIDs and OID sets (again)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 5 Mar 97 11:24:18 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1105" <wray at tuxedo.ENET.dec.com>
How about the OID elements within a OID-set? Since OIDs are put into
OID-sets by gss_add_oid_set_member(), this routine has two options:
it can either put a pointer to the existing OID into the set, or
create a heap-allocated copy of the OID (which would then be
deallocated with gss_release_oid_set()). The first method means that
an application must make sure that any OID that it puts into an
OID-set stays around for at least as long as the OID-set, whereas the
second method makes the OID-set a self-contained object.
I believe the OID-set should be a self-contained object. The problems
associated with pointer aliasing are too horrible to contemplate. It's
not just memory leaks; it's also the side effects when you modify an OID
that's being pointed to by the OID-set.
- Ted
Received: from cnri by ietf.org id aa01611; 5 Mar 97 16:41 EST
Received: from external.BSDI.COM by CNRI.Reston.VA.US id aa16144;
5 Mar 97 16:41 EST
Received: (from daemon at localhost) by external.BSDI.COM (8.8.5/8.8.2) id OAA10528 for telnet-ietf-list at bsdi.com; Wed, 5 Mar 1997 14:38:48 -0700 (MST)
Received: from forge.BSDI.COM (dab at forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.8.5/8.8.2) with ESMTP id OAA10514; Wed, 5 Mar 1997 14:38:32 -0700 (MST)
Received: (from dab at localhost) by forge.BSDI.COM (8.8.2/8.7.3) id OAA02645; Wed, 5 Mar 1997 14:38:31 -0700 (MST)
Date: Wed, 5 Mar 1997 14:38:31 -0700 (MST)
From: David Borman <dab at bsdi.com>
Message-Id: <199703052138.OAA02645 at forge.BSDI.COM>
To: seb at deis38.deis.unibo.it, telnet-ietf at bsdi.com
Subject: Re: encrypting 1 char at a time?
Sebastien,
> - Except for the kludge linemode (LINEMODE option is not supported for Solaris),
> telnet sends one char at the time from client to server. Encrypting one
> char is not very secure since an attacker could recognize some of them
> quite easily (i mean the 'j' would always be enciphered the same way, and
> 'j' f.i. is also repeatedly used in elm, vi, etc...). Changing the session
> key after every char brings too much overhead, so except working in the
> kludged linemode, what can i do? How do other encryption software do this?
You don't directly encrypt the data. You use key to encrypt a some known
text, and then feed the output back into the encryption engine. The
resulting stream is then XORed with the clear text to generate the
encrypted data. The receiver knows the same key and initial data,
generates the same stream of numbers, and XORes it with the encrypted
data to generate the clear text. This is called Output Feedback. If
you feed back in the encrypted data stream, then you have Cipher Feedback.
The latter is usually the prefered method.
For example, here are pictures showing cipher feedback:
Encryption:
Clear Text Data --------------+
|
+------------+ |
Key -----> | Encryption | v
Initial vector -> +-> | Engine |---> XOR --> Encrypted Data
| +------------+ |
+-----------------------+
Decryption:
Encrypted Data ------------+-----+
| |
+------------+ | |
Key -----> | Encryption | | v
Initial vector -> +-> | Engine |---(--> XOR --> Clear Text Data
| +------------+ |
+--------------------+
> - Implementing authentication was quite easy since the source contained
> some examples (especially SPX, since it also works with a GSS-API). The main
> problem was making the underlying security mechanism (SESAME) working and
> configuring it. For implementing the encryption, the only practical document
> i have is the internet-draft on the AUTH_ENCRYPT option (though this option
> will not be added). Are there any other interesting documents i should be
> aware of? (Especially modified telnet source for other security mechanisms
> would be welcome).
ftp://ftp.cray.com/src/telnet/telnet.rfc.tar.Z
is a collection of Telnet related RFCs, including the draft of
the encryption option from March, 1992, with documentation of
DES cipher and output feedback.
> TIA,
> Sebastien Boving.
-David Borman, dab at bsdi.com
Received: from cnri by ietf.org id aa02062; 5 Mar 97 16:57 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16487;
5 Mar 97 16:57 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA20801 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 17:59:19 GMT
Message-Id: <199703051758.AA29340 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 12:58:22 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051543.AA17771 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 10:43:00 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> In my (hopefully) final cleanup pass over the GSSAPI C-bindings, I noticed an
> ambiguity with gss_export_sec_context(). This routine takes a context handle
> (identifying the context to be exported), and returns an interprocess token in
> a buffer for the application to pass to another process.
>
> The routine description says that, on return from this routine, the context
> identified by the context handle can no longer be accessed by the calling
> process.
>
> i) What happens to the context if the routine fails for some reason (maybe the
> implementation doesn't support transferrable contexts)? Should the input
> context still be made inaccessible?
I'd like to see "transaction integrity": either context export works
successfully, or an error will be returned and the context will remain
completely unchanged.
>
> ii) Do we really want a successful call to make the context totally
> inaccessible? In particular, should this routine delete all process-wide
> resources associated with the original context, or should that responsibility
> lie with the application (in which case the context isn't totally inaccessible,
> but can only be accessed by the application to delete it)?
Upon successful return (GSS_S_COMPLETE), the context should no longer exist
in memory and the context_handle is to be cleared by the gssapi mechanism.
When the routine returns anthing else than GSS_S_COMPLETE, the context
should not have changed in any way, and the handle must remain untouched.
The equivalent of delete_sec_context() should be called as the very last
action of export_context(). If creating the interprocess_token in a
standalone gss_buffer_t object is successful, then export_context should
return GSS_S_COMPLETE and clear the context handle, even when there is
some awkward problem during delete_sec_context() (which should be impossible
at this point).
-Martin
Received: from cnri by ietf.org id aa02090; 5 Mar 97 16:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16500;
5 Mar 97 16:58 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA28124 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:36:43 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: OIDs and OID sets (again)
References: <9703051624.AA21675 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 15:36:41 -0500
In-Reply-To: "John Wray, Digital DPE,'s message of Wed, 5 Mar 97 11:24:18 EST
Message-Id: <t53lo82vzxi.fsf at rover.cygnus.com>
Lines: 15
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1105" <wray at tuxedo.ENET.dec.com> writes:
>> I prefer the second method, where the OIDs within a set are "owned"
>> by the set, and are freed by gss_release_oid_set(). Mixing
>> application-managed and GSSAPI-managed storage within a single data
>> structure seems to be asking for memory-leaks.
This seems obvious. I didn't even consider an implementor misguided
enough to believe that maintaining pointers to the
application-provided oid was reasonable.
Marc
P.S. John, is Digital *ever* going to fix your mailer's outgoing
headers, or should I just give up?
Received: from cnri by ietf.org id aa02503; 5 Mar 97 17:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16887;
5 Mar 97 17:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA24662 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:23:26 GMT
Date: Wed, 5 Mar 1997 14:23:21 -0500
Message-Id: <9703051923.AA06550 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 5 Mar 97 10:43:00 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com>
i) What happens to the context if the routine fails for some reason
(maybe the implementation doesn't support transferrable contexts)?
Should the input context still be made inaccessible?
No; in general, API calls should atomically fail (i.e., if they fail,
they should do nothing.)
ii) Do we really want a successful call to make the context totally
inaccessible? In particular, should this routine delete all
process-wide resources associated with the original context, or
should that responsibility lie with the application (in which case
the context isn't totally inaccessible, but can only be accessed by
the application to delete it)?
Yes, we have to make it totally inaccessible. In particular, services
such as sequencing and reply protection are not well defined if we don't
do this. And it does have to delete all of the process-side resources
associated with the context handle, because the application *can't* do
it; the only way to access the resources associated to the context
handle is via GSSAPI library.
- Ted
Received: from cnri by ietf.org id aa03398; 5 Mar 97 17:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17343;
5 Mar 97 17:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA26641 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:00:11 GMT
Message-Id: <199703051940.AA07350 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: OIDs and OID sets (again)
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 14:41:17 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051624.AA21675 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 11:24:18 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
>
> The consensus from the San Jose meeting was that we should remove the str<->oid
> functions from the GSSAPI spec with the purpose of making all GSSAPI-created
> OIDs static (non-freeable), and we subsequently seem to have reached agreement
> that OID-sets should be dynamically allocated (i.e. the application must call
> gss_release_oid_set() to free them).
Actually, this is interesting:
We agreed that the application must call gss_release_oid_set() to RELEASE
them.
We didn't discuss if you are allowed to pass OID_sets to add_oid_set_member
OTHER than those created by create_empty_oid_set and those modified
by add_oid_set_member.
I would object to any application that tries to feed into add_oid_set_member
an OID_set that was returned from any of acquire_cred(), add_cred(),
indicate_mechs(), inquire_cred(), inquire_mechs_for_name and
inquire_names_for_mech(). Otherwise all OID_sets will have to be completely
dynamic, especially the one returned from indicate_mechs.
-Martin
Received: from cnri by ietf.org id aa03880; 5 Mar 97 18:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17643;
5 Mar 97 18:02 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA22345 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 18:34:25 GMT
Message-Id: <9703051825.AA01544 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 13:25:12 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1315" <wray at tuxedo.enet.dec.com>
To: j.lebastard at frcl.bull.fr
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, j.lebastard at frcl.bull.fr
Subject: Re: gss_export_sec_context()
Precedence: bulk
>> i) What happens to the context if the routine fails for some reason (maybe the
>> implementation doesn't support transferrable contexts)? Should the input
>> context still be made inaccessible?
>
>In such a case, the context should not be modified at all and therefore
>accessible to all GSS routines.
That was my first thought, but for the application to be able to know what's
happened, I think this means that the GSSAPI implementation will have to
guarantee that in the event of any error, the input context will be untouched
(and therefore still valid). If that's not too onerous on GSSAPI implementors,
I'm happy with this.
>> ii) Do we really want a successful call to make the context totally
>> inaccessible? In particular, should this routine delete all process-wide
>> resources associated with the original context, or should that responsibility
>> lie with the application (in which case the context isn't totally
>> inaccessible, but can only be accessed by the application to delete it)?
>
>I'd recommend the application to invoke gss_delete_sec_context to actually
>delete the context.
There are two problems with this:
i) If the application provides a token buffer to delete_sec_context, gets a
token back, and transmits it to the peer, then the peer will presumably
delete its half of the context, so the transferred context won't work.
Now, this is an application bug, but if export_sec_context were to do the
local deletion, then it wouldn't be a possibility.
ii) I can conceive of some implementations actually maintaining context
information internally, in shared memory, and using the token simply
as a handle to this internal global state. In such an implementation,
"making the context inaccessible to a process" might not be quite the
same as "deleting the context" from that process, since in the first
case you'd want the actual context data to stay around for the import
operation, whereas in the second case you'd want the GSSAPI
implementation to actually free the resources.
John
Received: from cnri by ietf.org id aa03887; 5 Mar 97 18:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17653;
5 Mar 97 18:02 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA28012 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:33:04 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <9703051543.AA17771 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 15:32:44 -0500
In-Reply-To: "John Wray, Digital DPE,'s message of Wed, 5 Mar 97 10:43:00 EST
Message-Id: <t53n2siw043.fsf at rover.cygnus.com>
Lines: 29
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com> writes:
>> i) What happens to the context if the routine fails for some reason
>> (maybe the implementation doesn't support transferrable contexts)?
>> Should the input context still be made inaccessible?
I think the context should be made inaccessible. This is clear and
unambiguous. If the implementation doesn't support transferrable
contexts, then there the flags returned from
gss_init/accept_sec_context will indicate this. If there's some other
failure, I can't imagine any kind of sensible recovery process.
If someone has another unambiguous alternative which might support a
different recovery process, I'm interested in hearing it, but I think
KISS applies here.
>> ii) Do we really want a successful call to make the context totally
>> inaccessible? In particular, should this routine delete all
>> process-wide resources associated with the original context, or
>> should that responsibility lie with the application (in which case
>> the context isn't totally inaccessible, but can only be accessed by
>> the application to delete it)?
Yes, as a side effect, the all resources associated with the context
handle should be deleted. It would seem to require extra complexity
in the GSSAPI and the application to have a special deletable-only
context, so there's no good reason to do this.
Marc
Received: from cnri by ietf.org id aa04278; 5 Mar 97 18:19 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17960;
5 Mar 97 18:19 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA23027 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 18:48:12 GMT
Message-Id: <9703051834.AA02229 at us1rmc.bb.dec.com>
Date: Wed, 5 Mar 97 13:34:47 EST
From: "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1326" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, martin.rex at sap-ag.de
Subject: Re: gss_export_sec_context()
Precedence: bulk
>John Wray, Digital DPE, wrote:
>> In my (hopefully) final cleanup pass over the GSSAPI C-bindings, I noticed an
>> ambiguity with gss_export_sec_context(). This routine takes a context handle
>> (identifying the context to be exported), and returns an interprocess token in
>> a buffer for the application to pass to another process.
>>
>> The routine description says that, on return from this routine, the context
>> identified by the context handle can no longer be accessed by the calling
>> process.
>>
>> i) What happens to the context if the routine fails for some reason (maybe the
>> implementation doesn't support transferrable contexts)? Should the input
>> context still be made inaccessible?
>
>I'd like to see "transaction integrity": either context export works
>successfully, or an error will be returned and the context will remain
>completely unchanged.
That means that either the GSSAPI implementation has to verify somehow that the
entire operation is going to succeed before it performs it, or that it provide
some way to roll-back in the event of an error (in practice, it'd probably
require a combination of these techniques). The only reason I'm hesitant about
requiring this is that it seems like it might be a lot of work for an
implementation to do.
>>
>> ii) Do we really want a successful call to make the context totally
>> inaccessible? In particular, should this routine delete all process-wide
>> resources associated with the original context, or should that responsibility
>> lie with the application (in which case the context isn't totally inaccessible,
>> but can only be accessed by the application to delete it)?
>
>Upon successful return (GSS_S_COMPLETE), the context should no longer exist
>in memory and the context_handle is to be cleared by the gssapi mechanism.
>
>When the routine returns anthing else than GSS_S_COMPLETE, the context
>should not have changed in any way, and the handle must remain untouched.
OK (with the above reservations concerning implementation complexity).
>The equivalent of delete_sec_context() should be called as the very last
>action of export_context().
With the one proviso that not all the functionality of delete_sec_context() may
be wanted: in particular, if some context-specific state has to be retained in
order for the context to be imported in another process, that state obviously
shouldn't be deleted.
>If creating the interprocess_token in a
>standalone gss_buffer_t object is successful, then export_context should
>return GSS_S_COMPLETE and clear the context handle, even when there is
>some awkward problem during delete_sec_context() (which should be impossible
>at this point).
OK.
John
Received: from cnri by ietf.org id aa04775; 5 Mar 97 18:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18322;
5 Mar 97 18:44 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA27657 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 20:25:10 GMT
Message-Id: <199703052023.AA10310 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Date: Wed, 5 Mar 1997 15:24:06 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051747.AA16193 at ronde.frcl.bull.fr> from "Jacques Lebastard" at Mar 5, 97 06:47:42 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Jacques Lebastard wrote:
> > ii) Do we really want a successful call to make the context totally
> > inaccessible? In particular, should this routine delete all process-wide
> > resources associated with the original context, or should that responsibility
> > lie with the application (in which case the context isn't totally
> > inaccessible, but can only be accessed by the application to delete it)?
>
> I'd recommend the application to invoke gss_delete_sec_context to actually
> delete the context.
Could you be a little more specific why you want to explicitly call
delete_sec_context()?
It's true that RFC2078 says that "the context will be invalid
after export", so it might need to be clarified, but the C-Bindings
and Ted's original proposal pass the context_handle by reference --
so that it can be wiped when the operation succeeds.
An invalid but undeleted context would be totally useless in my
opinion. IMO, a context that is not valid would have to be rejected
by gss_delete_sec_context() with GSS_C_NO_CONTEXT -- if you read the
spec verbatim. ;-)
If the context remained valid after export, further processing
of messages is guaranteed to cause trouble with the features
"Sequencing" and "Replay Detection" for the next context importer.
What do you think an application could want to do with the context_handle
after exporting the context? The only thing available for discussion
is gss_delete_sec_context(). What should it do when this fails?
My application will definitely ignore that; at most I would write some
log that there might be something wrong with the gssapi mechanism
or with the invocation of the call which eventually should be checked.
The application definitely shouldn't abort (once it's shipping).
-Martin
Received: from cnri by ietf.org id aa04981; 5 Mar 97 18:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18531;
5 Mar 97 18:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA24828 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:26:49 GMT
Message-Id: <199703051925.AA06552 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: OIDs and OID sets (again)
Orig-To: wray at tuxedo.ENET.dec.com (John Wray, Digital DPE, )
To: cat-ietf at mit.edu
Date: Wed, 5 Mar 1997 14:25:31 -0500 (EST)
In-Reply-To: <9703051624.AA21675 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 11:24:18 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
>
> I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
>
> The consensus from the San Jose meeting was that we should remove the str<->oid
> functions from the GSSAPI spec with the purpose of making all GSSAPI-created
> OIDs static (non-freeable), and we subsequently seem to have reached agreement
> that OID-sets should be dynamically allocated (i.e. the application must call
> gss_release_oid_set() to free them).
>
> How about the OID elements within a OID-set? Since OIDs are put into OID-sets
> by gss_add_oid_set_member(), this routine has two options: it can either put a
> pointer to the existing OID into the set, or create a heap-allocated copy of
> the OID (which would then be deallocated with gss_release_oid_set()). The
> first method means that an application must make sure that any OID that it puts
> into an OID-set stays around for at least as long as the OID-set, whereas the
> second method makes the OID-set a self-contained object.
To avoid ANY possible problems with different heap allocators, especially
in shared library environments, it is necessary that objects are entirely
managed by one single service provider (library). I.e. oid_sets returned
by a gssapi mechanism have to completely managed and owned by the mechanism.
How a mechanism composes compound objects is a local matter (i.e.
implementation detail outside of the spec). If a mechanism creates oid_sets
that refer to static OID-elements octet strings, then it is responsible to
handle them correctly within gss_release_oid_set.
Glue layers that add up gssapi mechanisms to a multimechanism will have
either have to know about the nature of the oid_sets of the submechanisms,
or they will have to register or clone the oid_sets while they still know
which submechanism created the oid_set, so that it can later be released
correctly.
Passing application defined OID_sets to add_oid_set_member will cause
undefined behaviour -- passing OID of arbitrary nature is ok, since
the OID is a read-only input parameter.
>
> I don't think there are any backwards-compatibilty problems with either
> solution, since the V1 spec didn't provide the add_oid_set_member function, and
> therefore OID-sets could be implemented either way transparently to the
> application. Now we've provided a way for apps to generate OID-sets containing
> their own OID values, we have to pick a particualr storage model.
>
> I prefer the second method, where the OIDs within a set are "owned" by the set,
> and are freed by gss_release_oid_set(). Mixing application-managed and
> GSSAPI-managed storage within a single data structure seems to be asking for
> memory-leaks.
Even worse, it's asking for core dumps / GPVs / big trouble.
ANSI-C uses the term "undefined behaviour".
It should be emphasized in the spec that add_oid_set_member
is only allowed for OID_sets created by create_empty_oid_set().
-Martin
Received: from cnri by ietf.org id aa05078; 5 Mar 97 19:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18663;
5 Mar 97 19:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA23930 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 19:11:57 GMT
Message-Id: <199703051911.AA05538 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Wed, 5 Mar 1997 14:11:25 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703051834.AA02229 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 5, 97 01:34:47 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> Martin Rex wrote:
> >John Wray wrote:
> >> i) What happens to the context if the routine fails for some reason (maybe the
> >> implementation doesn't support transferrable contexts)? Should the input
> >> context still be made inaccessible?
> >
> >I'd like to see "transaction integrity": either context export works
> >successfully, or an error will be returned and the context will remain
> >completely unchanged.
>
> That means that either the GSSAPI implementation has to verify somehow that the
> entire operation is going to succeed before it performs it, or that it provide
> some way to roll-back in the event of an error (in practice, it'd probably
> require a combination of these techniques). The only reason I'm hesitant about
> requiring this is that it seems like it might be a lot of work for an
> implementation to do.
I think it should be rather easy. Since the exported context is
a standalone flat object and does not share any objects with the
security context, the creation of the exported context does not
harm the security context at all. If you start deleting the context
object only after the creation of the exported context has completed
successfully, then I don't see the problem.
After all, that is exactly what happens if the application called
export_sec_context()/delete_sec_context() in sequence before passing
the exported context along to a different process.
If context transfer is to work at all, it will work if the gssapi
mechanism does the delete within the export.
>
> >>
> >> ii) Do we really want a successful call to make the context totally
> >> inaccessible? In particular, should this routine delete all process-wide
> >> resources associated with the original context, or should that responsibility
> >> lie with the application (in which case the context isn't totally inaccessible,
> >> but can only be accessed by the application to delete it)?
> >
> >Upon successful return (GSS_S_COMPLETE), the context should no longer exist
> >in memory and the context_handle is to be cleared by the gssapi mechanism.
> >
> >When the routine returns anthing else than GSS_S_COMPLETE, the context
> >should not have changed in any way, and the handle must remain untouched.
>
> OK (with the above reservations concerning implementation complexity).
>
> >The equivalent of delete_sec_context() should be called as the very last
> >action of export_context().
>
> With the one proviso that not all the functionality of delete_sec_context() may
> be wanted: in particular, if some context-specific state has to be retained in
> order for the context to be imported in another process, that state obviously
> shouldn't be deleted.
Your last comment frightens me. You should not keep ANY context-specific
state around in the process image of the process that does the export!
(1) It's NOT ok for a gss-api mechanism to leak memory for
context_export/context_import activity.
(2) An application may decide to memset an exported security context to
zero, while the gssapi mechanism must still conform to (1).
(3) A context import may fail with GSS_S_CONTEXT_EXPIRED or other
error codes, in which case an application will probably do (2).
(4) The context-exporting process may exit before the exported context
will be imported by another process.
(I'm going to implement security context caching for specific
client applications that will require this characteristic,
mainly to improve performance for public key based authentication
and to save round trips on the average).
These are rules that we require for successful interoperation with
our application. The requirements may make it hard to impossible
to enforce certain policies on exported security contexts ...
-Martin
Received: from cnri by ietf.org id aa05624; 5 Mar 97 19:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19084;
5 Mar 97 19:34 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA04500 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 23:09:41 GMT
Message-Id: <199703052308.AA22231 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Marc Horowitz <marc at cygnus.com>
Date: Wed, 5 Mar 1997 18:08:28 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53n2siw043.fsf at rover.cygnus.com> from "Marc Horowitz" at Mar 5, 97 03:32:44 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
> "John Wray, Digital DPE, (508) 486-5210 05-Mar-1997 1032" <wray at tuxedo.enet.dec.com> writes:
>
> >> i) What happens to the context if the routine fails for some reason
> >> (maybe the implementation doesn't support transferrable contexts)?
> >> Should the input context still be made inaccessible?
>
> I think the context should be made inaccessible. This is clear and
> unambiguous. If the implementation doesn't support transferrable
> contexts, then there the flags returned from
> gss_init/accept_sec_context will indicate this. If there's some other
> failure, I can't imagine any kind of sensible recovery process.
I don't like this idea. My analogy would be a file descriptor on
which I try to seek but it happens to be a pipe. I would complain
when the OS closed the file because of this error.
export_sec_context() can fail with the error GSS_S_CONTEXT_EXPIRED.
so can the per-message calls getmic/verifymic/wrap/unwrap.
Neither should delete the context when returning this error.
The operation should be atomic, as Ted wrote. It would be very
counter-intuitive if it did half-work (delete the context) and
half-fail (not emit a interprocess token).
-Martin
Received: from cnri by ietf.org id aa06873; 5 Mar 97 20:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20086;
5 Mar 97 20:51 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA07111 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 00:06:09 GMT
Message-Id: <199703060005.AA25564 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: cat-ietf at mit.edu
Date: Thu, 6 Mar 1997 01:05:47 +0100 (MEZ)
In-Reply-To: <9703051747.AA16193 at ronde.frcl.bull.fr> from "Jacques Lebastard" at Mar 5, 97 06:47:42 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Maybe there is one situation where automatic context deletion by
gss_export_sec_context() causes a problem:
When trying to build a gssapi mechanism that can dynamically load existing
gssapi mechanisms, then one cannot see from the interprocess token emitted
by export_sec_context by which mechanism implementation it was actually
created. The glue-layer would have to add a wrapper when export_sec_context
returns from the mechanism, and this could fail with "out-of-memory".
In this situation it might be impossible to operate atomically.
Mandating a framing for the interprocess token similar to exported
names would improve the situation somewhat, but I doubt it's a panacea.
The exported names are to be specified in *all* details in the
gssapi mechanism specification; interprocess tokens are meaningful to
one specific implementation only, and they should remain like that.
Do we want to do something about this?
Are there other/more routines where layering does/will interfere with
atomic operation?
-Martin
Received: from cnri by ietf.org id aa07653; 5 Mar 97 21:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20569;
5 Mar 97 21:33 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA06239 at pad-thai.cam.ov.com>; Wed, 5 Mar 1997 23:46:47 GMT
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <199703052308.AA22231 at sap-ag.de>
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 18:44:57 -0500
In-Reply-To: Martin Rex's message of Wed, 5 Mar 1997 18:08:28 -0500 (EST)
Message-Id: <t53g1y9x5s6.fsf at rover.cygnus.com>
Lines: 37
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> > >> i) What happens to the context if the routine fails for some reason
>> > >> (maybe the implementation doesn't support transferrable contexts)?
>> > >> Should the input context still be made inaccessible?
>> >
>> > I think the context should be made inaccessible. This is clear and
>> > unambiguous. If the implementation doesn't support transferrable
>> > contexts, then there the flags returned from
>> > gss_init/accept_sec_context will indicate this. If there's some other
>> > failure, I can't imagine any kind of sensible recovery process.
>>
>> I don't like this idea. My analogy would be a file descriptor on
>> which I try to seek but it happens to be a pipe. I would complain
>> when the OS closed the file because of this error.
I understand your argument that atomic behavior would be nice, and I
agree, but I don't think that all mechanisms can guarantee that this
sort of atomic behavior is possible. Consider a mechanism which had
to do some sort of irrevocable "give away" of a resource, such as
chowning a file to another user. Remember, the context information
does not need to be contained in the token; the token can refer to the
context data elsewhere if that is appropriate for the mechanism.
To use your file descriptor analogy, consider a function which changes
the owner of a file and then releases a lock. If releasing the lock
somehow fails, it is impossible to "unchown" the file. You don't want
to release the lock first due to the nature of locking and races.
It would be nice to either {succeed/create the token/destroy the
context}, or {fail/not create the token/leave the context untouched},
but some mechanisms cannot guarantee one of these states.
With respect to recovery, what do you do if closing a file descriptor
fails? IMHO, this is similar.
Marc
Received: from ietf.org by ietf.org id aa21760; 6 Mar 97 5:58 EST
Received: from Twig.Rodents.Montreal.QC.CA by ietf.org id aa21516;
6 Mar 97 5:48 EST
Received: (from mouse at localhost) by Twig.Rodents.Montreal.QC.CA (8.7.5/8.7.3) id FAA16081; Thu, 6 Mar 1997 05:46:15 -0500 (EST)
Date: Thu, 6 Mar 1997 05:46:15 -0500 (EST)
Sender:ietf-request at ietf.org
From: der Mouse <mouse at rodents.montreal.qc.ca>
Message-Id: <199703061046.FAA16081 at Twig.Rodents.Montreal.QC.CA>
To: ietf at ietf.org
Cc: cat-ietf at mit.edu
Subject: draft-ietf-cat-ftpsec-09.txt
Source-Info: From (or Sender) name not authenticated.
I have a few minor comments on draft-ietf-cat-ftpsec-09.txt.
> CLEAR COMMAND CHANNEL (CCC)
[...]
> protected control channel messages. The CCC command itself must
> be integrity protected.
[...]
> INTEGRITY PROTECTED COMMAND (MIC) and
> CONFIDENTIALITY PROTECTED COMMAND (CONF) and
> PRIVACY PROTECTED COMMAND (ENC)
[...]
> A server may require that the first command after a successful
> security data exchange be CCC, and not implement the protection
> commands at all. In this case, the server should respond with a
[...]
> If the server has completed a security data exchange with the
> client using a mechanism which supports integrity, and requires a
> CCC command due to policy or implementation limitations, it should
How can the CCC command be integrity protected if the server doesn't
implement at least MIC?
> If the server is willing to allow the user named by the USER command
> to log in based on the identity established by the security data
> exchange, it should respond with reply code 232.
Presumably this refers to the response to the USER command; I think
this should be clarified.
> 6. Data Channel Encapsulation
[...]
> When the end of the file is reached, the sender must encode a block
> of zero bytes, and send this final block to the recipient before
> closing the data connection.
This appears to be considering only STRU F, MODE S - ie, the case where
EOF is indicated by closing the data channel. I think it is important
to clarify how the mechanisms of this draft interact with STRU/MODE
combinations that do not involve creating and closing a new data
channel for each file transferred.
Also, this encoding allows data-stream detection of EOF for STRU F,
MODE S transfers, transfers that normally would require closure of the
data connection to indicate EOF. Does this make it possible to
transfer multiple files over a single data connection when this would
not normally be possible? Whether or not, I think this should be
explicitly stated.
> 10. Base 64 Encoding
[...]
> Case must not be ignored when reading commands and replies containing
> base 64 encodings.
This could be misread to imply that (for example) "mic" is not a valid
form of the command keyword for the MIC command.
I also note that no registry is defined for authentication mechanism
name strings - presumably this will be handled by the IANA, but I'd
like to see it explicitly stated; in particular, people developing
mechanisms should be able to determine whom to get a registered name
for their mechanisms from.
der Mouse
mouse at rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received: from cnri by ietf.org id aa22781; 6 Mar 97 6:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06041;
6 Mar 97 6:51 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <JAA24467 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 09:49:57 GMT
Message-Id: <199703060946.AA11371 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Marc Horowitz <marc at cygnus.com>
Date: Thu, 6 Mar 1997 04:47:03 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53g1y9x5s6.fsf at rover.cygnus.com> from "Marc Horowitz" at Mar 5, 97 06:44:57 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Marc Horowitz wrote:
> Martin Rex <martin.rex at sap-ag.de> writes:
> >> > >> i) What happens to the context if the routine fails for some reason
> >> > >> (maybe the implementation doesn't support transferrable contexts)?
> >> > >> Should the input context still be made inaccessible?
> >> >
> >> > I think the context should be made inaccessible. This is clear and
> >> > unambiguous. If the implementation doesn't support transferrable
> >> > contexts, then there the flags returned from
> >> > gss_init/accept_sec_context will indicate this. If there's some other
> >> > failure, I can't imagine any kind of sensible recovery process.
> >>
> >> I don't like this idea. My analogy would be a file descriptor on
> >> which I try to seek but it happens to be a pipe. I would complain
> >> when the OS closed the file because of this error.
>
> I understand your argument that atomic behavior would be nice, and I
> agree, but I don't think that all mechanisms can guarantee that this
> sort of atomic behavior is possible. Consider a mechanism which had
> to do some sort of irrevocable "give away" of a resource, such as
> chowning a file to another user. Remember, the context information
> does not need to be contained in the token; the token can refer to the
> context data elsewhere if that is appropriate for the mechanism.
>
> To use your file descriptor analogy, consider a function which changes
> the owner of a file and then releases a lock. If releasing the lock
> somehow fails, it is impossible to "unchown" the file. You don't want
> to release the lock first due to the nature of locking and races.
>
> It would be nice to either {succeed/create the token/destroy the
> context}, or {fail/not create the token/leave the context untouched},
> but some mechanisms cannot guarantee one of these states.
I'm not sure this applies here. Context export is not an irreversible
operation. Even if a gssapi mechanism wants to implement a policy for
context "delegation", a process that just exported a context should
always be allowed to reimport the context immediately. I think this makes
it impossible to have irreversible operations during context export.
>
> With respect to recovery, what do you do if closing a file descriptor
> fails? IMHO, this is similar.
If I was just reading the file, I ignore it completely.
If I was writing the file, then I might have to worry if that data
that I was writing needs to be readable at some point in the future.
For context deletion, I basically ignore the returned status at the
application layer; I might log the event under "curiosities".
A gssapi security context doesn't do "buffering" at any level, so
it is a readonly object for the application. A failure upon context
deletion is "interesting during development / for debugging" at best,
it should never affect the operation of an application.
-Martin
Received: from ietf.org by ietf.org id aa27328; 6 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa26286; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rolc-nhrp-11.txt
Date: Thu, 06 Mar 1997 09:43:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26286 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : NBMA Next Hop Resolution Protocol (NHRP)
Author(s) : J. Luciani, D. Katz, D. Piscitello, B. Cole
Filename : draft-ietf-rolc-nhrp-11.txt
Pages : 48
Date : 03/05/1997
This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP
can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
internetworking layer address and NBMA subnetwork addresses of the "NBMA
next hop" towards a destination station. If the destination is connected
to the NBMA subnetwork, then the NBMA next hop is the destination station
itself. Otherwise, the NBMA next hop is the egress router from the NBMA
subnetwork that is "nearest" to the destination station. NHRP is intended
for use in a multiprotocol internetworking layer environment over NBMA
subnetworks.
Note that while this protocol was developed for use with NBMA subnetworks,
it is possible, if not likely, that it will be applied to BMA
subnetworks as well. However, this usage of NHRP is for further study.
This document is intended to be a functional superset of the NBMA Address
Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across
an NBMA subnetwork between two routers will be addressed in a separate
document (see [13]).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rolc-nhrp-11.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rolc-nhrp-11.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rolc-nhrp-11.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305145755.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rolc-nhrp-11.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rolc-nhrp-11.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305145755.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28288; 6 Mar 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa26300; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hethmon-mlst-command-ftp-01.txt
Date: Thu, 06 Mar 1997 09:43:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26300 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MLST Command and Extensions to FTP
Author(s) : P. Hethmon
Filename : draft-hethmon-mlst-command-ftp-01.txt
Pages : 10
Date : 03/05/1997
In order to overcome the problems inherent in the current FTP LIST output,
a new command is needed to transfer standardized listing information from
Server-FTP to Client-FTP. In addition, a way for the Server-FTP to let the
Client-FTP know of this capability without imposing on the Client-FTP to
randomly try new commands is needed. This proposal meets both of these
requirements.
This proposal also extends the FTP protocol to allow character sets other
than US-ASCII[1] by allowing the transmission of 8-bit characters and the
recommended use of UTF-8[2] encoding.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hethmon-mlst-command-ftp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hethmon-mlst-command-ftp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hethmon-mlst-command-ftp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305151902.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hethmon-mlst-command-ftp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hethmon-mlst-command-ftp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305151902.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28297; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26217; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-warwick-tokenring-01.txt
Date: Thu, 06 Mar 1997 09:43:19 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26217 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dedicated Token Ring Interface MIB
Author(s) : K. Lee, T. Warwick
Filename : draft-warwick-tokenring-01.txt
Pages : 36
Date : 03/05/1997
This document contains an extract from Draft 7 of the IEEE standard 802.5R
"Dedicated Token Ring". The extract comprises the Interface MIB for the
Dedicated Token Ring interface, in SNMPv2 format. Draft 7 is now
undergoing an IEEE sponsor ballot that is expected to complete in April
1997, and has also been submitted for ballot to ISO. No major changes to
the MIB are expected as a result of these ballots.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use tokens
for data transmission.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-warwick-tokenring-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-warwick-tokenring-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-warwick-tokenring-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305134623.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-warwick-tokenring-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-warwick-tokenring-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305134623.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28298; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26182; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: find at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-find-cip-ldap-01.txt
Date: Thu, 06 Mar 1997 09:43:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26182 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Indexing Protocol
Working Group of the IETF.
Title : A Tagged Index Object for use
in the Common Indexing Protocol
Author(s) : R. Hedberg, B. Greenblatt, R. Moats, M. Wahl
Filename : draft-ietf-find-cip-ldap-01.txt
Pages : 18
Date : 03/05/1997
This document defines a mechanism by which information servers can exchange
indices of information from their databases by making use of the Common
Indexing Protocol (CIP). This document defines the structure of the index
information being exchanged, as well as a the structure of the index
information being exchanged, as well as a the Indexing Protocol. It is
assumed that the structures defined here can be used by X.500 DSAs, LDAP
servers, whois++ servers, CCSO servers and many others.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-find-cip-ldap-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-cip-ldap-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-find-cip-ldap-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305133303.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-cip-ldap-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-cip-ldap-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305133303.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28303; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26250; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leiba-imap-idle-00.txt
Date: Thu, 06 Mar 1997 09:43:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26250 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 IDLE command
Author(s) : B. Leiba
Filename : draft-leiba-imap-idle-00.txt
Pages : 4
Date : 03/05/1997
The Internet Message Access Protocol [IMAP4] requires a client to poll the
server for changes to the selected mailbox (new mail, deletions). It's
often more desirable to have the server transmit updates to the client in
real time. This allows a user to see new mail immediately. It also helps
some real-time applications based on IMAP, which might otherwise need to
poll extremely often (such as every few seconds). (While the spec actually
does allow a server to push EXISTS responses aysynchronously, a client
can't expect this behaviour and must poll.)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-leiba-imap-idle-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leiba-imap-idle-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leiba-imap-idle-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305140412.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leiba-imap-idle-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leiba-imap-idle-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305140412.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28284; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26233; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-jeya-vlan-8021q-mib-00.txt
Date: Thu, 06 Mar 1997 09:43:22 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26233 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for
IEEE 802.1q Virtual LAN Bridges
Author(s) : I. Jeyasubramanian
Filename : draft-jeya-vlan-8021q-mib-00.txt
Pages : 12
Date : 03/05/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP based internets. In
particular it defines objects for managing bridges based on the
IEEE 802.1q draft standard between Local Area Network (LAN) segments.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-jeya-vlan-8021q-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-jeya-vlan-8021q-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-jeya-vlan-8021q-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305135022.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-jeya-vlan-8021q-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-jeya-vlan-8021q-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305135022.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28290; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26166; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-faynberg-telephone-sw-net-00.txt
Date: Thu, 06 Mar 1997 09:43:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26166 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Proposal for Internet and Public Switched Telephone
Networks (PSTN) Internetworking
Author(s) : I. Faynberg, M. Krishnaswamy, H. Lu
Filename : draft-faynberg-telephone-sw-net-00.txt
Pages : 10
Date : 03/05/1997
The purpose of this Internet Draft is to start discussion on the issues
involved in interconnecting Internet and Public Switched Networks so as to
provide more effective media than either network type can do presently.
Interworking of the Internet and PSTNs, based on open well-defined
interfaces, will promote interoperability of both the networks and systems
built by different vendors.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-faynberg-telephone-sw-net-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-faynberg-telephone-sw-net-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-faynberg-telephone-sw-net-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305143610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-faynberg-telephone-sw-net-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-faynberg-telephone-sw-net-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305143610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28286; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26321; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
cc: dns-security at tis.com
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-lewis-dnsnxt-semantics-00.txt
Date: Thu, 06 Mar 1997 09:43:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26321 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Semantics of DNS NXT Resource Records
Author(s) : E. Lewis, O. Gudmundsson
Filename : draft-lewis-dnsnxt-semantics-00.txt
Pages : 16
Date : 03/05/1997
In "Domain Name System Security Extensions" (RFC 2065) the NXT Resource
Record (along with SIG RR and KEY RR) is introduced to allow for secure
denial of existence of either a domain name or a RRSet belonging to an
existing domain name. The set of NXT records within a zone create a
virtual "chain" of RRSets within a zone by indicating, for each name within
a zone, the RRSets for which it owns records and the next name in the zone.
RFC 2065 discusses security extensions for static DNS zones. An Internet
Draft, draft-ietf-dnssec-update-04.txt, becoming an RFC describes security
in DNS zone which can be dynamically updated. In this document, the
authors build upon them to:
- define some terms used colloquially in the working group
- describe the semantics of the NXT record in greater detail
than the two existing documents, in order to achieve interoperability
- introduce and discuss unresolved issues involving NXT records
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-lewis-dnsnxt-semantics-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lewis-dnsnxt-semantics-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lewis-dnsnxt-semantics-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305173743.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lewis-dnsnxt-semantics-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lewis-dnsnxt-semantics-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305173743.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28293; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26201; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-warwick-tokenring-arch-01.txt
Date: Thu, 06 Mar 1997 09:43:17 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26201 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dedicated Token Ring Concentrator MIB
Author(s) : K. Lee, T. Warwick
Filename : draft-warwick-tokenring-arch-01.txt
Pages : 39
Date : 03/05/1997
This document contains an extract from Draft 7 of the IEEE standard 802.5R
"Dedicated Token Ring". The extract comprises the MIB for the Dedicated
Token Ring Concentrator, in SNMPv2 format. Draft 7 is now undergoing an
IEEE sponsor ballot that is expected to complete in April 1997, and has
also been submitted for ballot to ISO. No major changes to the MIB are
expected as a result of these ballots.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use tokens
for data transmission.
The architecture of a DTR Concentrator is defined in the 802.5R standard.
It is a MAC layer bridging device, which uses a new set of forwarding rules
that ease interoperability between source routing and transparent bridging
in an 802.5 LAN. The DTR Concentrator MIB is derived from the Source
Routing and Transparent Bridge MIBs (RFCs 1525 and 1493).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-warwick-tokenring-arch-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-warwick-tokenring-arch-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-warwick-tokenring-arch-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305134343.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-warwick-tokenring-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-warwick-tokenring-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305134343.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28304; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26149; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-romanov-00.txt
Date: Thu, 06 Mar 1997 09:43:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26149 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Practical Approach to Improving Scalability and
Interoperability of SNMP Applications
Author(s) : A. Romanov
Filename : draft-rfced-info-romanov-00.txt
Pages : 34
Date : 03/04/1997
The goal of this memo is to provide a simple solution for apparent
practical problem of scalability and interoperability of network
management applications.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-romanov-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-romanov-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-romanov-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970304165929.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-romanov-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-romanov-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970304165929.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28248; 6 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa26275; 6 Mar 97 9:43 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-exp-elliston-00.txt
Date: Thu, 06 Mar 1997 09:43:29 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703060943.aa26275 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Encapsulating IP with the Small Computer System
Interface
Author(s) : B. Elliston
Filename : draft-rfced-exp-elliston-00.txt
Pages : 4
Date : 03/05/1997
As the capacity of local area networks increases to meet the demands of
high volume application data, there is a class of network intensive
problems which may be applied to small clusters of workstations with high
bandwidth interconnection.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-exp-elliston-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-exp-elliston-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-exp-elliston-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970305150417.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-exp-elliston-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-exp-elliston-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970305150417.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00179; 6 Mar 97 10:30 EST
Received: from ietf.ietf.org by ietf.org id aa29794; 6 Mar 97 10:24 EST
To: ietf at ietf.org
Subject: Re: MUX Modems (was Re: RFC 1990)
Sender:ietf-request at ietf.org
From: I <JonDavis at hehe.com>
Date: Thu, 06 Mar 1997 10:24:55 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703061024.aa29794 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
It appears perhaps you have mistaken my endeavors of reverse multiplexing
(multiple lines, one connection) on POTS lines with standard multiplexing
(single modem, multiple uses). Other than the structure for RFC 1990, no
modem (that I know of) is capable of containing more than one telephone
line for a single purpose==higher data bandwidth. A single 2-line
56k-compatible modem in this case would reach speeds of 2 B channels in the
ISDN world, at the mere cost of two standard modem connections.
Please e-mail me if I am mistaken that there are no such modems. I would
like to pursue this if no one already has or if no one considers it a waste
of time.
When I have completed appropriate research, I will present the entire
outline (in the form of a URL) to IETF to approach standardization...
again, that is another thing I am open to comments about.
-Jon Davis
NewBreed Communications
http://www.interact-net.com/design
jon at interact-net.com
Received: from cnri by ietf.org id aa05789; 6 Mar 97 11:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12296;
6 Mar 97 11:37 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA04891 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 14:31:43 GMT
Message-Id: <199703061431.JAA02485 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Comments solicited re negotiated mechanism action
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 06 Mar 1997 09:31:38 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT/negotiated mechanism-interested people:
When Simple Negotiation (draft-ietf-cat-snego-02.txt) was discussed at the
San Jose meeting, controversy arose around interest in development of an
alternate proposal which would apply protection to the negotiation process.
The working plan of record, as cited in the San Jose minutes, was that
an alternate proposal would be defined and circulated in January for
group comparison with SNEGO in February, at which point the group would
consider an advancement recommendation. I believe that there's group
consensus on the value of advancing a negotiated mechanism, but the
alternate proposal contemplated at San Jose has not yet emerged.
Shall we proceed to WG Last-Call on advancement of draft-ietf-cat-snego-02.txt
to Proposed Standard, is alternate proposal development active with a
new target date, and/or does anyone have other suggestions or preferences
to offer as to how the group should now proceed in this area? I'd appreciate
any comments to the list by Friday, 14 March.
Thanks,
--jl
Received: from ietf.org by ietf.org id aa08292; 6 Mar 97 12:00 EST
Received: from cnri by ietf.org id aa07901; 6 Mar 97 11:54 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12606;
6 Mar 97 11:54 EST
Received: from garlic.com by venera.isi.edu (5.65c/5.61+local-26)
id <AA22328>; Thu, 6 Mar 1997 08:51:49 -0800
Received: from WW2 by garlic.com (8.8.5/4.03)
id QAA73270; Thu, 6 Mar 1997 16:51:14 GMT
Date: Thu, 6 Mar 1997 16:51:14 GMT
Message-Id: <199703061651.QAA73270 at garlic.com>
Sender:ietf-request at ietf.org
From: Anne & Lynn Wheeler <lynn at garlic.com>
To: ietf at isi.edu
Subject: my index & restored RFCs
Reply-To: Anne & Lynn Wheeler <lynn at garlic.com>
Source-Info: From (or Sender) name not authenticated.
noticed bunch of restored RFCs went up yesterday at ISI and today
at internic ... i've modified my index
http://www.garlic.com/~lynn/rfcietf.html
to support the filename variation (i.e. rfcon###.txt instead of
rfc###.txt).
Received: from cnri by ietf.org id aa13219; 6 Mar 97 12:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13712;
6 Mar 97 12:39 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA06694 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 15:11:22 GMT
Message-Id: <9703061503.AA29664 at us1rmc.bb.dec.com>
Date: Thu, 6 Mar 97 10:03:18 EST
From: "John Wray, Digital DPE, (508) 486-5210 06-Mar-1997 0950" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, martin.rex at sap-ag.de
Subject: Re: OIDs and OID sets (again)
Precedence: bulk
Martin wrote:
>John Wray, Digital DPE, wrote:
>> I think we still have a minor problem with dynamic vs. static OIDs & OID sets.
>>
>> The consensus from the San Jose meeting was that we should remove the str<->oid
>> functions from the GSSAPI spec with the purpose of making all GSSAPI-created
>> OIDs static (non-freeable), and we subsequently seem to have reached agreement
>> that OID-sets should be dynamically allocated (i.e. the application must call
>> gss_release_oid_set() to free them).
>
>Actually, this is interesting:
>We agreed that the application must call gss_release_oid_set() to RELEASE
>them.
>
>We didn't discuss if you are allowed to pass OID_sets to add_oid_set_member
>OTHER than those created by create_empty_oid_set and those modified
>by add_oid_set_member.
>
>I would object to any application that tries to feed into add_oid_set_member
>an OID_set that was returned from any of acquire_cred(), add_cred(),
>indicate_mechs(), inquire_cred(), inquire_mechs_for_name and
>inquire_names_for_mech(). Otherwise all OID_sets will have to be completely
>dynamic, especially the one returned from indicate_mechs.
I don't think we need to support OID-sets that were built "by hand" by the
application as input to add_oid_set_member() (after all, if you want to
roll-your-own OID-sets, that's what create_empty_oid_set() and
add_oid_set_member() are for); however it seems unnecessarily restrictive to
prevent the application from using any other GSSAPI-create OID-set. For
example, I could imagine an application that wanted to create a credential just
like an existing one, but with two specific additional mechanisms. It could
call inquire_cred() to get the mechanisms for the existing credential, then
add_oid_set() twice to add the two new mechanism OIDs, then acquire_cred() to
create a new credential. I don't see why we should prohibit this behavior
(even though the app could just call add_cred twice to get the same effect).
I don't see a problem with all OID-sets being dynamic. Indeed, the decision in
V1 to define some OIDs as being static led to all sorts of problems which we
still haven't really solved. The OID-set you mention - the one returned by
indicate_mechs - will have to be specified as dynamic anyway (or at least, the
applicationj will have to invoke gss_release_oid_set() to delete it), since
that's the only way to support dynamic loading of mechanisms.
John
Received: from cnri by ietf.org id aa19107; 6 Mar 97 14:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15387;
6 Mar 97 14:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA08171 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 15:45:53 GMT
Message-Id: <9703061538.AA02594 at us1rmc.bb.dec.com>
Date: Thu, 6 Mar 97 10:38:29 EST
From: "John Wray, Digital DPE, (508) 486-5210 06-Mar-1997 1004" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, martin.rex at sap-ag.de
Subject: Re: OIDs and OID sets (again)
Precedence: bulk
Martin wrote:
>To avoid ANY possible problems with different heap allocators, especially
>in shared library environments, it is necessary that objects are entirely
>managed by one single service provider (library). I.e. oid_sets returned
>by a gssapi mechanism have to completely managed and owned by the mechanism.
>
>How a mechanism composes compound objects is a local matter (i.e.
>implementation detail outside of the spec). If a mechanism creates oid_sets
>that refer to static OID-elements octet strings, then it is responsible to
>handle them correctly within gss_release_oid_set.
I don't think this is right. If the _mechanism_ creates static OID-elements
within OID-sets, that's fine, but that's an internal matter between GSSAPI and
the mechanism. What GSSAPI returns to the application should be a fully
dynamic OID-set, or at least something that behaves as if it were fully dynamic
as far as the application is concerned. If a particular GSSAPI/mechanism
implementation wants to optimize this by using static elements, that's OK
provided the application-visible behavior of the sets isn't affected.
There is no defined internal API between "GSSAPI" and "the mechanism", and I
think that's the problem.
>Glue layers that add up gssapi mechanisms to a multimechanism will have
>either have to know about the nature of the oid_sets of the submechanisms,
>or they will have to register or clone the oid_sets while they still know
>which submechanism created the oid_set, so that it can later be released
>correctly.
It's never been an explicit requirement that the GSSAPI spec should support
recursive implementations - i.e. implementations where two mechanisms that each
export a single-mechanism GSSAPI are joined together with a glue layer to
export one multi-mechanism GSSAPI. I expect that an efficient implementation
of this model would require more than just GSSAPI as the interface between the
individual mechanisms and the glue layer.
If glue-layers constructed like this have to clone OID-sets, so be it.
I believe that once we define a GSS-SPI to help the construction of
mechanism-independent GSSAPI libraries, we can deal with this. While most of
the functionality of this SPI would be to allow the GSSAPI layer to invoke
per-mechanism functions (probably mostly single-mechanism analogs of the GSSAPI
functions), it can also include functions exported by GSSAPI that a mechanism
implementation can call. So the GSS-SPI could include GSSAPI-provided
gss_create_empty_oid_set() and gss_add_oid_set_member() functions, allowing any
mechanism to create GSS-compliant OID-sets, and conformance to this SPI by a
machanism would include a requirement that all OID-sets passed to GSSAPI by a
mechanism would be created using these functions. This would remove the need
for cloning OID-sets, since the GSSAPI layer would be responsible for all
OID-set storage management.
John
Received: from cnri by ietf.org id aa21273; 6 Mar 97 14:42 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16090;
6 Mar 97 14:42 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA08919 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 16:03:41 GMT
Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970306155202Z-14401 at bwdldb.ott.bnr.ca>
From: Carlisle Adams <Cadams at entrust.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'linn at cam.ov.com'" <linn at cam.ov.com>
Subject: RE: Comments solicited re negotiated mechanism action
Date: Thu, 6 Mar 1997 10:52:02 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 43 TEXT
Precedence: bulk
Hi,
>----------
>From: linn at cam.ov.com[SMTP:linn at cam.ov.com]
>Sent: Thursday, March 06, 1997 9:31 AM
>To: cat-ietf at mit.edu
>Cc: linn at cam.ov.com
>Subject: Comments solicited re negotiated mechanism action
>
>CAT/negotiated mechanism-interested people:
>
>When Simple Negotiation (draft-ietf-cat-snego-02.txt) was discussed at the
>San Jose meeting, controversy arose around interest in development of an
>alternate proposal which would apply protection to the negotiation process.
>The working plan of record, as cited in the San Jose minutes, was that
>an alternate proposal would be defined and circulated in January for
>group comparison with SNEGO in February, at which point the group would
>consider an advancement recommendation. I believe that there's group
>consensus on the value of advancing a negotiated mechanism, but the
>alternate proposal contemplated at San Jose has not yet emerged.
>
>Shall we proceed to WG Last-Call on advancement of
>draft-ietf-cat-snego-02.txt
>to Proposed Standard, is alternate proposal development active with a
>new target date, and/or does anyone have other suggestions or preferences
>to offer as to how the group should now proceed in this area? I'd appreciate
>any comments to the list by Friday, 14 March.
The way I remember the meeting, the alternate proposal had a hard
deadline. Since that deadline has now passed, it seems (in fairness to
the SNEGO authors) that the existing draft should go to Last Call. Of
course this does not prevent the potential authors of the alternate
proposal from going ahead and submitting a draft anyway. However, if
there really is group consensus on the value of a negotiated mechanism
(and I agree with John that there seems to be), then I see no reason to
continue holding up last call...
--------------------------------------
Carlisle Adams
Entrust Technologies
cadams at entrust.com
---------------------------------------
Received: from cnri by ietf.org id aa22569; 6 Mar 97 15:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16769;
6 Mar 97 15:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14595 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:07:40 GMT
Date: Thu, 6 Mar 1997 13:07:19 -0500
Message-Id: <199703061807.NAA18788 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: J.Lebastard at frcl.bull.fr, cat-ietf at mit.edu
In-Reply-To: <199703052023.AA10310 at sap-ag.de> (message from Martin Rex on Wed,
5 Mar 1997 15:24:06 -0500 (EST))
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 5 Mar 1997 15:24:06 -0500 (EST)
It's true that RFC2078 says that "the context will be invalid
after export", so it might need to be clarified, but the C-Bindings
and Ted's original proposal pass the context_handle by reference --
so that it can be wiped when the operation succeeds.
Well, given you calling gss_delete_sec_context on an invalid context is
undefined, I'd think RFC-2078 is quite clear, but we can make things
much more explicit in the C-bindings. Certainly the krb5
export_sec_context implementation that I've done frees the context upon
a successful contextr export.
- Ted
Received: from cnri by ietf.org id aa24255; 6 Mar 97 16:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17944;
6 Mar 97 16:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14497 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:04:54 GMT
Date: Thu, 6 Mar 1997 13:04:21 -0500
Message-Id: <199703061804.NAA18784 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: marc at cygnus.com
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: <t53n2siw043.fsf at rover.cygnus.com> (message from Marc Horowitz on
05 Mar 1997 15:32:44 -0500)
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Marc Horowitz <marc at cygnus.com>
Date: 05 Mar 1997 15:32:44 -0500
I think the context should be made inaccessible. This is clear and
unambiguous. If the implementation doesn't support transferrable
contexts, then there the flags returned from
gss_init/accept_sec_context will indicate this. If there's some other
failure, I can't imagine any kind of sensible recovery process.
The recovery process is easy; just free the flat exportable security
context token that you were busy building. We have it in the krb5 code
already; first you build the exportable flat context token, and only
after you've successfully built it, do you free the gss context.
- Ted
Received: from cnri by ietf.org id aa24391; 6 Mar 97 16:20 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18025;
6 Mar 97 16:20 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA13224 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 17:36:43 GMT
Message-Id: <9703061723.AA11366 at us1rmc.bb.dec.com>
Date: Thu, 6 Mar 97 12:23:54 EST
From: "John Wray, Digital DPE, (508) 486-5210 06-Mar-1997 1147" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, martin.rex at sap-ag.de
Subject: Re: gss_export_sec_context()
Precedence: bulk
Martin writes:
>>
>> >The equivalent of delete_sec_context() should be called as the very last
>> >action of export_context().
>>
>> With the one proviso that not all the functionality of delete_sec_context() may
>> be wanted: in particular, if some context-specific state has to be retained in
>> order for the context to be imported in another process, that state obviously
>> shouldn't be deleted.
>
>Your last comment frightens me. You should not keep ANY context-specific
>state around in the process image of the process that does the export!
>
>(1) It's NOT ok for a gss-api mechanism to leak memory for
> context_export/context_import activity.
>(2) An application may decide to memset an exported security context to
> zero, while the gssapi mechanism must still conform to (1).
>(3) A context import may fail with GSS_S_CONTEXT_EXPIRED or other
> error codes, in which case an application will probably do (2).
>(4) The context-exporting process may exit before the exported context
> will be imported by another process.
> (I'm going to implement security context caching for specific
> client applications that will require this characteristic,
> mainly to improve performance for public key based authentication
> and to save round trips on the average).
Hmm. These are new requirements (at least, as far as I know, they've never
been stated expicitly before).
I've been viewing an interprocess token sort-of like a capability - something
that can be used to get at a context by the second process. There's not been
an explicit requirement that all the information needed to re-build the context
is contained in the interprocess token, although that's certainly one way of
implementing it. On the other hand, it should be acceptable to build a kernel
GSSAPI implementation where contexts are maintained in shared protected memory,
and accessed by processes via handles, with the GSSAPI enforcing
access-control. In such a model, the interprocess token provides a way for
access to a given context to be transferred to another process, but the context
itself is never actually passed around.
This sort of implementation has to be able to garbage-collect contexts that the
application has forgotten to delete. This would normally be triggered on
process-exit, but if the app has created an interprocess token, that won't work
if we have to be able to satisfy your requirement 4 above. I guess a context
can always be garbage-collected when it expires.
Should requirement 4 be a requirement on all GSSAPI implementations? Do we
want to mandate how long an exported context will remain importable, after the
original process goes away? Should it last across system reboots, if the
application stores the token in a file, for example? Or can this be left up to
individual implementations? There are already some words to the effect that an
implementation can impose its own access-control on context import/export, so
maybe this covers everything.
I don't believe that memsetting an interprocess token to zero should be the
"approved" way to change your mind about importing it. If you really need this
functionality, it would be better to have an additional
gss_release_exported_context() or gss_release_interprocess_token() call that
would do whatever's necessary to release resources and erase any sensitive
information in the token. That way, if the GSSAPI implementation does save
context information elsewhere than in the token, then it can be scrubbed and
released.
John
Received: from cnri by ietf.org id aa24864; 6 Mar 97 16:35 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18291;
6 Mar 97 16:35 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14426 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:02:17 GMT
Date: Thu, 6 Mar 1997 13:01:55 -0500
Message-Id: <199703061801.NAA18780 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: <199703051940.AA07350 at sap-ag.de> (message from Martin Rex on Wed,
5 Mar 1997 14:41:17 -0500 (EST))
Subject: Re: OIDs and OID sets (again)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 5 Mar 1997 14:41:17 -0500 (EST)
We didn't discuss if you are allowed to pass OID_sets to
add_oid_set_member OTHER than those created by create_empty_oid_set
and those modified by add_oid_set_member.
I would object to any application that tries to feed into
add_oid_set_member an OID_set that was returned from any of
acquire_cred(), add_cred(), indicate_mechs(), inquire_cred(),
inquire_mechs_for_name and inquire_names_for_mech(). Otherwise all
OID_sets will have to be completely dynamic, especially the one
returned from indicate_mechs.
I think OID sets should always be completely dynamic. It simplifies
things immensely. The advantage of making some OID sets be static is
relatively small, given that applications have to always assume that OID
sets be dynamic and call gss_release_oid_set() to avoid memory leaks.
The confusion caused by having some OID_sets being OK for some
operations (like add_oid_set_member()), and some not being OK for some
operations is only going to cause hard-to-find bugs. I really don't
think it's worth the small marginal increase in simplicity in the
mechanism code.
- Ted
Received: from cnri by ietf.org id aa25477; 6 Mar 97 16:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18712;
6 Mar 97 16:57 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA18969 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 19:51:15 GMT
Message-Id: <199703061950.LAA02885 at fluffy.cisco.com>
To: Carlisle Adams <Cadams at entrust.com>
Cc: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'linn at cam.ov.com'" <linn at cam.ov.com>
Subject: Re: Comments solicited re negotiated mechanism action
In-Reply-To: Your message of "Thu, 06 Mar 1997 10:52:02 EST."
<c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970306155202Z-14401 at bwdldb.ott.bnr.ca>
Date: Thu, 06 Mar 1997 11:50:53 -0800
From: Derrell Piper <piper at cisco.com>
Precedence: bulk
>The way I remember the meeting, the alternate proposal had a hard
>deadline. Since that deadline has now passed, it seems (in fairness to
>the SNEGO authors) that the existing draft should go to Last Call. Of
>course this does not prevent the potential authors of the alternate
>proposal from going ahead and submitting a draft anyway. However, if
>there really is group consensus on the value of a negotiated mechanism
>(and I agree with John that there seems to be), then I see no reason to
>continue holding up last call...
Yeah, that's what I remember too...
Derrell
Received: from cnri by ietf.org id aa28032; 6 Mar 97 17:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19598;
6 Mar 97 17:38 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA18317 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 19:35:05 GMT
Message-Id: <199703061934.AA01639 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: protecting empty messages?
To: cat-ietf at mit.edu
Date: Thu, 6 Mar 1997 14:34:25 -0500 (EST)
In-Reply-To: <199703061046.FAA16081 at Twig.Rodents.Montreal.QC.CA> from "der Mouse" at Mar 6, 97 05:46:15 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Ooops, there seems to be an assumption in ftpsec that I do not
consider obvious from the GSS-API spec:
Support for "protecting" zero-length messages:
draft-ietf-cat-ftpsec-09.txt:
6. Data Channel Encapsulation
[...]
The sender must take the input byte stream, and break it up into
blocks such that each block, when encoded using a security mechanism
specific procedure, will be no larger than the buffer size negotiated
by the client with the PBSZ command. Each block must be encoded,
then transmitted with the length of the encoded block prepended as a
four byte unsigned integer, most significant byte first.
When the end of the file is reached, the sender must encode a block
of zero bytes, and send this final block to the recipient before
closing the data connection.
The recipient will read the four byte length, read a block of data
that many bytes long, then decode and verify this block with a
security mechanism specific procedure. This must be repeated until a
block encoding a buffer of zero bytes is received. This indicates
the end of the encoded byte stream.
This sounds like GSS-API mechanisms should be able to wrap an
"empty message", and that an "empty buffer" returned from gss_unwrap
with status GSS_S_COMPLETE is supposed to mean "empty message" instead
of "no message, strange mechanism behaviour".
If support for protection of emtpy messages is to be required by
GSS-API, then I'd like this to be explicitly mentioned in the spec.
-Martin
Received: from cnri by ietf.org id aa28589; 6 Mar 97 17:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19980;
6 Mar 97 17:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA21099 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 20:43:55 GMT
To: Theodre Ts'o <tytso at lurch.mit.edu>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <199703061804.NAA18784 at lurch.mit.edu>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 15:43:53 -0500
In-Reply-To: "Theodre Ts'o"'s message of Thu, 6 Mar 1997 13:04:21 -0500
Message-Id: <t533eu8wy2e.fsf at rover.cygnus.com>
Lines: 12
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"Theodre Ts'o" <tytso at lurch.mit.edu> writes:
>> The recovery process is easy; just free the flat exportable security
>> context token that you were busy building. We have it in the krb5 code
>> already; first you build the exportable flat context token, and only
>> after you've successfully built it, do you free the gss context.
This is fine for krb5, which can atomically export a context. As my
previous messages have stated, I'm unconvinced that this is possible
for all mechanisms.
Marc
Received: from cnri by ietf.org id aa28915; 6 Mar 97 18:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20233;
6 Mar 97 18:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14609 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:08:18 GMT
Message-Id: <199703061807.KAA10076 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Thu, 6 Mar 97 10:07:51 -0800
To: John Linn <linn at cam.ov.com>
Subject: Re: Comments solicited re negotiated mechanism action
Cc: cat-ietf at mit.edu
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <199703061431.JAA02485 at gza-client1.cam.ov.com>
Precedence: bulk
> Date: Thu, 06 Mar 1997 09:31:38 -0500
> From: John Linn <linn at cam.ov.com>
>
> CAT/negotiated mechanism-interested people:
>
> When Simple Negotiation (draft-ietf-cat-snego-02.txt) was
> discussed at the San Jose meeting, controversy arose around
> interest in development of an alternate proposal which would
> apply protection to the negotiation process. The working plan
> of record, as cited in the San Jose minutes, was that an
> alternate proposal would be defined and circulated in January
> for group comparison with SNEGO in February, at which point the
> group would consider an advancement recommendation. I
> believe that there's group consensus on the value of advancing
> a negotiated mechanism, but the alternate proposal
> contemplated at San Jose has not yet emerged.
>
> Shall we proceed to WG Last-Call on advancement of
> draft-ietf-cat-snego-02.txt to Proposed Standard, is
> alternate proposal development active with a new target date,
> and/or does anyone have other suggestions or preferences to
> offer as to how the group should now proceed in this area? I'd
> appreciate any comments to the list by Friday, 14 March.
>
I was unable to attend San Jose, please forgive my ignorance.
See you in Memphis. :)
I vote for snego, as it stands, to advance to informational or
experimental and another approach pursued. Perhaps too we
should start on GSS-APIv3, not backward compatible with v1 and
v2, and addresses GSS-APIv2's shortcomings, such as nego,
configuration, thread safety, single sign-on, etc.
-dpg
Received: from cnri by ietf.org id aa28961; 6 Mar 97 18:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20254;
6 Mar 97 18:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA14926 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 18:15:05 GMT
Date: Thu, 6 Mar 1997 13:14:27 -0500
Message-Id: <199703061814.NAA18793 at lurch.mit.edu>
From: Theodre Ts'o <tytso at lurch.mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: <199703060005.AA25564 at sap-ag.de> (message from Martin Rex on Thu,
6 Mar 1997 01:05:47 +0100 (MEZ))
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Thu, 6 Mar 1997 01:05:47 +0100 (MEZ)
When trying to build a gssapi mechanism that can dynamically load existing
gssapi mechanisms, then one cannot see from the interprocess token emitted
by export_sec_context by which mechanism implementation it was actually
created. The glue-layer would have to add a wrapper when export_sec_context
returns from the mechanism, and this could fail with "out-of-memory".
In this situation it might be impossible to operate atomically.
This is a good point. There are some ways to get around this problem in
principal (preallocate a very large buffer before calling the
mechanism-specific export_sec_context(), and then use that large buffer
to store the exported token plus the mechanism glue framing).
Mandating a framing for the interprocess token similar to exported
names would improve the situation somewhat, but I doubt it's a panacea.
The exported names are to be specified in *all* details in the
gssapi mechanism specification; interprocess tokens are meaningful to
one specific implementation only, and they should remain like that.
Well, we could mandate that the token has to be framed similar to the
way the initial init_sec_context token is framed. That specifies much
less (just what has to be at the begining of a token, to disambiguate
one mechanism from another).
Do we want to do something about this?
Are there other/more routines where layering does/will interfere with
atomic operation?
init_sec_context() and accept_sec_context() likely have similar
problems, although in general applications generally assume that the
entire security context negotiation has failed when these errors occur,
instead of trying to retry them somehow.
- Ted
Received: from cnri by ietf.org id aa00113; 6 Mar 97 18:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20935;
6 Mar 97 18:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA22783 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 21:23:41 GMT
Date: Thu, 6 Mar 1997 16:22:59 -0500 (EST)
From: der Mouse <mouse at rodents.montreal.qc.ca>
Message-Id: <199703062122.QAA17067 at Twig.Rodents.Montreal.QC.CA>
To: Marc Horowitz <marc at cygnus.com>
Cc: jis at mit.edu, linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
Precedence: bulk
> I believe that all of them are easily addressed editorially, [...]
I suspect you are right. Aside from the pure editorial changes (like
the bit about the 232 reply to USER), everything I mentioned could, for
some possible original intent, be nothing more than a minor
clarificative change, and they all seem to have turned out that way,
with the possible exception of the first one herein, which is still
unclear to me:
>>> protected control channel messages. The CCC command itself must
>>> be integrity protected.
[...]
>>> A server may require that the first command after a successful
>>> security data exchange be CCC, and not implement the protection
>>> commands at all. In this case, the server should respond with a
>> How can the CCC command be integrity protected if the server doesn't
>> implement at least MIC?
> This command was requested by HP, who has implemented it.
Yeah, I too can't quite see the point of CCC, but my point was not so
much that CCC is or isn't useless, as that the document seems to
contradict itself, saying that CCC must be integrity protected and then
stating fairly directly that it is possible to operate without
implementing the command that would be necessary to get that integrity
protection.
>>> 6. Data Channel Encapsulation
[...]
>>> When the end of the file is reached, the sender must encode a block
>>> of zero bytes, [...]
I just now noticed that this could be misunderstood to mean "a block
containing data bytes of value 0x00". While I don't think this is
likely to be a problem in practice, it's easy to fix with a minor
rewording (eg, "a zero-length block of bytes"), and unambiguous clarity
is generally a Good Thing for standards.
>> This appears to be considering only [...] the case where EOF is
>> indicated by closing the data channel.
>> Also, this encoding allows data-stream detection of EOF for STRU F,
>> MODE S transfers, [...]
> I think this issue can be solved by replacing the word "file" with
> the word "data channel", which was the intent.
Aha, yes, if that was the intent then I have no problem with the
mechanism, only with the (former) wording. :-)
> The reason to transmit an encoded block of zero bytes is to protect
> against an attacker prematurely closing the TCP stream.
Heh. Can you say "NT sniper bug"? :-)
>> I also note that no registry is defined for authentication mechanism
>> name strings - presumably this will be handled by the IANA, [...]
> In section 3:
> AUTHENTICATION/SECURITY MECHANISM (AUTH)
> The argument field is a Telnet string identifying a supported
> mechanism. This string is case-insensitive. Values must be
> registered with the IANA, except that values beginning with "X-"
> are reserved for local use.
> Do you think this is insufficient?
No. My apologies; I simply missed that sentence when reading it.
der Mouse
mouse at rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received: from cnri by ietf.org id aa00451; 6 Mar 97 19:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21152;
6 Mar 97 19:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA21091 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 20:43:17 GMT
To: der Mouse <mouse at rodents.montreal.qc.ca>
Cc: jis at mit.edu, linn at cam.ov.com
Cc: cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
References: <199703061046.FAA16081 at Twig.Rodents.Montreal.QC.CA>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 15:41:24 -0500
In-Reply-To: der Mouse's message of Thu, 6 Mar 1997 05:46:15 -0500 (EST)
Message-Id: <t534teowy6j.fsf at rover.cygnus.com>
Lines: 110
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
der Mouse <mouse at rodents.montreal.qc.ca> writes:
>> I have a few minor comments on draft-ietf-cat-ftpsec-09.txt.
Thank you for your comments. I believe that all of them are easily
addressed editorially, and therefore do not require me to produce
another draft, but I would like your opinion and the opinions of the
WG members, WG chair, and AD on this.
>> > CLEAR COMMAND CHANNEL (CCC)
>> [...]
>> > protected control channel messages. The CCC command itself must
>> > be integrity protected.
>> [...]
>> > INTEGRITY PROTECTED COMMAND (MIC) and
>> > CONFIDENTIALITY PROTECTED COMMAND (CONF) and
>> > PRIVACY PROTECTED COMMAND (ENC)
>> [...]
>> > A server may require that the first command after a successful
>> > security data exchange be CCC, and not implement the protection
>> > commands at all. In this case, the server should respond with a
>> [...]
>> > If the server has completed a security data exchange with the
>> > client using a mechanism which supports integrity, and requires a
>> > CCC command due to policy or implementation limitations, it should
>>
>> How can the CCC command be integrity protected if the server doesn't
>> implement at least MIC?
This command was requested by HP, who has implemented it. Since it
requires them to implement MIC, at least for CCC, I admit that I'm not
sure why it's worth the effort, but they seem to have implemented
this. If nobody else implements this command as the document
progresses, then the command will have to be dropped due to lack of
interoperating implementations, but we can deal with that then.
>> > If the server is willing to allow the user named by the USER command
>> > to log in based on the identity established by the security data
>> > exchange, it should respond with reply code 232.
>>
>> Presumably this refers to the response to the USER command; I think
>> this should be clarified.
Done.
>> > 6. Data Channel Encapsulation
>> [...]
>> > When the end of the file is reached, the sender must encode a block
>> > of zero bytes, and send this final block to the recipient before
>> > closing the data connection.
>>
>> This appears to be considering only STRU F, MODE S - ie, the case where
>> EOF is indicated by closing the data channel. I think it is important
>> to clarify how the mechanisms of this draft interact with STRU/MODE
>> combinations that do not involve creating and closing a new data
>> channel for each file transferred.
>>
>> Also, this encoding allows data-stream detection of EOF for STRU F,
>> MODE S transfers, transfers that normally would require closure of the
>> data connection to indicate EOF. Does this make it possible to
>> transfer multiple files over a single data connection when this would
>> not normally be possible? Whether or not, I think this should be
>> explicitly stated.
I think this issue can be solved by replacing the word "file" with the
word "data channel", which was the intent. The reason to transmit an
encoded block of zero bytes is to protect against an attacker
prematurely closing the TCP stream. This issue is independent of
structure and mode. To make this completely unambiguous, I can add a
paragraph:
The zero-byte block must be the last data transmitted by the sender
before the data channel TCP connection is closed. If the recipient
sees the connection close before this block is received, or if
additional data arrives after this block, then the recipient should
treat this as a message stream modification. If the server is unable
to send the final block, or detects one of the above conditions when
receiving, it should respond with reply code 535.
This change is clarifying only, not semantic.
>>
>> > 10. Base 64 Encoding
>> [...]
>> > Case must not be ignored when reading commands and replies containing
>> > base 64 encodings.
>>
>> This could be misread to imply that (for example) "mic" is not a valid
>> form of the command keyword for the MIC command.
Good point. I'll clarify this.
>> I also note that no registry is defined for authentication mechanism
>> name strings - presumably this will be handled by the IANA, but I'd
>> like to see it explicitly stated; in particular, people developing
>> mechanisms should be able to determine whom to get a registered name
>> for their mechanisms from.
In section 3:
AUTHENTICATION/SECURITY MECHANISM (AUTH)
The argument field is a Telnet string identifying a supported
mechanism. This string is case-insensitive. Values must be
registered with the IANA, except that values beginning with "X-"
are reserved for local use.
Do you think this is insufficient?
Marc
Received: from cnri by ietf.org id aa00786; 6 Mar 97 19:23 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21379;
6 Mar 97 19:22 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA20395 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 20:27:22 GMT
Message-Id: <199703062026.AA04947 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: John Wray Digital DPE <wray at tuxedo.enet.dec.com>
Date: Thu, 6 Mar 1997 15:26:28 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703061723.AA11366 at us1rmc.bb.dec.com> from "John Wray, Digital DPE," at Mar 6, 97 12:23:54 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, wrote:
> Martin writes:
> >Your last comment frightens me. You should not keep ANY context-specific
> >state around in the process image of the process that does the export!
> >
> >(1) It's NOT ok for a gss-api mechanism to leak memory for
> > context_export/context_import activity.
> >(2) An application may decide to memset an exported security context to
> > zero, while the gssapi mechanism must still conform to (1).
> >(3) A context import may fail with GSS_S_CONTEXT_EXPIRED or other
> > error codes, in which case an application will probably do (2).
> >(4) The context-exporting process may exit before the exported context
> > will be imported by another process.
> > (I'm going to implement security context caching for specific
> > client applications that will require this characteristic,
> > mainly to improve performance for public key based authentication
> > and to save round trips on the average).
>
>
> Hmm. These are new requirements (at least, as far as I know, they've never
> been stated expicitly before).
That's true, I've never explicitly stated that. But I was trying to
convince Denis Pinkas to use context export for context caching with
these things in mind.
My list of requirements is for interoperability with *our* application,
I don't ask to mandate these requirements for all GSS-API v2 mechanisms
that offer context transfer. How about adding another feature flag
to init_sec_context/accept_sec_context which indicates how robust the
implemented context transfer is?
>
> I've been viewing an interprocess token sort-of like a capability - something
> that can be used to get at a context by the second process. There's not been
> an explicit requirement that all the information needed to re-build the context
> is contained in the interprocess token, although that's certainly one way of
> implementing it. On the other hand, it should be acceptable to build a kernel
> GSSAPI implementation where contexts are maintained in shared protected memory,
> and accessed by processes via handles, with the GSSAPI enforcing
> access-control. In such a model, the interprocess token provides a way for
> access to a given context to be transferred to another process, but the context
> itself is never actually passed around.
>
> This sort of implementation has to be able to garbage-collect contexts that
> the application has forgotten to delete. This would normally be triggered on
> process-exit, but if the app has created an interprocess token, that won't
> work if we have to be able to satisfy your requirement 4 above. I guess a
> context can always be garbage-collected when it expires.
Garbage collection on context expiration should be possible.
GSS-API mechanisms that implement complicated policy stuff around
security context transfers might disqualify themselves for interoperation
with our application anyway, i.e. the overhead for a single operation
(import or export) must not exceed 3 milliseconds, or impact on the
transaction rate will become so significant, that a customer will
probably choose a different product/implementation/gss-api mechanism.
>
> Should requirement 4 be a requirement on all GSSAPI implementations? Do we
> want to mandate how long an exported context will remain importable, after
> the original process goes away? Should it last across system reboots, if the
> application stores the token in a file, for example? Or can this be left up
> to individual implementations? There are already some words to the effect
> that an implementation can impose its own access-control on context
> import/export, so maybe this covers everything.
I plan to cache the security contexts in a file to reuse them in successor
client processes. The server will most probably cache them in shared memory,
because it rarely restarts.
In our application environment a server will (soon) hold up to 10000 security
contexts in parallel, 99% of them dormant in exported state. Contexts will
only be imported to process client requests, and they will be exported right
after the reply for the client has been processed ("protected"). Many of
the clients are GUIs, so the sleeping periods of security contexts can be
arbitrarily long (hours, days, weeks in some cases). I do rely on context
expiring approximately at the same time (clock skew +- 5 Minutes),
independent of their state (imported or exported), so that I can renegotiate
a new context when the existing context is close to expiration or already
expired.
An absolutely required feature for our application is that an exported
security context survives termination of the process which did the
context export.
>
> I don't believe that memsetting an interprocess token to zero should be the
> "approved" way to change your mind about importing it. If you really need
> this functionality, it would be better to have an additional
> gss_release_exported_context() or gss_release_interprocess_token() call that
> would do whatever's necessary to release resources and erase any sensitive
> information in the token. That way, if the GSSAPI implementation does save
> context information elsewhere than in the token, then it can be scrubbed and
> released.
It would be very difficult to do something like releasing an exported
context. Where would it have to be done? In the process which did
the export? That's in general not possible for our application, so
we wouldn't even think about the 5% of case where it might be.
If it would be possible to "release" an exported context from any
process context, then it could be implemented, but we will still have
a considerable amount of leftovers.
-Martin
Received: from cnri by ietf.org id aa01209; 6 Mar 97 19:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21634;
6 Mar 97 19:41 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA26548 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 22:51:21 GMT
Date: Thu, 6 Mar 1997 14:51:07 -0800 (PST)
Message-Id: <199703062251.OAA19406 at tree2.Stanford.EDU>
From: schemers at stanford.edu
To: Marc Horowitz <marc at cygnus.com>
Cc: Theodre Ts'o <tytso at lurch.mit.edu>, wray at tuxedo.enet.dec.com,
cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
In-Reply-To: <t533eu8wy2e.fsf at rover.cygnus.com>
References: <199703061804.NAA18784 at lurch.mit.edu>
<t533eu8wy2e.fsf at rover.cygnus.com>
Precedence: bulk
Marc Horowitz writes:
> "Theodre Ts'o" <tytso at lurch.mit.edu> writes:
>
> >> The recovery process is easy; just free the flat exportable security
> >> context token that you were busy building. We have it in the krb5 code
> >> already; first you build the exportable flat context token, and only
> >> after you've successfully built it, do you free the gss context.
>
> This is fine for krb5, which can atomically export a context. As my
> previous messages have stated, I'm unconvinced that this is possible
> for all mechanisms.
>
What will be the typical failure mode for an application that
wants to export a context and can't? Is it really going to continue
on and do something else with the context, or is it going to delete it
and return an error? Answering that might help answer this question.
roland
Received: from ietf.org by ietf.org id ab01947; 6 Mar 97 20:19 EST
Received: from servo.qualcomm.com by ietf.org id aa01794; 6 Mar 97 20:13 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id RAA27320; Thu, 6 Mar 1997 17:10:31 -0800 (PST)
Date: Thu, 6 Mar 1997 17:10:31 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199703070110.RAA27320 at servo.qualcomm.com>
To: ietf at ietf.org
Subject: Memphis hotel situation
Source-Info: From (or Sender) name not authenticated.
Well, the Peabody, Holiday Inn Select and Holiday Inn Crowne Plaza are all
completely sold out for the week of the IETF. Anybody have any alternates?
The recurring IETF hotel situation is becoming completely
untenable. Aside from moving the IETF permanently to Las Vegas (if any
US city can handle a group our size, Vegas is it), does anyone have
any ideas to solve this problem?
Phil
Received: from cnri by ietf.org id aa03102; 6 Mar 97 20:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22258;
6 Mar 97 20:33 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA29621 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 00:04:57 GMT
Date: Thu, 6 Mar 1997 19:04:46 -0500 (EST)
From: der Mouse <mouse at rodents.montreal.qc.ca>
Message-Id: <199703070004.TAA17674 at Twig.Rodents.Montreal.QC.CA>
To: Marc Horowitz <marc at cygnus.com>, jis at mit.edu, linn at cam.ov.com,
cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
Precedence: bulk
>> [M]y point was not so much that CCC is or isn't useless, as that the
>> document seems to contradict itself, saying that CCC must be
>> integrity protected and then stating fairly directly that it is
>> possible to operate without implementing the command that would be
>> necessary to get that integrity protection.
> I can reword the text to say something like "... and not implement
> the protection commands in the general case." How's that?
That would be fine with me.
der Mouse
Received: from cnri by ietf.org id aa03462; 6 Mar 97 20:36 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22295;
6 Mar 97 20:36 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA26407 at pad-thai.cam.ov.com>; Thu, 6 Mar 1997 22:46:25 GMT
To: der Mouse <mouse at rodents.montreal.qc.ca>
Cc: jis at mit.edu, linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: draft-ietf-cat-ftpsec-09.txt
References: <199703062122.QAA17067 at Twig.Rodents.Montreal.QC.CA>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 17:45:31 -0500
In-Reply-To: der Mouse's message of Thu, 6 Mar 1997 16:22:59 -0500 (EST)
Message-Id: <t53vi74vdv8.fsf at rover.cygnus.com>
Lines: 23
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
der Mouse <mouse at Rodents.Montreal.QC.CA> writes:
>> >>> protected control channel messages. The CCC command itself must
>> >>> be integrity protected.
>> [...]
>> >>> A server may require that the first command after a successful
>> >>> security data exchange be CCC, and not implement the protection
>> >>> commands at all. In this case, the server should respond with a
>> >> How can the CCC command be integrity protected if the server doesn't
>> >> implement at least MIC?
>> > This command was requested by HP, who has implemented it.
>>
>> Yeah, I too can't quite see the point of CCC, but my point was not so
>> much that CCC is or isn't useless, as that the document seems to
>> contradict itself, saying that CCC must be integrity protected and then
>> stating fairly directly that it is possible to operate without
>> implementing the command that would be necessary to get that integrity
>> protection.
I can reword the text to say something like "... and not implement the
protection commands in the general case." How's that?
Marc
Received: from ietf.org by ietf.org id aa03560; 6 Mar 97 20:38 EST
Received: from works.ingrid.org by ietf.org id aa03513; 6 Mar 97 20:37 EST
Received: by works.ingrid.org (8.8.4/ingrid*mx2) with TCP; Fri, 7 Mar 1997 10:36:41 +0900 (JST)
Date: Fri, 7 Mar 1997 10:36:41 +0900 (JST)
Sender:ietf-request at ietf.org
From: Paul Francis <francis at works.ingrid.org>
Message-Id: <199703070136.KAA00352 at works.ingrid.org>
To: ietf at ietf.org, karn at qualcomm.com
Subject: Re: Memphis hotel situation
Source-Info: From (or Sender) name not authenticated.
>
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
>
I think having all meetings in las vegas is a great idea.
What better place to hammer out rough concensus than at
a roulette table?
PF
Received: from ietf.org by ietf.org id aa05094; 6 Mar 97 21:05 EST
Received: from rip.psg.com by ietf.org id aa05034; 6 Mar 97 21:04 EST
Received: by rip.psg.com
id m0w2oyU-0007zYC; Thu, 6 Mar 97 18:01 PST (Smail3.1.29.1#1)
Message-Id: <m0w2oyU-0007zYC at rip.psg.com>
Date: Thu, 6 Mar 97 18:01 PST
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Subject: Re: Memphis hotel situation
References: <199703070110.RAA27320 at servo.qualcomm.com>
Source-Info: From (or Sender) name not authenticated.
> The recurring IETF hotel situation is becoming completely
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
> any ideas to solve this problem?
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
would solve two problems with one hack.
randy
Received: from cnri by ietf.org id aa06979; 6 Mar 97 21:28 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22995;
6 Mar 97 21:28 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA29787 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 00:08:40 GMT
To: schemers at stanford.edu
Cc: Theodre Ts'o <tytso at lurch.mit.edu>, wray at tuxedo.enet.dec.com,
cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <199703061804.NAA18784 at lurch.mit.edu>
<t533eu8wy2e.fsf at rover.cygnus.com>
<199703062251.OAA19406 at tree2.Stanford.EDU>
From: Marc Horowitz <marc at cygnus.com>
Date: 06 Mar 1997 19:07:55 -0500
In-Reply-To: schemers at stanford.edu's message of Thu, 6 Mar 1997 14:51:07 -0800 (PST)
Message-Id: <t53pvxcva1w.fsf at rover.cygnus.com>
Lines: 15
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
schemers at stanford.edu writes:
>> What will be the typical failure mode for an application that
>> wants to export a context and can't? Is it really going to continue
>> on and do something else with the context, or is it going to delete it
>> and return an error? Answering that might help answer this question.
Chances are, you won't get that far, because you'll only link against
mechanisms which support the feature if you require it. Once we have
negotiation and some sort of pluggable mechanism support, then this
could happen; I would expect most applications to delete it and try
another available mechanism, but some might downgrade to a
single-process model and take the resulting performance hit.
Marc
Received: from cnri by ietf.org id aa07189; 6 Mar 97 21:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23146;
6 Mar 97 21:39 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA01725 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 00:37:31 GMT
Message-Id: <199703070036.AA22663 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: schemers at stanford.edu
Date: Fri, 7 Mar 1997 01:36:24 +0100 (MEZ)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703062251.OAA19406 at tree2.Stanford.EDU> from "schemers at stanford.edu" at Mar 6, 97 02:51:07 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
schemers at stanford.edu wrote:
> Marc Horowitz writes:
> > "Theodre Ts'o" <tytso at lurch.mit.edu> writes:
> >
> > >> The recovery process is easy; just free the flat exportable security
> > >> context token that you were busy building. We have it in the krb5 code
> > >> already; first you build the exportable flat context token, and only
> > >> after you've successfully built it, do you free the gss context.
> >
> > This is fine for krb5, which can atomically export a context. As my
> > previous messages have stated, I'm unconvinced that this is possible
> > for all mechanisms.
>
> What will be the typical failure mode for an application that
> wants to export a context and can't? Is it really going to continue
> on and do something else with the context, or is it going to delete it
> and return an error? Answering that might help answer this question.
A careful application might try to inquire_context() and write in its
logs who the affected client was and what the context looked like when
the context export failed ...
:)
-Martin
Received: from ietf.org by ietf.org id aa21265; 7 Mar 97 4:16 EST
Received: from ecrc.de by ietf.org id aa21005; 7 Mar 97 4:02 EST
Received: from scorpio.ecrc.de (scorpio.ecrc.de [141.1.4.100]) by ecrc.ecrc.de (8.8.3/8.8.3/$Revision: 1.2 $) with ESMTP id KAA16620; Fri, 7 Mar 1997 10:00:13 +0100 (MET)
Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125])
by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP
id JAA02037; Fri, 7 Mar 1997 09:57:47 +0100 (MET)
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Received: (from dave at localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id KAA01293; Fri, 7 Mar 1997 10:00:11 +0100 (MET)
Date: Fri, 7 Mar 1997 10:00:11 +0100 (MET)
Message-Id: <199703070900.KAA01293 at acrab25.ecrc.de>
To: karn at qualcomm.com, randy at psg.com
Subject: Re: Memphis hotel situation
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>> The recurring IETF hotel situation is becoming completely
>> untenable. Aside from moving the IETF permanently to Las Vegas (if any
>> US city can handle a group our size, Vegas is it), does anyone have
>> any ideas to solve this problem?
>
>Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
>would solve two problems with one hack.
>
>randy
Randy - next IETF is Munich - I think we have the hotel situation
under control for the Aug. meeting.
And now let me see where I can get a room for Memphis :-)
Dave
Received: from ietf.org by ietf.org id aa28252; 7 Mar 97 9:40 EST
Received: from ietf.ietf.org by ietf.org id aa28102; 7 Mar 97 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-02.txt
Date: Fri, 07 Mar 1997 09:37:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070938.aa28102 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (REL) Resource Record
in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-02.txt
Pages : 15
Date : 03/06/1997
This document describes the use of the Roaming Relationship (REL) record in
the DNS for the description of roaming relationships. In the absence of DNS
security, REL resource records may be used for determining the existence of
a roaming relationship path between the local ISP and the user's home
domain, as well as the location of an appropriate accounting agent.
However, without DNS security, hierarchical authentication routing must be
used in order to validate the roaming relationship path. When DNS security
is implemented, the roaming relationship path is authenticated via digital
signatures, and as a result, additional services may be provided, such as
non-repudiation of proxied authentications and signed receipts for
accounting record transfers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-dnsrr-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970306140919.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306140919.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28350; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28058; 7 Mar 97 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-murphy-ospf-signature-03.txt
Date: Fri, 07 Mar 1997 09:37:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070937.aa28058 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : OSPF with Digital Signatures
Author(s) : S. Murphy, M. Badger, B. Wellington
Filename : draft-murphy-ospf-signature-03.txt
Pages : 32
Date : 03/06/1997
This memo describes the extensions to OSPF required to add digital
signature authentication to Link State data, and to provide a certification
mechanism for router data. Added LSA processing and key management is
detailed. A method for migration from, or co-existence with, standard
OSPF V2 is described.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-murphy-ospf-signature-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-murphy-ospf-signature-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-murphy-ospf-signature-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970306104324.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-murphy-ospf-signature-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-murphy-ospf-signature-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306104324.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28356; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28101; 7 Mar 97 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-actng-01.txt
Date: Fri, 07 Mar 1997 09:38:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070938.aa28101 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Accounting Problem in Roaming
Author(s) : B. Aboba
Filename : draft-ietf-roamops-actng-01.txt
Pages : 22
Date : 03/06/1997
This document describes the accounting problems that arise in the provision
of inter-provider services, such as provision of dialup roaming
capabilities. These include issues relating to standardization of
accounting record formats, and inter-provider transfers of accounting
record bundles. Work relevant to the solution of these problems are
reviewed, and recommendations are made on the direction of future
standardization work.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-actng-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-actng-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-actng-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970306141529.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-actng-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-actng-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306141529.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28355; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28074; 7 Mar 97 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-atm2TC-06.txt
Date: Fri, 07 Mar 1997 09:37:55 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070937.aa28074 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Definitions of Textual Conventions and OBJECT-IDENTITIES
for ATM Management
Author(s) : M. Noto, E. Spiegel, K. Tesink
Filename : draft-ietf-atommib-atm2TC-06.txt
Pages : 20
Date : 03/06/1997
This memo describes Textual Conventions and OBJECT-IDENTITIES used for
managing ATM-based interfaces, devices, networks and services.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-atm2TC-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2TC-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-atm2TC-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970306135419.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atm2TC-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm2TC-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306135419.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28357; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28042; 7 Mar 97 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-stepanek-vipre-00.txt
Date: Fri, 07 Mar 1997 09:37:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070937.aa28042 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : VIPRE -- Virtual Internet Packet Relay
An Encapsulation Architecture for Unidirectional Links
Author(s) : J. Stepanek, S. Schwab
Filename : draft-stepanek-vipre-00.txt
Pages : 11
Date : 03/06/1997
This memo describes a method of incorporating unidirectional links into an
IP network in a bidirectional mode by relaying encapsulated IP packets over
a bidirectional network.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-stepanek-vipre-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-stepanek-vipre-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-stepanek-vipre-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970306101356.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-stepanek-vipre-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-stepanek-vipre-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306101356.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28358; 7 Mar 97 9:41 EST
Received: from ietf.ietf.org by ietf.org id aa28104; 7 Mar 97 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-nai-02.txt
Date: Fri, 07 Mar 1997 09:38:02 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703070938.aa28104 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Network Access Identifier
Author(s) : B. Aboba
Filename : draft-ietf-roamops-nai-02.txt
Pages : 5
Date : 03/06/1997
This document describes issues relating to user identification in provision
of "roaming capability" for dialup Internet users. "Roaming capability"
may be loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-provided corporate
network access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-nai-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-nai-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-nai-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970306141847.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-nai-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-nai-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970306141847.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28797; 7 Mar 97 9:47 EST
Received: from ietf.ietf.org by ietf.org id aa28759; 7 Mar 97 9:46 EST
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Best Current Practice for the Internet White Pages
Service to BCP
Reply-to: iesg at ietf.org
Date: Fri, 07 Mar 1997 09:46:53 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703070946.aa28759 at ietf.org>
The IESG has received a request from the Integrated Directory Services
Working Group to consider "Best Current Practice for the Internet White
Pages Service" <draft-ietf-ids-ds-bcp-02.txt> for the status of BCP.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 20, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa28924; 7 Mar 97 9:50 EST
Received: from mercury.Sun.COM by ietf.org id aa28861; 7 Mar 97 9:48 EST
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA21772 for <ietf at ietf.org>; Fri, 7 Mar 1997 06:44:36 -0800
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
id JAA00451; Fri, 7 Mar 1997 09:45:21 -0500
Received: from maple.East.Sun.COM by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA19011; Fri, 7 Mar 1997 09:45:23 -0500
Received: from maple by maple.East.Sun.COM (SMI-8.6/SMI-SVR4)
id JAA10197; Fri, 7 Mar 1997 09:44:33 -0500
Date: Fri, 7 Mar 1997 09:44:33 -0500 (EST)
Sender:ietf-request at ietf.org
From: Miriam Kadansky - SUN Microsystems <Miriam.Kadansky at east.sun.com>
Reply-To: Miriam Kadansky - SUN Microsystems <Miriam.Kadansky at east.sun.com>
Subject: Re: Memphis hotel situation
To: ietf at ietf.org
Message-ID: <libSDtMail.9703070944.21037.miriamk at maple/maple>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ssYz/0uCZ9SCST2MCPNjVQ==
X-Mailer: dtmail 1.1.0 CDE Version 1.1_48 SunOS 5.5.1 sun4m sparc
Source-Info: From (or Sender) name not authenticated.
How about putting more sessions out on the MBone? I know many folks
who are interested in only a few areas, and would be happy to stay
home and tune in to only those sessions.
I tried to do this once, but found it impossible because there was no
easy way to connect to the MBone from my site, and the Multicast Guide
was not published far enough in advance to figure out if my favorite
sessions were covered.
For those people who can't get on the MBone, what if some members in
major cities hosted MBone participation?
From: Randy Bush <randy at psg.com>
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Subject: Re: Memphis hotel situation
> The recurring IETF hotel situation is becoming completely
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
> any ideas to solve this problem?
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and
we
would solve two problems with one hack.
randy
Received: from ietf.org by ietf.org id aa28925; 7 Mar 97 9:50 EST
Received: from fnal.fnal.gov by ietf.org id aa28496; 7 Mar 97 9:43 EST
Received: from gungnir.fnal.gov ("port 36412"@gungnir.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IG7QWZ9R5A0007NN at FNAL.FNAL.GOV>;
Fri, 07 Mar 1997 08:40:46 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4)
id IAA06755; Fri, 07 Mar 1997 08:40:45 -0600
Date: Fri, 07 Mar 1997 08:40:45 -0600
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: Memphis hotel situation
In-reply-to: "06 Mar 1997 17:10:31 PST."
<"199703070110.RAA27320"@servo.qualcomm.com>
X-Orig-Sender: crawdad at gungnir.fnal.gov
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Message-id: <199703071440.IAA06755 at gungnir.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> Aside from moving the IETF permanently to Las Vegas ...
No! No!
Received: from ietf.org by ietf.org id aa05190; 7 Mar 97 10:58 EST
Received: from Cust21.Max9.Seattle.WA.MS.UU.NET by ietf.org id aa05063;
7 Mar 97 10:53 EST
Received: from localhost (aboba at localhost) by monitor.internaut.com (8.8.5/8.6.12) with SMTP id HAA08596; Fri, 7 Mar 1997 07:47:53 -0800 (PST)
Date: Fri, 7 Mar 1997 07:47:53 -0800 (PST)
Sender:ietf-request at ietf.org
From: Bernard Aboba <aboba at monitor.internaut.com>
To: Phil Karn <karn at qualcomm.com>
cc: ietf at ietf.org
Subject: Re: Memphis hotel situation
In-Reply-To: <199703070110.RAA27320 at servo.qualcomm.com>
Message-ID: <Pine.BSI.3.95.970307074447.8577C-100000 at monitor.internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
You might try the following:
Sleepin at Court Square
40 North Front St.
Memphis, Tennessee 38103
(901)522-9700
$70/night
Radisson Hotel
185 Union AVe.
Memphis, Tennessee 38103
(901)528-1800
(800)333-3333
Received: from ietf.org by ietf.org id aa06041; 7 Mar 97 11:10 EST
Received: from ietf.ietf.org by ietf.org id aa05978; 7 Mar 97 11:08 EST
To: IETF-Announce: ;
Subject: Encapsulation
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Date: Fri, 07 Mar 1997 11:08:56 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703071108.aa05978 at ietf.org>
The IESG is extending the last-call periods for the following:
o Generic Routing Encapsulation (GRE)
<RFC1701>
o Generic Routing Encapsulation over IPv4 networks
<RFC1702>
o Generic Packet Tunneling in IPv6 Specification
<draft-ietf-ipngwg-ipv6-tunnel-07.txt>
A number of people pointed out after the IESG announced that it
had received a request to consider Generic Routing Encapsulation (RFC
1701 and RFC 1702) for the status of IETF Proposed standards that this
request could cause some level of confusion since there are already a
number of existing RFCs which describe encapsulation schemes for IPv4
and an Internet-Draft which was recently also the subject of an IETF
last-call (draft-ietf-ipngwg-ipv6-tunnel-07.txt) that describes an
encapsulation scheme to be used with IPv6.
The comment period will run for another two weeks (March 21) in order
to get comments from the IETF community about the desirability of
minimizing any confusion over what encapsulation technology or
technologies that the IETF should recommend and under what situations.
Possibilities include:
o Having multiple encapsulating protocols and let the marketplace
decide on which technology to use in which cases
o Selecting a single IPv4 encapsulation technology and a single IPv6
encapsulation technology
In addition to advice on what direction the IETF should take the IESG
is also soliciting advice about the process we should follow (one time BOF,
short lived WG, etc.).
Finally, the IESG would like to answer a question that was asked in
more than one message. Cisco Systems has explicitly disavowed any
claims of IPR relating to the technology described in RFC1701 and
RFC1702.
Received: from ietf.org by ietf.org id aa06995; 7 Mar 97 11:25 EST
Received: from dell05.cnri.reston.va.us by ietf.org id aa06740;
7 Mar 97 11:23 EST
Message-Id: <2.2.32.19970307162047.006d5884 at ietf.org>
X-Sender: mbeaulie at ietf.org
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 07 Mar 1997 11:20:47 -0500
To: Bernard Aboba <aboba at monitor.internaut.com>,
Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: Marcia Beaulieu <mbeaulie at ietf.org>
Subject: Re: Memphis hotel situation
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
The Radisson Hotel is also full, I am finalizing arrangements
at a hotel that is about 5 blocks away but on the trolley line,
the trolley runs every 15 to 20 minutes and drops you off about
one block from the Peabody. I will send the specifics as soon as
I receive them.
Marcia
At 07:47 AM 3/7/97 -0800, Bernard Aboba wrote:
>You might try the following:
>
>Sleepin at Court Square
>40 North Front St.
>Memphis, Tennessee 38103
>(901)522-9700
>$70/night
>
>Radisson Hotel
>185 Union AVe.
>Memphis, Tennessee 38103
>(901)528-1800
>(800)333-3333
>
>
>
Received: from ietf.org by ietf.org id aa07695; 7 Mar 97 11:39 EST
Received: from dirty.research.bell-labs.com by ietf.org id aa07557;
7 Mar 97 11:38 EST
Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Fri Mar 7 11:35:13 EST 1997
Received: from sea.dnrc.bell-labs.com ([135.180.144.10]) by research; Fri Mar 7 11:32:55 EST 1997
Received: from sea (localhost [127.0.0.1]) by sea.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id LAA17873 for <ietf at ietf.org>; Fri, 7 Mar 1997 11:30:37 -0500 (EST)
X-Orig-Sender: hgs at dnrc.bell-labs.com
Message-ID: <332042AD.5128 at cs.columbia.edu>
Date: Fri, 07 Mar 1997 11:30:37 -0500
Sender:ietf-request at ietf.org
From: "Henning Schulzrinne (BL)" <hgs at cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.4 sun4m)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Memphis hotel/Mbone
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Unfortunately, the audio quality of the Mbone is too unpredictable (or,
in many places, predictably unusable) that you could replace travel.
Given the will, it would seem fairly easy to arrange standard
telephone-conferencing gear such as the PolyCom, with hookup to the
house audio system. I'd gladly pay long-distance by the minute to
actually understand what's being said (and maybe even contribute and be
understood). Video/wb for slides over Mbone works just fine. (By special
effort of the secretariat, this was done once in San Jose,
unfortunately, the audio setup wasn't the greatest).
Henning
Received: from cnri by ietf.org id aa10319; 7 Mar 97 12:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11899;
7 Mar 97 12:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA26432 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 14:53:17 GMT
Message-Id: <9703071448.AA12885 at us1rmc.bb.dec.com>
Date: Fri, 7 Mar 97 09:48:15 EST
From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>
To: dennis.glatting at plaintalk.bellevue.wa.us
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dennis.glatting at plaintalk.bellevue.wa.us
Subject: Re: Comments solicited re negotiated mechanism action
Precedence: bulk
Dennis writes:
>I vote for snego, as it stands, to advance to informational or
>experimental and another approach pursued. Perhaps too we
>should start on GSS-APIv3, not backward compatible with v1 and
>v2, and addresses GSS-APIv2's shortcomings, such as nego,
>configuration, thread safety, single sign-on, etc.
Why do you think GSSAPI V2 would be a poor base for a
GSSAPI that includes these features?
GSSAPI currently doesn't address configuration or single sign-on
(or sign-on at all, come to that), but I don't see anything in the
current specs that would make it awkward to add these features. I think
we really should start work on support for pluggable mechanisms - a GSS-SPI -
and this would probably include some configuration stuff (although I'm not
sure how much of configuration needs to be standardized, rather than left
platform-specific).
SNEGO or a protected version thereof would seem to work OK as methods
of adding negotiation, and since in many environments negotiation
isn't wanted I'm not convinced that it should be an integral part of
GSSAPI. The only issues I have with SNEGO are to do with the lack of
protection during the negotiation, not the way that it's bolted onto
GSSAPI. The textual description of the GSSAPI specs could perhaps be
more negotiation-friendly (for example, the routine description for
gss_init_sec_context() could explicitly say that the actual_mech
parameter doesn't have to be the same as the input mech_type parameter, and
use a negotiation mechanism mech_type as an example, where the eventual
actual_mech parameter would indicate the chosen mechanism, not the negotiation
mechanism). I can imagine all sorts of ways an application might want
to "tweak" the negotiation process, but I don't see why any of these couldn't
be added on via additional calls to annotate the credential prior to calling
gss_init_sec_context() - i.e. done as extensions, rather than incompatible
changes.
As far as I know, the V2 spec doesn't contain any intrinsic threading problems,
although specific implementations may not necessarily be thread-safe. What
threading issues do you have with the current specs? We ought to address them
in V2 - threads aren't "exotic" any more.
John
Received: from ietf.org by ietf.org id aa11725; 7 Mar 97 12:52 EST
Received: from dot.netrex.net by ietf.org id aa11543; 7 Mar 97 12:48 EST
Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id MAA21256; Fri, 7 Mar 1997 12:46:07 -0500 (EST)
Message-Id: <3.0.1.32.19970307124340.009fea00 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 07 Mar 1997 12:43:40 -0500
To: "Henning Schulzrinne (BL)" <hgs at cs.columbia.edu>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: Memphis hotel/Mbone
In-Reply-To: <332042AD.5128 at cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 11:30 AM 3/7/97 -0500, Henning Schulzrinne (BL) wrote:
>Video/wb for slides over Mbone works just fine. (By special
>effort of the secretariat, this was done once in San Jose,
>unfortunately, the audio setup wasn't the greatest).
As I recall, it was by special effort of one of our hosts, Xerox that
supplied the wg systems. Others did the back-end systems.
They were neat.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa12605; 7 Mar 97 13:10 EST
Received: from hq.barrnet.net by ietf.org id aa12501; 7 Mar 97 13:07 EST
Received: (from vaf at localhost) by hq.barrnet.net (8.7.5/HQ-Len-1.1) id KAA22726; Fri, 7 Mar 1997 10:05:24 -0800 (PST)
Date: Fri, 7 Mar 97 10:05:24 PST
Sender:ietf-request at ietf.org
From: Vince Fuller <vaf at wr.bbnplanet.com>
To: Randy Bush <randy at psg.com>
Cc: Phil Karn <karn at qualcomm.com>, ietf at ietf.org
Phone: (415) 528-7227
USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: Memphis hotel situation
In-Reply-To: Your message of Thu, 6 Mar 97 18:01 PST
Message-ID: <CMM.0.90.2.857757924.vaf at hq.barrnet.net>
Source-Info: From (or Sender) name not authenticated.
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
would solve two problems with one hack.
Well, if there is ever a plan to have another IETF in Northern California,
I'd suggest, mostly-seriously, South Lake Tahoe. There are thousands of
hotel rooms because of the casinos, it's far enough away from Silicon Valley
to reduce the "drop-in random factor", it's within an hour of an airport
(Reno, albeit not the best-connected), and if you schedule it away from the
peak ski season the "boondoggle factor" and crowds aren't too bad. Much nicer
than Vegas with some of the benefits (i.e. large hotels).
Following Interop's lead, perhaps Atlanta in an east-coast choice - lots
of hotels, conference facilities, and a big airport. Schedule it in July or
August and the humidity will keep the crowds away...
--Vince
Received: from cnri by ietf.org id aa15237; 7 Mar 97 14:12 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14234;
7 Mar 97 14:12 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA03501 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 17:38:10 GMT
Message-Id: <199703071737.MAA04437 at gza-client1.cam.ov.com>
To: wray at tuxedo.enet.dec.com
Cc: cat-ietf at mit.edu
Subject: Re: Comments solicited re negotiated mechanism action
Date: Fri, 07 Mar 1997 12:37:53 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
John writes, excerpting:
>The textual description of the GSSAPI specs could perhaps be
>more negotiation-friendly (for example, the routine description for
>gss_init_sec_context() could explicitly say that the actual_mech
>parameter doesn't have to be the same as the input mech_type
>parameter, and use a negotiation mechanism mech_type as an example,
>where the eventual actual_mech parameter would indicate the chosen
>mechanism, not the negotiation mechanism).
I thought that RFC-2078 explicitly covered this; I checked and it
does. On page 39 (deep into the discussion of
GSS_Init_sec_context()), is the following text:
> The returned mech_type value indicates the specific mechanism
> employed on the context, is valid only along with major_status
> GSS_S_COMPLETE, and will never indicate the value for "default".
> Note that, for the case of certain mechanisms which themselves
> perform negotiation, the returned mech_type result may indicate
> selection of a mechanism identified by an OID different than that
> passed in the input mech_type argument.
--jl
Received: from ietf.org by ietf.org id aa16166; 7 Mar 97 14:50 EST
Received: from core.IConNet.NET by ietf.org id aa15405; 7 Mar 97 14:20 EST
Received: from localhost (brisco at localhost)
by fs.IConNet.NET (8.8.5/8.8.5) with SMTP id OAA07819;
Fri, 7 Mar 1997 14:18:19 -0500 (EST)
Date: Fri, 7 Mar 1997 14:18:18 -0500 (EST)
Sender:ietf-request at ietf.org
From: "T.P.Brisco" <brisco at iconnet.net>
To: "Henning Schulzrinne (BL)" <hgs at cs.columbia.edu>
cc: ietf at ietf.org
Subject: Re: Memphis hotel/Mbone
In-Reply-To: <332042AD.5128 at cs.columbia.edu>
Message-ID: <Pine.GSO.3.92.970307141145.7333A-100000 at fs.IConNet.NET>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
One of the groups that I do work with a lot has resorted to using
a "broadcast" 800 number. The 800 number (from the committee's
perspective) is "outgoing only" (i.e. I can't talk back) - I can patch
in/out at my leasure - and get all the quality that my telephone will
bring me :-)
Has the group considered a (cheap) 900 number in such an
arrangement?
Tp
On Fri, 7 Mar 1997, Henning Schulzrinne (BL) wrote:
> Unfortunately, the audio quality of the Mbone is too unpredictable (or,
> in many places, predictably unusable) that you could replace travel.
> Given the will, it would seem fairly easy to arrange standard
> telephone-conferencing gear such as the PolyCom, with hookup to the
> house audio system. I'd gladly pay long-distance by the minute to
> actually understand what's being said (and maybe even contribute and be
> understood). Video/wb for slides over Mbone works just fine. (By special
> effort of the secretariat, this was done once in San Jose,
> unfortunately, the audio setup wasn't the greatest).
>
> Henning
>
Received: from cnri by ietf.org id aa16302; 7 Mar 97 14:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15150;
7 Mar 97 14:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA05210 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 18:22:15 GMT
Date: Fri, 7 Mar 1997 13:19:34 -0500
Message-Id: <9703071819.AA08475 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: schemers at stanford.edu
Cc: Marc Horowitz <marc at cygnus.com>, Theodre Ts'o <tytso at lurch.mit.edu>,
wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: schemers at stanford.edu's message of Thu, 6 Mar 1997 14:51:07 -0800
(PST), <199703062251.OAA19406 at tree2.Stanford.EDU>
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Thu, 6 Mar 1997 14:51:07 -0800 (PST)
From: schemers at stanford.edu
What will be the typical failure mode for an application that
wants to export a context and can't? Is it really going to continue
on and do something else with the context, or is it going to delete it
and return an error? Answering that might help answer this question.
Assuming that the application links (I think an implementation has to
supply export_context even if it's not supported, although there may be
some disagreement on this issue), I'd assume that likely failure modes
would be things like memory allocation failures.
- Ted
Received: from cnri by ietf.org id aa17056; 7 Mar 97 15:17 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15621;
7 Mar 97 15:17 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA02327 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 17:08:25 GMT
Message-Id: <199703071708.JAA10781 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Fri, 7 Mar 97 09:08:05 -0800
To: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu
Subject: Re: Comments solicited re negotiated mechanism action
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <9703071448.AA12885 at us1rmc.bb.dec.com>
Precedence: bulk
> From: Dennis Glatting <dennisg>
> Date: Fri, 7 Mar 97 08:49:44 -0800
>
> > From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997
> > 0911" <wray at tuxedo.ENET.dec.com>
> > Date: Fri, 7 Mar 97 09:48:15 EST
> >
> > Dennis writes:
> >
> [ snip ]
>
> My thoughts regarding configuration are: the default mech;
> preference mech order for nego; preference QOP order and
> restricted QOP usage per mech; advertised mech set for nego vs
> available mech set; restricte name type per mech; preferred
> name type per mech and across the mech set; mech preferences
> such as replay detection; then underlying mech specific
> options such as "Kerberos: use a memory based replay cache".
>
Asa an aside, I believe it would be beneficial to the community
if the Kerberos configuration syntax were standardized too.
-dpg
Received: from cnri by ietf.org id aa18199; 7 Mar 97 15:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16523;
7 Mar 97 15:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA05453 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 18:26:11 GMT
Date: Fri, 7 Mar 1997 13:26:06 -0500
Message-Id: <9703071826.AA08487 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John Wray, Digital DPE, 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
In-Reply-To: John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911's message
of Fri, 7 Mar 97 09:48:15 EST, <9703071448.AA12885 at us1rmc.bb.dec.com>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Fri, 7 Mar 97 09:48:15 EST
From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.ENET.dec.com>
As far as I know, the V2 spec doesn't contain any intrinsic threading
problems, although specific implementations may not necessarily be
thread-safe. What threading issues do you have with the current
specs? We ought to address them in V2 - threads aren't "exotic" any
more.
The main complaints which I've heard is that GSSAPI doesn't have a
"startup" and "shutdown" function, and that it doesn't have a library
context variable which is passed into each function. This means that if
the library needs to keep any state that needs to be accessed by
functions which don't take a security context, the state has to be
stored in a static variable. For some restricted OS's emanating from
Redmond, WA, this can cause some problems, although generally there are
ways of working around them.
The other approach of fixing threading would be to add functions which
allow an application to register and deregister locking primitives to
work with an arbitrary threading infrastructure. (Alternatively, you
could make the implementation work with one and exactly thread library
without making any changes to the API; this requires that all
applications using that particular GSSAPI mechanism would have to use
that thread library.)
None of these approaches is particularly fun nor simple, but then again,
neither is threading. :-/
- Ted
Received: from cnri by ietf.org id aa18475; 7 Mar 97 16:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16831;
7 Mar 97 16:09 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA01534 at pad-thai.cam.ov.com>; Fri, 7 Mar 1997 16:50:11 GMT
Message-Id: <199703071649.IAA10762 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Fri, 7 Mar 97 08:49:44 -0800
To: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997 0911" <wray at tuxedo.enet.dec.com>
Subject: Re: Comments solicited re negotiated mechanism action
Cc: cat-ietf at mit.edu
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <9703071448.AA12885 at us1rmc.bb.dec.com>
Precedence: bulk
> From: "John Wray, Digital DPE, (508) 486-5210 07-Mar-1997
> 0911" <wray at tuxedo.ENET.dec.com>
> Date: Fri, 7 Mar 97 09:48:15 EST
>
> Dennis writes:
>
> >I vote for snego, as it stands, to advance to informational or
> >experimental and another approach pursued. Perhaps too we
> >should start on GSS-APIv3, not backward compatible with v1 and
> >v2, and addresses GSS-APIv2's shortcomings, such as nego,
> >configuration, thread safety, single sign-on, etc.
>
> Why do you think GSSAPI V2 would be a poor base for a
> GSSAPI that includes these features?
>
I didn't mean to imply it wasn't. I mean v3 need not resemble v2
and nothing in v2 should be considered sacred.
> GSSAPI currently doesn't address configuration or single
> sign-on (or sign-on at all, come to that), but I don't see
> anything in the current specs that would make it awkward to add
> these features. I think we really should start work on support
> for pluggable mechanisms - a GSS-SPI - and this would probably
> include some configuration stuff (although I'm not sure how
> much of configuration needs to be standardized, rather than
> left platform-specific).
>
My thoughts regarding configuration are: the default mech;
preference mech order for nego; preference QOP order and
restricted QOP usage per mech; advertised mech set for nego vs
available mech set; restricte name type per mech; preferred
name type per mech and across the mech set; mech preferences
such as replay detection; then underlying mech specific
options such as "Kerberos: use a memory based replay cache".
[snip ]
> As far as I know, the V2 spec doesn't contain any intrinsic
> threading problems, although specific implementations may
> not necessarily be thread-safe. What threading issues do you
> have with the current specs? We ought to address them in V2 -
> threads aren't "exotic" any more.
>
An environment context passed to each function. An underlying
mech, for example, could store a per-thread pRNG state within
the context. GSS-API and mechanisms could store
traditionally static data, such as the default Kerberos
realm, within the context too.
-dpg
Received: from ietf.org by ietf.org id aa19971; 7 Mar 97 16:53 EST
Received: from hail.ncr.disa.mil by ietf.org id aa19803; 7 Mar 97 16:48 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA14590; Fri, 7 Mar 1997 16:43:36 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857781712; Fri, 07 Mar 97 16:28:43 EST
Date: Fri, 07 Mar 97 16:28:43 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9702078577.AA857781712 at ncr.disa.mil>
To: Vince Fuller <vaf at wr.bbnplanet.com>
Cc: ietf at ietf.org
Subject: Drop-In Random Factor (Was: Re[2]: Memphis hotel situation)
Source-Info: From (or Sender) name not authenticated.
Vince,
If you hold all meetings in, say, Europe (and outside the US), you
can really keep the "drop-in random factor" low. Munich is beautiful;
so is Rome, Venice, Paris, Stockholm, etc. I personally prefer the
Caribbean, especially Saba (in the East) and the Caiman Islands (in
the West). And in the future there will be Mars and the moons of
Jupiter.
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: Memphis hotel situation
Author: Vince Fuller <vaf at wr.bbnplanet.com> at smtp
Date: 3/7/97 10:05 AM
Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
would solve two problems with one hack.
Well, if there is ever a plan to have another IETF in Northern California,
I'd suggest, mostly-seriously, South Lake Tahoe. There are thousands of
hotel rooms because of the casinos, it's far enough away from Silicon Valley
to reduce the "", it's within an hour of an airport
(Reno, albeit not the best-connected), and if you schedule it away from the
peak ski season the "boondoggle factor" and crowds aren't too bad. Much nicer
than Vegas with some of the benefits (i.e. large hotels).
Following Interop's lead, perhaps Atlanta in an east-coast choice - lots
of hotels, conference facilities, and a big airport. Schedule it in July or
August and the humidity will keep the crowds away...
--Vince
Received: from ietf.org by ietf.org id aa20121; 7 Mar 97 16:55 EST
Received: from hail.ncr.disa.mil by ietf.org id aa20029; 7 Mar 97 16:55 EST
Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA14914; Fri, 7 Mar 1997 16:50:45 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA857782316; Fri, 07 Mar 97 16:50:20 EST
Date: Fri, 07 Mar 97 16:50:20 EST
Sender:ietf-request at ietf.org
From: Bill Flanigan <flanigab at ncr.disa.mil>
Message-Id: <9702078577.AA857782316 at ncr.disa.mil>
To: Marcia Beaulieu <mbeaulie at ietf.org>
Cc: ietf at ietf.org
Return-Receipt-To: flanigab at ncr.disa.mil
Subject: Re[2]: Memphis hotel situation
Source-Info: From (or Sender) name not authenticated.
Hello Marcia,
Here's part of an email I sent out to the list on 27 Feb that might
help.
-------------
1. Recommend you get the AAA Tour Book for Tennessee--it list
and rates about forty in "Greater "Memphis."
2. List for downtown (all have 901 area code):
a. Best Western (two diamonds) 948-9005;
b. Comfort Inn (three) 526-0583;
c. Days Inn (two) 527-4100;
d. Holiday Inn (three) 527-7300;
e. Another Holiday Inn (three) 525-5491; and
f. Radison (three) 528-1800.
3. Rack rates for the above range from $50 to $109 before AAA
(or other) discounts.
-------------
Bill Flanigan
______________________________ Reply Separator _________________________________
Subject: Re: Memphis hotel situation
Author: Marcia Beaulieu <mbeaulie at ietf.org> at smtp
Date: 3/7/97 11:27 AM
The Radisson Hotel is also full, I am finalizing arrangements
at a hotel that is about 5 blocks away but on the trolley line,
the trolley runs every 15 to 20 minutes and drops you off about
one block from the Peabody. I will send the specifics as soon as
I receive them.
Marcia
Received: from ietf.org by ietf.org id aa21653; 7 Mar 97 17:15 EST
Received: from hq.barrnet.net by ietf.org id aa21565; 7 Mar 97 17:13 EST
Received: (from vaf at localhost) by hq.barrnet.net (8.7.5/HQ-Len-1.1) id OAA27309; Fri, 7 Mar 1997 14:11:03 -0800 (PST)
Date: Fri, 7 Mar 97 14:11:03 PST
Sender:ietf-request at ietf.org
From: Vince Fuller <vaf at wr.bbnplanet.com>
To: Bill Flanigan <flanigab at ncr.disa.mil>
Cc: ietf at ietf.org
Phone: (415) 528-7227
USMail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: Drop-In Random Factor (Was: Re[2]: Memphis hotel situation)
In-Reply-To: Your message of Fri, 07 Mar 97 16:28:43 EST
Message-ID: <CMM.0.90.2.857772663.vaf at hq.barrnet.net>
Source-Info: From (or Sender) name not authenticated.
If you hold all meetings in, say, Europe (and outside the US), you
can really keep the "drop-in random factor" low. Munich is beautiful;
so is Rome, Venice, Paris, Stockholm, etc. I personally prefer the
Caribbean, especially Saba (in the East) and the Caiman Islands (in
the West). And in the future there will be Mars and the moons of
Jupiter.
I'm not sure if I should interpret this note as sarcastic or serious, so I
will risk taking some bait and answer it. Randy's note addressed the same
issue: holding the IETF in off-the-beaten-path locations would certainly
cut down on over-crowding. But there has to be some balance - I'm a big
fan of Grand Cayman, too (been there twice, diving was awesome, would love
to go again, especially on someone else's dime), but I suspect that my, and
others' management would look askance at having meetings in such nice,
expensive locations.
I tossed South Lake Tahoe into the ring because it is the sort of place that
has some characteristics that would be good in a IETF location:
- not a hideous place to be
- not too far from a major airport
- lots of hotel space at a range of prices
- close, but not too close, to high density of Internet geeks
The last of these is significant - the 3-4 hour drive from the Bay Area is
close enough to be practical for those who are seious about participation
but is also far enough to discourage random drop-ins. San Francisco/San Jose,
Boston, and DC are three examples of places which fail this last test - it
is just too easy and too inviting for non-participant spectators to show up
if the IETF is held in such a place.
--Vince
Received: from ietf.org by ietf.org id aa22279; 7 Mar 97 17:22 EST
Received: from cnri by ietf.org id aa22229; 7 Mar 97 17:21 EST
Received: from [208.1.117.130] by CNRI.Reston.VA.US id aa18269;
7 Mar 97 17:21 EST
Received: from legacy.lgcy.com ([207.14.219.48]) by alberta.sallynet.com (8.8.3/8.7.3) with SMTP id LAA03936; Fri, 7 Mar 1997 11:57:41 -0500 (EST)
Date: Fri, 7 Mar 1997 11:57:41 -0500 (EST)
Message-Id: <199703071657.LAA03936 at alberta.sallynet.com>
Comments: Authenticated sender is <mc at mail.scottallen.com>
Sender:ietf-request at ietf.org
From: "." <williams at lgcy.com>
To: you at alberta.sallynet.com
Subject: All Aboard!!
X-mailer: Floodgate Pro 5.0
Source-Info: From (or Sender) name not authenticated.
Four days and nights aboard a private yacht in the caribean
for $262.50???? includes meals and diving!!! Check us out at
http://www.lgcy.com/williams/caribean-cruise.html or E-mail williams at lgcy.com
Received: from cnri by ietf.org id aa10152; 8 Mar 97 2:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02656;
8 Mar 97 2:34 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <GAA29652 at pad-thai.cam.ov.com>; Sat, 8 Mar 1997 06:25:32 GMT
Date: Sat, 8 Mar 1997 01:22:56 -0500 (EST)
From: Rich Salz <rsalz at osf.org>
Message-Id: <199703080622.BAA28241 at sulphur.osf.org>
To: tytso at mit.edu, wray at tuxedo.enet.dec.com
Subject: Re: Comments solicited re negotiated mechanism action
Cc: cat-ietf at mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
>context variable which is passed into each function. This means that if
>the library needs to keep any state that needs to be accessed by
>functions which don't take a security context, the state has to be
>stored in a static variable. For some restricted OS's emanating from
>Redmond, WA, this can cause some problems, although generally there are
>ways of working around them.
Why isn't thread-local-storage/thread-specific-data acceptable?
Yes, it would probably bind a particular GSSAPI implementation to
a particular threads package, but I don't see that as onerous:
How many OS's, where you wouldn't have GSSAPI source available to
port, support more than one threads library?
As for "Redmond" are you talking about the problems with Windows
DLL's and static data, or something else? (There's really no need
to be oblique, is there?)
/r$
Received: from cnri by ietf.org id aa21150; 8 Mar 97 15:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11452;
8 Mar 97 15:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA21461 at pad-thai.cam.ov.com>; Sat, 8 Mar 1997 18:51:11 GMT
Message-Id: <m0w3RCG-0000fMC at ermail02.btx.dtag.de>
Date: Sat, 8 Mar 97 19:49 +0100
From: Scherer Annette <Annette.Scherer at t-online.de>
X-Sender: 0957172051-0001 at t-online.de (Annette Scherer)
Subject: GSS-API
To: cat-ietf at mit.edu
Precedence: bulk
Dear Ladies and Gentlemen,
I have to write a paper about WWW-security. One chapter will refer to GSS-API.
Is there any paper which gives a good overview about the GSS-API but is shorter
then the RFC or draft?
Especially I have following questions:
How does it work
Which interfaces does it provide
How can I couple it with applications and protocols
With which protocols does it work
Which advantages does it provide
What are the diffrences between RFC and draft
Thank you for your answers
Annette Scherer
Fernuniversitaet Hagen
annette.scherer at t-online.de
Received: from ietf.org by ietf.org id aa15573; 9 Mar 97 17:51 EST
Received: from THOR.INNOSOFT.COM by ietf.org id aa15211; 9 Mar 97 17:32 EST
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694)
id <01IG95SCDKG08WVYSE at INNOSOFT.COM> for ietf at ietf.org; Sun,
9 Mar 1997 14:29:04 PST
Date: Sun, 09 Mar 1997 14:03:02 -0800 (PST)
Sender:ietf-request at ietf.org
From: Ned Freed <Ned.Freed at innosoft.com>
Subject: Re: Memphis hotel situation
In-reply-to: "Your message dated Thu, 06 Mar 1997 17:10:31 -0800 (PST)"
<199703070110.RAA27320 at servo.qualcomm.com>
To: Phil Karn <karn at qualcomm.com>
Cc: ietf at ietf.org
Message-id: <01IGAVNIF5CG8WVYSE at INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> Well, the Peabody, Holiday Inn Select and Holiday Inn Crowne Plaza are all
> completely sold out for the week of the IETF. Anybody have any alternates?
> The recurring IETF hotel situation is becoming completely
> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> US city can handle a group our size, Vegas is it), does anyone have
> any ideas to solve this problem?
Actually lots of facilities can handle a group as small as the IETF still is.
I've attended conferences with attendance double or even quadruple that of the
IETF and with networking needs comparable to those of the IETF in Atlanta,
Anaheim, New Orleans, Cincinnati, to name but four in the US alone, and found
all of them to be quite reasonable. And more to the point, none of them have
suffered from the problems the IETF meetings now seem to encounter with a fair
amount of regularity.
Frankly, the IETF isn't all that large, nor are its needs all that special, in
this day and age. The only real issues here are planning for the numbers we all
know have to be accomodated plus having the experience, contacts, and expertise
to arrange it all. And much as I admire the hard work that has been done
to bring off past IETFs, I do agree that there's a serious problem here in
need of fixing.
Ned
Received: from ietf.org by ietf.org id aa17600; 9 Mar 97 18:39 EST
Received: from mailhost.ipsilon.com by ietf.org id aa17035; 9 Mar 97 18:37 EST
Received: from red.ipsilon.com (red.Ipsilon.COM [205.226.1.58]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id PAA20591; Sun, 9 Mar 1997 15:34:34 -0800
Received: from red.ipsilon.com by red.ipsilon.com (8.6.12) id PAA05643; Sun, 9 Mar 1997 15:34:38 -0800
Message-Id: <199703092334.PAA05643 at red.ipsilon.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Ned Freed <Ned.Freed at innosoft.com>
cc: Phil Karn <karn at qualcomm.com>, ietf at ietf.org
Subject: Re: Memphis hotel situation
In-reply-to: Your message of "Sun, 09 Mar 1997 14:03:02 PST."
<01IGAVNIF5CG8WVYSE at INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 09 Mar 1997 15:34:37 -0800
Sender:ietf-request at ietf.org
From: Greg Minshall <minshall at ipsilon.com>
Source-Info: From (or Sender) name not authenticated.
Ned, et al,
> The only real issues here are planning for the numbers we all
> know have to be accomodated plus having the experience, contacts, and expertise
> to arrange it all. And much as I admire the hard work that has been done
> to bring off past IETFs, I do agree that there's a serious problem here in
> need of fixing.
In fairness to the secretariat, which does the job of scheduling things (as i
understand the situation), it is probably the case that most other groups have
more predictable numbers of attendees and aren't experiencing the exponential
(well...) growth that the IETF is.
As i understand things, arrangements are made a few years in advance.
This isn't to say there isn't a problem (there is). And it isn't to say that
the secretariat is, in fact, doing everything possible to deal with the
problem (i have no knowledge on that one way or the other). It's just to say
that this growth thing hits us in lots of ways, one of which is that
"experience, contacts, and expertise" with a stable sized meeting may not be
enough!
Greg
Received: from cnri by ietf.org id aa01791; 10 Mar 97 3:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03575;
10 Mar 97 3:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA29070 at pad-thai.cam.ov.com>; Mon, 10 Mar 1997 07:31:18 GMT
Message-Id: <3323B8B8.658B at math.ethz.ch>
Date: Mon, 10 Mar 1997 08:31:04 +0100
From: Carlos De Sousa <desousa at math.ethz.ch>
Organization: ETH - Zuerich, Switzerland
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
unsubscribe
Thank you
Received: from ietf.org by ietf.org id aa06735; 10 Mar 97 9:50 EST
Received: from bugs_bunny.columbia.sparta.com by ietf.org id aa06507;
10 Mar 97 9:42 EST
Received: from katahdin.columbia.sparta.com by columbia.sparta.com (4.1/cfm-7-21-95)
id AA02492; Mon, 10 Mar 97 09:39:28 EST
Received: by katahdin.columbia.sparta.com (5.61/SMI-4.1)
id AA04923; Mon, 10 Mar 97 09:39:26 -0500
Sender:ietf-request at ietf.org
From: Howard Weiss <hsw at columbia.sparta.com>
Message-Id: <9703101439.AA04923 at katahdin.columbia.sparta.com>
Subject: Re: Memphis hotel situation
To: Ned Freed <Ned.Freed at innosoft.com>
Date: Mon, 10 Mar 1997 09:39:25 -0500 (EST)
Cc: karn at qualcomm.com, ietf at ietf.org
In-Reply-To: <01IGAVNIF5CG8WVYSE at INNOSOFT.COM> from "Ned Freed" at Mar 9, 97 02:03:02 pm
Organization: SPARTA Inc. (Secure Systems Engineering Division)
Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046
Phone: (410) 381-9400 x201
Fax: (410) 381-5559
X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2378
Source-Info: From (or Sender) name not authenticated.
>
> > Well, the Peabody, Holiday Inn Select and Holiday Inn Crowne Plaza are all
> > completely sold out for the week of the IETF. Anybody have any alternates?
>
> > The recurring IETF hotel situation is becoming completely
> > untenable. Aside from moving the IETF permanently to Las Vegas (if any
> > US city can handle a group our size, Vegas is it), does anyone have
> > any ideas to solve this problem?
>
> Actually lots of facilities can handle a group as small as the IETF still is.
> I've attended conferences with attendance double or even quadruple that of the
> IETF and with networking needs comparable to those of the IETF in Atlanta,
> Anaheim, New Orleans, Cincinnati, to name but four in the US alone, and found
> all of them to be quite reasonable. And more to the point, none of them have
> suffered from the problems the IETF meetings now seem to encounter with a fair
> amount of regularity.
>
> Frankly, the IETF isn't all that large, nor are its needs all that special, in
> this day and age. The only real issues here are planning for the numbers we all
> know have to be accomodated plus having the experience, contacts, and expertise
> to arrange it all. And much as I admire the hard work that has been done
> to bring off past IETFs, I do agree that there's a serious problem here in
> need of fixing.
>
> Ned
>
Indeed, the National Information Systems Security Conference (NISSC)
(formally, the National Computer Security Conference) has had
approximately 2000 attendees for years. Its held at the Baltimore
Convention Center every October and over 600 hotel rooms in downtown
Baltimore and near the Baltimore-Washington International (BWI)
Airport are held in reserve. Certainly, there are lots of "drop-in"
attendees from the Baltimore-Washington corrider, but nevertheless,
this is no different from the San Jose venue for the IETF.
Howie
--
___________________________________________________________________
| |
|Howard Weiss phone (410) 381-9400 x201 |
|SPARTA, Inc. (301) 621-8145 x201 (DC)|
|9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 |
|Columbia, MD 21046 email: hsw at columbia.sparta.com|
|___________________________________________________________________|
Received: from ietf.org by ietf.org id aa07408; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06904; 10 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-madman-dsa-mib-1-03.txt
Date: Mon, 10 Mar 1997 09:52:58 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100952.aa06904 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : LDAP/CLDAP/X.500 Directory Services Monitoring MIB
Author(s) : G. Mansfield, S. Kille
Filename : draft-ietf-madman-dsa-mib-1-03.txt
Pages : 21
Date : 03/07/1997
This document defines a portion of the Management Information
Base (MIB). It defines the MIB for monitoring Directory Services.
This MIB will be used in conjunction with the APPLICATION-MIB
for monitoring Directory Servers (DS)s.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-madman-dsa-mib-1-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-dsa-mib-1-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970307100815.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-dsa-mib-1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307100815.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07405; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa07025; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ediint at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ediint-as1-03.txt
Date: Mon, 10 Mar 1997 09:53:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa07025 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Electronic Data
Interchange-Internet Integration Working Group of the IETF.
Title : MIME-based Secure EDI
Author(s) : M. Jansson, C. Shih, R. Drummond
Filename : draft-ietf-ediint-as1-03.txt
Pages : 17
Date : 03/07/1997
This document describes how to securely exchange EDI documents using MIME
and public key cryptography.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ediint-as1-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-as1-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ediint-as1-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310094454.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ediint-as1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ediint-as1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310094454.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07413; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06924; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-cbt-spec-07.txt
Date: Mon, 10 Mar 1997 09:53:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa06924 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Core Based Trees (CBT) Multicast
-- Protocol Specification --
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-spec-07.txt
Pages : 27
Date : 03/07/1997
This document describes the Core Based Tree (CBT) network layer multicast
routing protocol. CBT builds a shared multicast distribution tree per
group, and is suited to inter- and intra-domain multicast routing.
CBT is protocol independent in that it makes use of unicast routing to
establish paths between senders and receivers. The CBT architecture is
described in [1].
This document is progressing through the IDMR working group of the IETF.
CBT related documents include [1, 5, 6]. For all IDMR-related documents,
see http://www.cs.ucl.ac.uk/ietf/idmr.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-cbt-spec-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-spec-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-cbt-spec-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970307104720.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-spec-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-spec-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307104720.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07403; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06887; 10 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ripv2-md5-auth-00.txt
Date: Mon, 10 Mar 1997 09:52:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100952.aa06887 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the RIP Version II Working Group
of the IETF.
Title : RIP-II MD5 Authentication
Author(s) : F. Baker
Filename : draft-ietf-ripv2-md5-auth-00.txt
Pages : 14
Date : 03/07/1997
Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIP-II provides for unauthenticated
service (as in classical RIP), or password authentication. Both are
vulnerable to passive attacks currently widespread in the Internet.
Well-understood security issues exist in routing protocols [4]. Clear text
passwords, currently specified for use with RIP-II, are no longer
considered sufficient [5].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ripv2-md5-auth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ripv2-md5-auth-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ripv2-md5-auth-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970307095329.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-md5-auth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-md5-auth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307095329.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07411; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06989; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-cbt-dvmrp-00.txt
Date: Mon, 10 Mar 1997 09:53:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa06989 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Core Based Tree (CBT) Multicast Border Router
Specification for Connecting a CBT Stub Region to a
DVMRP Backbone
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-dvmrp-00.txt
Pages : 9
Date : 03/07/1997
This document specifies the behaviour of CBT multicast border router
interconnecting a CBT multicast stub domain (region) to a DVMRP [1]
multicast backbone.
The document provides guidelines that are intended to be generally aligned
with the mechanisms described in the "Interoperability Rules for Multicast
Routing Protocols" [2]. Certain aspects of those rules may be interpreted
and implemented differently, and therefore some discretion is left to the
implementor.
This document assumes the reader is familiar with the CBT protocol [3].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-cbt-dvmrp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dvmrp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-cbt-dvmrp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970307121600.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-dvmrp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-dvmrp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307121600.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07412; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa06941; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-cbt-arch-04.txt
Date: Mon, 10 Mar 1997 09:53:17 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa06941 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Core Based Trees (CBT) Multicast Routing Architecture
Author(s) : A. Ballardie
Filename : draft-ietf-idmr-cbt-arch-04.txt
Pages : 24
Date : 03/07/1997
CBT is a multicast routing architecture that builds a single delivery tree
per group which is shared by all of the group's senders and receivers.
Most multicast algorithms build one multicast tree per sender (subnetwork),
the tree being rooted at the sender's subnetwork. The primary advantage of
the shared tree approach is that it typically offers more favourable
scaling characteristics than all other multicast algorithms.
The CBT protocol [1] is a network layer multicast routing protocol that builds
and maintains a shared delivery tree for a multicast group. The sending
and receiving of multicast data by hosts on a subnetwork conforms to the
traditional IP multicast service model [2].
CBT is progressing through the IDMR working group of the IETF.
The CBT protocol is described in an accompanying document [1].
For this, and all IDMR-related documents, see
http://www.cs.ucl.ac.uk/ietf/idmr
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-cbt-arch-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-arch-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-cbt-arch-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970307112116.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-cbt-arch-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-cbt-arch-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307112116.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07406; 10 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa07051; 10 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-tls at w3.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-tls-protocol-01.txt
Date: Mon, 10 Mar 1997 09:53:41 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703100953.aa07051 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Transport Layer Security
Working Group of the IETF.
Title : The TLS Protocol Version 1.0
Author(s) : T. Dierks, C. Allen
Filename : draft-ietf-tls-protocol-01.txt
Pages : 67
Date : 03/07/1997
This document specifies Version 1.0 of the Transport Layer Security (TLS)
protocol, which is at this stage is strictly based on the Secure Sockets
Layer (SSL) version 3.0 protocol, and is to serve as a basis for future
discussions. The TLS protocol provides communications privacy over the
Internet. The protocol allows client/server applications to communicate in
a way that is designed to prevent eavesdropping, tampering, or message
forgery.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-tls-protocol-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tls-protocol-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tls-protocol-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970307164422.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tls-protocol-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tls-protocol-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970307164422.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa13662; 10 Mar 97 11:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10835;
10 Mar 97 11:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA12084 at pad-thai.cam.ov.com>; Mon, 10 Mar 1997 14:49:16 GMT
Date: Mon, 10 Mar 1997 09:46:29 -0500
Message-Id: <9703101446.AA16204 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Rich Salz <rsalz at osf.org>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: Rich Salz's message of Sat, 8 Mar 1997 01:22:56 -0500 (EST),
<199703080622.BAA28241 at sulphur.osf.org>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Sat, 8 Mar 1997 01:22:56 -0500 (EST)
From: Rich Salz <rsalz at osf.org>
Why isn't thread-local-storage/thread-specific-data acceptable?
Yes, it would probably bind a particular GSSAPI implementation to
a particular threads package, but I don't see that as onerous:
How many OS's, where you wouldn't have GSSAPI source available to
port, support more than one threads library?
Quite a few, actually. Between non-OS specific thread implementations
like Chris Provenzano's pthreads, and DCE threads (implementing
different versions of the POSIX standard and POSIX draft standards), and
OS-specific thread packages such as are distributed with Solaris and
other vendor operating systems, I consider thread portability to be a
real nightmare.
As for "Redmond" are you talking about the problems with Windows
DLL's and static data, or something else? (There's really no need
to be oblique, is there?)
Yes, that's what I'm referring to; I would have thought that was
obvious. :-)
- Ted
Received: from ietf.org by ietf.org id aa18175; 10 Mar 97 15:00 EST
Received: from suntan.tandem.com by ietf.org id aa17988; 10 Mar 97 14:53 EST
Received: from tigger.tower.tandem.com.tower.tandem.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf at ietf.org>
id LAA25037; Mon, 10 Mar 1997 11:50:47 -0800
Received: from oltp-keithe (dhcp95-184.loc252.tandem.com) by tigger.tower.tandem.com.tower.tandem.com (4.1/6main.931028)
id AA18814; Mon, 10 Mar 97 11:56:42 PST
Message-Id: <9703101956.AA18814 at tigger.tower.tandem.com.tower.tandem.com>
Sender:ietf-request at ietf.org
From: Keith Evans <keith at loc252.tandem.com>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Announcing TIP BOF at Memphis IETF Meeting, April 9
Date: Mon, 10 Mar 1997 11:51:25 -0800
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> There will be a TIP "birds of a feather" (BOF) session, 1-2pm, Weds April
> 9th, at the Memphis IETF meeting.
>
> Name: Transaction Internet Protocol (TIP) BOF
>
> Area: Applications
>
> Chair: Keith Evans (keith at loc252.tandem.com)
>
> Description:
>
> The standard method for achieving atomic commitment is the two-phase
> commit protocol.
>
> Numerous two-phase commit protocols have been implemented over the
> years. However, none of them has become widely used in the Internet,
> due mainly to their complexity. Most of that complexity comes from
> the fact that the two-phase commit protocol is bundled together with
> a specific program-to-program communication protocol, and that
> protocol lives on top of a very large infrastructure.
>
> TIP proposes a very simple two-phase commit protocol. It
> achieves its simplicity by specifying only how different nodes agree
> on the outcome of a transaction; it allows (even requires) that the
> subject matter on which the nodes are agreeing be communicated via
> other protocols. By doing so, all of the issues related to
> application communication semantics and data representation
> (to name just a few) are avoided.
>
> It is envisioned that this protocol will be used mainly for a
> transaction manager on one Internet node to communicate with a
> transaction manager on another node.
>
> TIP BOF Agenda: 1) socialise the TIP protocol (presentation),
> 2) solicit feedback re the protocol (questions, suggestions for
> enhancement, etc), 3) ascertain support for moving TIP forward as an
> IETF standard.
>
> The current TIP proposal is described in draft-lyon-itp-nodes-00.txt
>
> General information re this meeting can be found at:
>
> http://www.ietf.org/meetings/Memphis.html
>
> Anyone interested in discussing TIP (particularly those considering TIP
> implementations), and wishing to further TIP as an Internet Standard are
> encouraged to attend.
>
> -Keith
Received: from ietf.org by ietf.org id aa18936; 10 Mar 97 15:11 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa18889;
10 Mar 97 15:10 EST
Received: from Ikkoku-Kan.Panda.COM (clam at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id MAA03704; Mon, 10 Mar 1997 12:07:52 -0800 (PST)
Received: from localhost (chince at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id MAA03411; Mon, 10 Mar 1997 12:07:48 -0800 (PST)
Date: Mon, 10 Mar 1997 11:23:02 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: call for a new email infrastructure
To: ietf at ietf.org
Message-ID: <MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
It is high time to put together a working group for a new sender-pays email
infrastructure to replace the current recipient-pays SMTP infrastructure. The
current system works only when their is cooperation between all parties to
keep abuse in check. That has failed.
We can no longer wait for the large ISPs to take action. MCI and BBN are, at
best, mixed. PSI has done nothing (and consequently net 38 is blocked at a
lot of sites). UUNET openly states that it is not their responsibility.
SPRINT bounces email sent to their "abuse" address; when you call the SPRINT
NOC and follow their alternate instructions, you get rude or obscene email
from their employees.
The mechanism that I envision involves the concept of a "message center"; a
site signs up with a message center the way it signs up with an ISP. The site
has its mail MXed to the message center, and disables its own SMTP server.
Message centers would have contractual arrangements with other message centers
for the interchange of mail between them.
To some extent, the message center would play the role that the postal
authorities do with postal mail. The current situation in email is that
everybody puts mail in everybody else's mailbox, whereas with postal mail only
the postal authorities can place mail in someone's mailbox.
The difference with the message center model is that message centers would be
competing non-governmental entities, albeit with a contractual requirement to
interchange mail. So, it is closer to the telephone model, although with a
few additional twists.
The message center would also, in the short term, have an SMTP server for
compatibility with the past, but SMTP mail may be subject to filtering and
other mechanisms.
The purpose of the message center is multifold:
1) The message center authenticates mail as coming from the site, using a
secure message interchange protocol (not SMTP).
2) The message center handles details of charging and cost accounting,
including special arrangements (e.g. EDUs might want to waive charges
with other EDUs).
3) The message center provides a single point by which spam can be blocked.
Suspicious SMTP traffic patterns can be detected, and action taken.
4) The message center could also handle premium services, e.g. the email
equivalent of a 900 number.
The only other choice is government regulation. That option is looking better
all the time. One thing that might get the ISPs attention is legislation that
mandates a UCE charge (much like the junk FAX charge) that is levied against
the originating ISP (or failing that, to the next upstream provider). If ISPs
find themselves socked with a $500/recipient liability for each spam incident,
they may become somewhat more selective about who they sign up as customers.
Received: from ietf.org by ietf.org id aa22147; 10 Mar 97 16:56 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa21909; 10 Mar 97 16:47 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id QAA07185; Mon, 10 Mar 1997 16:43:08 -0500 (EST)
Message-Id: <199703102143.QAA07185 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Mark Crispin <MRC at panda.com>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 10 Mar 1997 11:23:02 PST."
<MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Mar 1997 16:43:08 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> It is high time to put together a working group for a new sender-pays email
> infrastructure to replace the current recipient-pays SMTP
> infrastructure.
Sender-pays doesn't solve the problem. Despite the high cost of snail
mail, the S/N ratio of my incoming snail-mail is far worse than that
of incoming my e-mail. Sender-pays didn't sufficiently discourage
junk faxes either.
A nearly-inevitable result of sender-pays, is that it costs *less* to
send bulk mail than it does to send interpersonal mail. This
increases the incidence of spam.
Be careful what you wish for.
Keith
Received: from ietf.org by ietf.org id aa22796; 10 Mar 97 17:14 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa22713;
10 Mar 97 17:13 EST
Received: from Ikkoku-Kan.Panda.COM (gnof at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id OAA03828; Mon, 10 Mar 1997 14:10:36 -0800 (PST)
Received: from localhost (gin at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id OAA03941; Mon, 10 Mar 1997 14:10:31 -0800 (PST)
Date: Mon, 10 Mar 1997 14:03:54 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: call for a new email infrastructure
To: Keith Moore <moore at cs.utk.edu>
cc: ietf at ietf.org, moore at cs.utk.edu
In-Reply-To: <199703102143.QAA07185 at ig.cs.utk.edu>
Message-ID: <MailManager.858031434.366.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 10 Mar 1997 16:43:08 -0500, Keith Moore wrote:
> A nearly-inevitable result of sender-pays, is that it costs *less* to
> send bulk mail than it does to send interpersonal mail. This
> increases the incidence of spam.
This can be avoided if the recipients set their own fee schedules.
But, more importantly, it's doubtful that the spammers would want their mail
to be stamped with "bulk mail" postage, given that it would then be trivial
for sites to toss out all bulk mail unconditionally.
Received: from ietf.org by ietf.org id aa24050; 10 Mar 97 17:34 EST
Received: from cnri by ietf.org id aa23990; 10 Mar 97 17:33 EST
Received: from monet.caad.ed.ac.uk by CNRI.Reston.VA.US id aa17953;
10 Mar 97 17:33 EST
Received: from [129.215.100.202] (mac-202.caad.ed.ac.uk [129.215.100.202]) by monet.caad.ed.ac.uk (8.6.13/8.6.9) with SMTP id WAA02208; Mon, 10 Mar 1997 22:29:33 GMT
Date: Mon, 10 Mar 1997 22:29:33 GMT
Message-Id: <199703102229.WAA02208 at monet.caad.ed.ac.uk>
X-Sender: richard at monet.caad.ed.ac.uk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: gxg9562 at tesla.njit.edu, harfmann at headcheese.daa.uc.edu,
Hartmut.Benz at informatik.uni-stuttgart.de, herzner at zdfzs.arcs.ac.at,
hipparch at sophia.inria.fr, hjoseph at crcg.edu,
hoffmann at osiris.iemar.tuwien.ac.at, holiday at mevis.uni-bremen.de,
hori at ai.rcast.u-tokyo.ac.jp, ianb at ariel.ucs.unimelb.edu.au,
IETF at CNRI.Reston.VA.US, isadsoc at fokus.gmd.de, ivo at modern.u-net.com,
J.A.Self at cbl.leeds.ac.uk, j.jo at eas.gu.edu.au, j.l.alty at lboro.ac.uk,
J.L.Leach at maths.bath.ac.uk, J.McDonnell at cs.ucl.ac.uk, J.Plume at unsw.edu.au,
jakima at cksr.ac.bialystok.pl, james at arch.su.edu.au,
janssent at smtplink.dis.anl.gov, JLA ARMAS <JLAA at arucas.cda.ulpgc.es>,
MALTRET <jlm at gamsau.archi.fr>, jnd at hitl.washington.edu,
joe at gcr2.fcit.monash.edu.au, John.Riley at rd.bbc.co.uk, john17 at mdx.ac.uk,
john at caad.ed.ac.uk, jos.de.bruin at pi.net
Sender:ietf-request at ietf.org
From: Richard Coyne <Richard.Coyne at ed.ac.uk>
Subject: EuropIA'97 registration
Cc: Ronnie.Galloway at ed.ac.uk, mike at caad.ed.ac.uk
Source-Info: From (or Sender) name not authenticated.
If you are intending to register for EuropIA'97, and have not done so, then
please do so urgently, and email your intention to Ronnie.Galloway at ed.ac.uk
Authors 175 pounds stirling
Non-authors 250 pounds stirling
Conference Dinner 27 pounds stirling
EuropIA'97 Design and the Net 2-3 April 1997
Registrations: Ronnie.Galloway at ed.ac.uk
http://www.caad.ed.ac.uk/europia
UnivEd Technologies Limited
11 South College Street, Edinburgh, EH8 9AA
Ph +44 131 650 9020 Fax +44 131 650 9019
---------------------------------------------------------------------------
Richard Coyne Tel: +44 131 650 2332
Department of Architecture Fax: +44 131 650 8019
University of Edinburgh email: Richard.Coyne at ed.ac.uk
20 Chambers Street EH1 1JZ Scotland http://www.caad.ed.ac.uk/~richard/
Received: from ietf.org by ietf.org id aa24834; 10 Mar 97 17:46 EST
Received: from songbird.com by ietf.org id aa24505; 10 Mar 97 17:43 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id OAA05398; Mon, 10 Mar 1997 14:38:17 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703102238.OAA05398 at songbird.com>
Subject: Re: call for a new email infrastructure
To: Keith Moore <moore at cs.utk.edu>
Date: Mon, 10 Mar 1997 14:38:17 -0800 (PST)
Cc: MRC at panda.com, ietf at ietf.org, moore at cs.utk.edu
In-Reply-To: <199703102143.QAA07185 at ig.cs.utk.edu> from "Keith Moore" at Mar 10, 97 04:43:08 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Keith Moore allegedly said:
>
> > It is high time to put together a working group for a new sender-pays email
> > infrastructure to replace the current recipient-pays SMTP
> > infrastructure.
>
> Sender-pays doesn't solve the problem. Despite the high cost of snail
> mail, the S/N ratio of my incoming snail-mail is far worse than that
> of incoming my e-mail. Sender-pays didn't sufficiently discourage
> junk faxes either.
>
> A nearly-inevitable result of sender-pays, is that it costs *less* to
> send bulk mail than it does to send interpersonal mail. This
> increases the incidence of spam.
It will always be cheaper to send bulk mail, regardless of who pays.
Another model that might be considered, besides "sender pays", is
"receiver pays for a filtered source" model. That is, if you want
cheap email connectivity, you deal with ads, just like broadcast TV.
Otherwise, you get connectivity that is filtered, like cable TV. You
pay extra for the service, but you avoid most of the spam.
Such a scheme has several advantages, the most important of which is
that it can be implemented on top of the existing infrastructure.
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: 5A 16 DA 04 31 33 40 1E 87 DA 29 02 97 A3 46 2F
Received: from ietf.org by ietf.org id aa25766; 10 Mar 97 18:04 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa25694; 10 Mar 97 18:02 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id RAA04616; Mon, 10 Mar 1997 17:57:44 -0500 (EST)
Message-Id: <199703102257.RAA04616 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: Kent Crispin <kent at songbird.com>
cc: Keith Moore <moore at cs.utk.edu>, MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 10 Mar 1997 14:38:17 PST."
<199703102238.OAA05398 at songbird.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Mar 1997 17:57:44 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> It will always be cheaper to send bulk mail, regardless of who pays.
Right. "Sender-pays" merely increases the difference in cost.
It's difficult to increase the signal-to-noise ratio of a channel by
decreasing the signal level.
Keith
Received: from ietf.org by ietf.org id aa26553; 10 Mar 97 18:18 EST
Received: from apollo.it.hq.nasa.gov by ietf.org id aa26492; 10 Mar 97 18:16 EST
Received: from wirehead.it.hq.nasa.gov (WireHead.it.hq.nasa.gov [131.182.119.88]) by apollo.it.hq.nasa.gov (8.8.3/8.8.3) with ESMTP id SAA25886; Mon, 10 Mar 1997 18:11:49 -0500 (EST)
Received: from localhost (cshenton at localhost) by wirehead.it.hq.nasa.gov (8.6.12/8.6.12) with ESMTP id XAA21603; Mon, 10 Mar 1997 23:14:06 GMT
Message-Id: <199703102314.XAA21603 at wirehead.it.hq.nasa.gov>
X-Authentication-Warning: wirehead.it.hq.nasa.gov: cshenton owned process doing -bs
To: kent at songbird.com
Cc: moore at cs.utk.edu, MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Mon, 10 Mar 1997 14:38:17 -0800 (PST)"
References: <199703102238.OAA05398 at songbird.com>
X-Mailer: Mew version 1.03 on Emacs 19.31.8
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Mon, 10 Mar 1997 18:14:04 -0500
Sender:ietf-request at ietf.org
From: Chris Shenton <cshenton at it.hq.nasa.gov>
Source-Info: From (or Sender) name not authenticated.
On Mon, 10 Mar 1997 14:38:17 -0800 (PST)
Kent Crispin <kent at songbird.com> wrote:
kent> Another model that might be considered, besides "sender pays", is
kent> "receiver pays for a filtered source" model. That is, if you want
kent> cheap email connectivity, you deal with ads, just like broadcast TV.
kent> Otherwise, you get connectivity that is filtered, like cable TV. You
kent> pay extra for the service, but you avoid most of the spam.
Except that the promise of commercial-free (or significantly reduced
commercials) on cable is a dismal failure. They're just different
commercials, placed differently thoughout the hour.
But since the net is demand-driven, it's conceivable for multiple
providers to offer varying degrees of filtering. A serious spam-nazi
filter might, however, significantly slow your mail delivery...
Received: from ietf.org by ietf.org id aa27818; 10 Mar 97 18:44 EST
Received: from callandor.cybercash.com by ietf.org id aa27778;
10 Mar 97 18:43 EST
Received: by callandor.cybercash.com; id SAA04033; Mon, 10 Mar 1997 18:34:34 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma004024; Mon, 10 Mar 97 18:34:07 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA02406; Mon, 10 Mar 97 18:37:07 EST
Date: Mon, 10 Mar 1997 18:37:07 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703102143.QAA07185 at ig.cs.utk.edu>
Message-Id: <Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 10 Mar 1997, Keith Moore wrote:
> Date: Mon, 10 Mar 1997 16:43:08 -0500
> From: Keith Moore <moore at cs.utk.edu>
> To: Mark Crispin <MRC at panda.com>
> Cc: ietf at ietf.org, moore at cs.utk.edu
> Subject: Re: call for a new email infrastructure
>
> > It is high time to put together a working group for a new sender-pays email
> > infrastructure to replace the current recipient-pays SMTP
> > infrastructure.
>
> Sender-pays doesn't solve the problem. Despite the high cost of snail
> mail, the S/N ratio of my incoming snail-mail is far worse than that
> of incoming my e-mail. Sender-pays didn't sufficiently discourage
> junk faxes either.
I don't believe any single mechanism will solve the spam problem or that any
reasonable combination of mechanisms will completely eliminate it. I do
believe that a combination of mechanisms will bring it under reasonable
control. I don't think it is that applicable to compare your spam to real
mail ratio for physical and email today becasue I believe this ratio is
realtively stable for physical mail, which typically costs the sender around
$1 when you get done with postage, printing, buying a reasonable quality
mailing list, etc. In contract, the amount of spam being sent is increasing
exponentially. Commercial rates for bulk email transmission are 0.01 cents
($10 per 100K messages) per address and that includes profit. That's *four*
*orders* *of* *magnitude* cheaper than postal bulk mail.
Ever media (postal, fax, voice, email, ...) is different in terms of cost to
send, cost to receive, intrusiveness, etc., and each will probably require a
different balance of techncial, financial, legal, and social, measures.
> A nearly-inevitable result of sender-pays, is that it costs *less* to
> send bulk mail than it does to send interpersonal mail. This
> increases the incidence of spam.
Not for any sort of sender-pays that I have proposed. You seem to be
making the assumption that the sender pays some sort of actual network
costs in all cases. What you want is to require the sender to pay
whatever the receiver asks, if they want their mail to get through, with
the receiver being easily able to exempt known correspondents and mailing
lists and the like.
> Be careful what you wish for.
I don't claim they are final polished proposals, but what I wish for is full
implementation and deployment of ubiquitious email security and optional
charging capabilities along the lines of
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-muse-01.txt> and
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-internet-payment-02.txt>.
> Keith
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa28189; 10 Mar 97 18:50 EST
Received: from rodan.UU.NET by ietf.org id aa27981; 10 Mar 97 18:49 EST
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQcgig29549; Mon, 10 Mar 1997 18:44:48 -0500 (EST)
Message-Id: <QQcgig29549.199703102344 at rodan.UU.NET>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Keith Moore <moore at cs.utk.edu>
cc: Kent Crispin <kent at songbird.com>, MRC at panda.com, ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: call for a new email infrastructure
References: <199703102257.RAA04616 at ig.cs.utk.edu>
In-reply-to: Your message of "Mon, 10 Mar 1997 17:57:44 EST."
<199703102257.RAA04616 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Mar 1997 18:44:48 -0500
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
The alternative approach is to push for the deployment of authenticated
(and perhaps privacy enhanced mail). Then user agents could be configured
to apply policy to messages as they receive them. If mailing lists could
be so configured to change forwareding policy based on originator, then
we could make significant progress in seeing the messages we want to
see, and deferring/ignoring/whatever the others.
Louis Mamakos
Received: from ietf.org by ietf.org id aa29576; 10 Mar 97 18:59 EST
Received: from [204.94.142.153] by ietf.org id aa29515; 10 Mar 97 18:58 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id PAA04374 for ietf at ietf.org; Mon, 10 Mar 1997 15:56:50 -0800
Date: Mon, 10 Mar 1997 15:56:50 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703102356.PAA04374 at egoshin.genesyslab.com>
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
I can suggest yet another way - something like Authentificated Mail
Transfer Protocol. It can take measures to deliver only E-mail which
had authentificated source host (without uncontrolled gating).
After that it can be simple to support the list of hosts with mail
spammers... or list of networks in case of dialup entry points.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa00667; 10 Mar 97 19:10 EST
Received: from gate2.sprintlink.net by ietf.org id aa00465; 10 Mar 97 19:09 EST
Received: from iscserv.res.sprintlink.net by gate2.sprintlink.net
via smtpd (for ietf.org [132.151.1.19]) with SMTP; 10 Mar 1997 23:56:45 UT
Received: from localhost (ramanan at localhost)
by iscserv.res.sprintlink.net (8.8.5/8.8.5) with SMTP id TAA27960
for <ietf at ietf.org>; Mon, 10 Mar 1997 19:04:18 -0500 (EST)
Date: Mon, 10 Mar 1997 19:04:18 -0500 (EST)
Sender:ietf-request at ietf.org
From: Ramanan <ramanan at sprint.net>
X-Sender: ramanan at iscserv
Reply-To: Ramanan <ramanan at sprint.net>
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
Message-ID: <Pine.GSO.3.95.970310185655.27751A-100000 at iscserv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
kent> Another model that might be considered, besides "sender pays", is
kent> "receiver pays for a filtered source" model. That is, if you want
kent> cheap email connectivity, you deal with ads, just like broadcast TV.
kent> Otherwise, you get connectivity that is filtered, like cable TV.You
kent> pay extra for the service, but you avoid most of the spam.
Thats a good suggestion. But has anyone thought of this model --
"sender pays, and receiver gets a percentage or all the
benefit, after all the bulk email is going to be based
on the personal information that receiver provided at some
point"
This way it will be an added incentive for the user (receiver)
and may probably encourage more internet usage. Just a thought !!
--Ramanan
Received: from cnri by ietf.org id aa02896; 10 Mar 97 19:42 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20104;
10 Mar 97 19:42 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA03216 at pad-thai.cam.ov.com>; Mon, 10 Mar 1997 23:16:34 GMT
Message-Id: <332495EB.7535 at dascom.com>
Date: Mon, 10 Mar 1997 15:14:51 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: GSSAPI and SSL?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Is anyone looking into (or have done) integration of SSL under the
GSSAPI?
Is there any interest in the GSSAPI community in this?
Or do you view these things as virtually interchangeable (i.e. solves
the same problem)?
Does this even make any sense?
Thanks, John
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa04087; 10 Mar 97 20:31 EST
Received: from npcc.net by ietf.org id aa03996; 10 Mar 97 20:27 EST
Received: from cjmeyer (dial26.npcc.net [206.160.236.26]) by npcc.net (8.8.3/8.7.3) with ESMTP id UAA13633 for <ietf at ietf.org>; Mon, 10 Mar 1997 20:25:02 -0500 (EST)
Message-Id: <199703110125.UAA13633 at npcc.net>
Sender:ietf-request at ietf.org
From: Carl Meyer <cjmeyer at npcc.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: call for a new email infrastructure
Date: Mon, 10 Mar 1997 20:23:44 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> I can suggest yet another way - something like Authentificated Mail
> Transfer Protocol. It can take measures to deliver only E-mail which
> had authentificated source host (without uncontrolled gating).
> After that it can be simple to support the list of hosts with mail
> spammers... or list of networks in case of dialup entry points.
I agree. Most half-decent mail readers can filter incoming mail, so all
that is really required is sender authentification. The additional
advantage is that it doesn't even involve the slightest hint of censorship.
Everyone can decide for themselves exactly who they'd like to see mail
from and who they wouldn't. In the most extreme case, a user could simply
block all mail by default, and only allow mail in from chosen users. A
firewall for email, essentially. All that's lacking in the current system
is sender authentification, which I consider a feature worth implementing
in any case, apart from the issue of spam.
peace
(ar|
Received: from ietf.org by ietf.org id aa04157; 10 Mar 97 20:33 EST
Received: from smtp.dtinet.or.jp by ietf.org id aa04114; 10 Mar 97 20:32 EST
Received: from ppp0.shimizu.dtinet.or.jp (ppp0.shimizu.dtinet.or.jp [203.181.70.33]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with SMTP id KAA19946 for <ietf at ietf.org>; Tue, 11 Mar 1997 10:29:33 +0900 (JST)
Message-Id: <3.0.1.32.19970311100125.006ac06c at twics.com>
X-Sender: martyn at twics.com
X-Mailer: Windows Eudora Pro Version 3.0.1 beta 8 (32)
Date: Tue, 11 Mar 1997 10:01:25 +0900
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Martyn Williams <martyn at twics.com>
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703102238.OAA05398 at songbird.com>
References: <199703102143.QAA07185 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
> It is high time to put together a working group for a new sender-pays email
> infrastructure to replace the current recipient-pays SMTP
> infrastructure.
If a sender pays system begins it legitimises the use of e-mail for mass
mailing purposes so this path would have to be very carefully taken. I'm
sure once such a system began, it would attract companies that had, until
now, kept from mass mailing because of the resent it causes.
I don't think the idea of the recipient setting the fees would do much
either. Heavy users, who are presumably those most bothered and most vocal
about mass e-mail, would not want to impose a large incoming fee because of
the heavy use they make of the Internet. Thus mass emailers also wouldn't
be detered. It would also have to be very sophisticated because I might
want to impose a $1 a message charge on spammers but would want mailing
lists and email-delivered services to come in for free.
Martyn
--
Martyn Williams |Internet : martyn at twics.com
Shimizu, Japan |Internet : martyn at newsbytes.com
|CompuServe : 74777,1301
http://www.twics.com/~martyn |Fax : 0543-64-0199
Received: from cnri by ietf.org id aa08832; 10 Mar 97 22:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22577;
10 Mar 97 22:46 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <CAA09668 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 02:15:58 GMT
Message-Id: <3.0.32.19970310181259.0070d9c0 at pop-srvr>
X-Sender: arim at pop-srvr
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 10 Mar 1997 18:12:59 -0800
To: johnn at dascom.com, cat-ietf at mit.edu
From: Ari Medvinsky <ari.medvinsky at cybersafe.com>
Subject: Re: GSSAPI and SSL?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
At 03:14 PM 3/10/97 -0800, John Nunneley wrote:
>Is anyone looking into (or have done) integration of SSL under the
>GSSAPI?
>Is there any interest in the GSSAPI community in this?
>Or do you view these things as virtually interchangeable (i.e. solves
>the same problem)?
>Does this even make any sense?
>Thanks, John
I have not looked into this. However, there is an internet draft that
we authored for integrating Kerberos and SSL.
The draft is available from the TLS working group's web page.
cheers,
-Ari
Received: from cnri by ietf.org id aa15368; 11 Mar 97 0:45 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01592;
11 Mar 97 0:45 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA12794 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 03:49:10 GMT
Date: Mon, 10 Mar 1997 19:48:14 -0800 (PST)
From: Mike Eisler <Michael.Eisler at eng.sun.com>
Reply-To: Mike Eisler <Michael.Eisler at eng.sun.com>
Subject: Re: GSSAPI and SSL?
To: johnn at dascom.com
Cc: cat-ietf at mit.edu
In-Reply-To: "Your message with ID" <332495EB.7535 at dascom.com>
Message-Id: <Roam 0.9.4.858052094.26887.mre at jurassic.eng.sun.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Precedence: bulk
> Is anyone looking into (or have done) integration of SSL under the
> GSSAPI?
> Is there any interest in the GSSAPI community in this?
> Or do you view these things as virtually interchangeable (i.e. solves
> the same problem)?
> Does this even make any sense?
I've had similar thoughts. One could create a GSS-API mechanism that mimiced
SSL's CipherSuites as QOP values (using the same numerical values). And one
could also mimic SSL's CipherSuite negotiation during the
GSS_Init_sec_context/GSS_Accept_sec_context handshake.
The value in this would be in simplifying the deployment of protocols that use
GSS-API security into operating environments that favor SSL (for example web
browsers). While the result would NOT be the SSL protocol, it would be
security equivalent to what SSL delivers. Presumably, if the operating
environment has modularized the SSL layer appropriately, the GSS-SSL
mechanism could share code with the SSL protocol's API:
internal SSL-api GSS-API
| |
ssl-protocol engine gss-ssl-mech
\ /
ssl-crypto-code
-
Mike Eisler
SunSoft, Inc.
mre at Eng.Sun.Com
Received: from ietf.org by ietf.org id aa15996; 11 Mar 97 1:26 EST
Received: from mail2.microsoft.com by ietf.org id aa15860; 11 Mar 97 1:22 EST
Received: by mail2.microsoft.com with Internet Mail Service (5.0.1457.3)
id <GWWK0J36>; Mon, 10 Mar 1997 21:43:57 -0800
Message-ID: <2120C028D567CF11BB8700805FD4CC4C01E6B2EE at RED-11-MSG.dns.microsoft.com>
Sender:ietf-request at ietf.org
From: Tony Hain <tonyhain at microsoft.com>
To: Martyn Williams <martyn at twics.com>, ietf at ietf.org
Subject: RE: call for a new email infrastructure
Date: Mon, 10 Mar 1997 18:51:17 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Source-Info: From (or Sender) name not authenticated.
Another 'feature' of sender pays would be legal action if arbitrary
blocking (like that done now) is installed. Since the sender has paid
for the right it would be more difficult to argue the bits should be
blocked or hampered in any way before hitting the destination mail box.
This sounds like a box that should be left closed.
Tony
-----Original Message-----
From: Martyn Williams [SMTP:martyn at twics.com]
Sent: Monday, March 10, 1997 5:01 PM
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
> It is high time to put together a working group for a
new sender-pays email
> infrastructure to replace the current recipient-pays
SMTP
> infrastructure.
If a sender pays system begins it legitimises the use of
e-mail for mass
mailing purposes so this path would have to be very
carefully taken. I'm
sure once such a system began, it would attract
companies that had, until
now, kept from mass mailing because of the resent it
causes.
I don't think the idea of the recipient setting the fees
would do much
either. Heavy users, who are presumably those most
bothered and most vocal
about mass e-mail, would not want to impose a large
incoming fee because of
the heavy use they make of the Internet. Thus mass
emailers also wouldn't
be detered. It would also have to be very sophisticated
because I might
want to impose a $1 a message charge on spammers but
would want mailing
lists and email-delivered services to come in for free.
Martyn
--
Martyn Williams |Internet :
martyn at twics.com
Shimizu, Japan |Internet :
martyn at newsbytes.com
|CompuServe :
74777,1301
http://www.twics.com/~martyn |Fax :
0543-64-0199
Received: from ietf.org by ietf.org id aa15997; 11 Mar 97 1:26 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa15928; 11 Mar 97 1:25 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id BAA08638; Tue, 11 Mar 1997 01:20:54 -0500 (EST)
Message-Id: <199703110620.BAA08638 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 10 Mar 1997 18:37:07 EST."
<Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Date: Tue, 11 Mar 1997 01:20:53 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> What you want is to require the sender to pay
> whatever the receiver asks, if they want their mail to get through, with
> the receiver being easily able to exempt known correspondents and mailing
> lists and the like.
Nope, that's nowhere close to what I want. I certainly don't want
to manage a list of people who are allowed to communicate with me
for cheap or free, just so I don't see spam. That would not only
exclude far more traffic than I want to exclude, it would also take
up far more of my time, than dealing with spam.
The cure is worse than the disease.
Keith
Received: from ietf.org by ietf.org id aa17111; 11 Mar 97 1:42 EST
Received: from callandor.cybercash.com by ietf.org id aa17058;
11 Mar 97 1:41 EST
Received: by callandor.cybercash.com; id BAA17631; Tue, 11 Mar 1997 01:32:29 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma017610; Tue, 11 Mar 97 01:31:47 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA08245; Tue, 11 Mar 97 01:34:47 EST
Date: Tue, 11 Mar 1997 01:34:46 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Tony Hain <tonyhain at microsoft.com>
Cc: ietf at ietf.org
Subject: RE: call for a new email infrastructure
In-Reply-To: <2120C028D567CF11BB8700805FD4CC4C01E6B2EE at RED-11-MSG.dns.microsoft.com>
Message-Id: <Pine.SUN.3.91.970311013359.7676E-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Any reasonable system would only collect a payment if the mail is
accepted.
Donald
On Mon, 10 Mar 1997, Tony Hain wrote:
> Date: Mon, 10 Mar 1997 18:51:17 -0800
> From: Tony Hain <tonyhain at microsoft.com>
> To: Martyn Williams <martyn at twics.com>, ietf at ietf.org
> Subject: RE: call for a new email infrastructure
>
> Another 'feature' of sender pays would be legal action if arbitrary
> blocking (like that done now) is installed. Since the sender has paid
> for the right it would be more difficult to argue the bits should be
> blocked or hampered in any way before hitting the destination mail box.
> This sounds like a box that should be left closed.
>
> Tony
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa18316; 11 Mar 97 2:03 EST
Received: from callandor.cybercash.com by ietf.org id aa18280;
11 Mar 97 2:02 EST
Received: by callandor.cybercash.com; id BAA18110; Tue, 11 Mar 1997 01:53:33 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma018100; Tue, 11 Mar 97 01:53:02 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA08384; Tue, 11 Mar 97 01:56:02 EST
Date: Tue, 11 Mar 1997 01:56:02 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Keith Moore <moore at cs.utk.edu>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703110620.BAA08638 at ig.cs.utk.edu>
Message-Id: <Pine.SUN.3.91.970311013555.7676F-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I thought I made it clear that I believe that multiple techniques are needed.
I thought I made it clear that charging was an option.
There are already a growing number of people that bounce all mail that's not
either from entities on a white list or has a magic password in it. Would
you prefer to pay 1 cent, say, the first time you send individual email to
someone (would might then be able to just click on something on their screen
to make future mail from you free) or would you prefer for your mail to
bounce with a message telling you (in some complex way to make it
deliberately hard to process automatically by a spam daemon) to resend with
such a magic password?
On Tue, 11 Mar 1997, Keith Moore wrote:
> Date: Tue, 11 Mar 1997 01:20:53 -0500
> From: Keith Moore <moore at cs.utk.edu>
>
> Nope, that's nowhere close to what I want. I certainly don't want
> to manage a list of people who are allowed to communicate with me
> for cheap or free, just so I don't see spam. That would not only
> exclude far more traffic than I want to exclude, it would also take
> up far more of my time, than dealing with spam.
You are making a lot of unwarranted assumptions about there being a poor
user interface. You should also note that many spammers leave out .edu,
.gov, and some other TLDs. So you are behind the poor people in .com for
general spam volume.
> The cure is worse than the disease.
This particular cure, which I only think shoyld be one of many tools in
the user's arsenal, remains about equally bad or might even get better with
improved user interfaces. Without some action, the disease gets
*exponentially* worse. I remember when I saw spam montly, then weekly, now
daily. How long will it be before its equal to all you regualr mail, then
ten times as much, then a hundred times as much, ...?
> Keith
Security and email syntax checking (including repliability) and IP blocking
and extensive contagiously spread black lists and social pressure and law
suits against spammers and laws against spam, etc., will all help but I think
the ability to impose applications level charges is a tool not to be
dismissed so lightly. And there are other applicaitons such as for pay
services invoked via email.
I didn't write draft-eastlake-internet-payment-02.txt because of spam. I
wrote it to provide a reasonable syntax for payment in the WWW context.
After handling the much more complex cases of the web, it occured to me that
it would be easy to add to a variety of other protocol including SMTP. I was
thinking of this in terms of payment for digital products or services. It
was only later that its possible use against spam occured to me.
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa19442; 11 Mar 97 2:48 EST
Received: from deliverator.io.com by ietf.org id aa19364; 11 Mar 97 2:45 EST
Received: from tristero.io.com (tristero.io.com [199.170.88.11])
by deliverator.io.com (8.8.5/8.8.5) with ESMTP id BAA16572
for <ietf at ietf.org>; Tue, 11 Mar 1997 01:28:08 -0600 (CST)
Received: from loopback (dialup-01-191.austin.io.com [199.170.89.191]) by tristero.io.com (8.8.5/8.6.12) with SMTP id BAA10054 for <ietf at ietf.org>; Tue, 11 Mar 1997 01:28:07 -0600 (CST)
Date: Tue, 11 Mar 1997 01:28:49 -0600 (CST)
Sender:ietf-request at ietf.org
From: John Harvey <johnbob at io.com>
X-Sender: johnbob at loopback
To: ietf at ietf.org
Subject: Re: call for a new email infrastructure
Message-ID: <Pine.A32.3.95.970311010201.18204A-100000 at loopback>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Perhaps we could develop a fetch based email system. Instead of sending
out the body of the message itself send a message id and a location from
which to fetch it. The sender would automatically be identified to some
extent because the fetch information would have to be valid for it to
work. The sender couldn't hit-and-run with a throwaway account because
the account would have to be valid long enough for the receiver to fetch
the body. Any receiver could reject mail by simply not fetching it. The
sender would have to store the messages on their disk or whatever storage
for however long they think the receivers will wait to fetch them. (This
probably wouldn't be a burden to junkmailers that are sending the same
message to everyone though.) For mailing lists (that you subscribe to,
like ietf) the message id and location could be forwarded instead of the
body so that it can be fetched from the originator.
hurm,
-john
John Harvey Email advertisers: put me on your "don't call, don't email" list.
home: johnbob at io. com http://www .io. com/~johnbob/
Received: from ietf.org by ietf.org id aa20917; 11 Mar 97 3:46 EST
Received: from SYNW06.elettra.trieste.it by ietf.org id aa20864;
11 Mar 97 3:45 EST
Date: Tue, 11 Mar 1997 9:41:14 +0100
To: ietf at ietf.org
CC: ALLOCCHIO at elettra.trieste.it
Message-Id: <970311094114.600534 at elettra.trieste.it>
Sender:ietf-request at ietf.org
From: "Claudio Allocchio, +39 40 3758523" <Claudio.Allocchio at elettra.trieste.it>
Subject: re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
Unsolicited mail is an old and more expanding problem... we called already for
suggestions, BOFs...
Sender-pays does not solve the problem at all:
- if sender pays, he feels legitimate to send as much unsolicited e-mail he/she
can afford to send. It means we will have "wealthy" entities flooding us,
and little ones sending only little stuff.
- if sender pays and we block his/her messages, he/she could take legal actions
against recepients, or anybody blocking his/her traffic... too bad!
We need a mixture of actions to limit the e-mail abuse:
- encourage the installation of "trusted mailers", i.e. objects which ONLY
accept and forward authenticated mail message. This also solves other
problems like fake messaging.
- adopt "level 3" filtering policy against proved sources of unsolicited
messages: after repeated abuse from a source, that network is filtered out
by major routers in the "area". If the area is the world and the routers
are the critical ones, the damage to the abuser can really affect his/her
complete business. As an example, the italian ISP are thinking to adopt
such a policy, filtering out abusers on the international and ISP to ISP
routers; level 3 filtering can be a total block, but they already all agreed
to have customers sign up contracts where they accept explicitly that mail
spamming is a violation of in force rules, thus they CAN act like this, if
they wish.
- add options to local MTAs like
list of rejected addresses/domains
list of accepted addresses/domains
i.e. sender accept/deny access lists
with options as "bounce / spool to dev/null" for rejected messages
(something like "Please do not disturb" hanging on the MTA). It is the same
idea used when you have called ID enabled on your phone and you can somehow
identify undesired callers.
other ideas?
regards
Claudio
Received: from ietf.org by ietf.org id aa23997; 11 Mar 97 7:28 EST
Received: from usr07.primenet.com by ietf.org id aa23898; 11 Mar 97 7:24 EST
Received: from primenet.com (root at mailhost02.primenet.com [206.165.5.53])
by usr07.primenet.com (8.8.5/8.8.5) with ESMTP id FAA02497
for <ietf at ietf.org>; Tue, 11 Mar 1997 05:21:15 -0700 (MST)
Received: from primenet.primenet.com (ip172.boi.primenet.com [198.68.45.172])
by primenet.com (8.8.5/8.8.5) with ESMTP id FAA20361
for <ietf at ietf.org>; Tue, 11 Mar 1997 05:21:12 -0700 (MST)
Message-Id: <199703111221.FAA20361 at primenet.com>
Sender:ietf-request at ietf.org
From: Michael Quinlan <mikeq at primenet.com>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: call for a new email infrastructure
Date: Tue, 11 Mar 1997 05:23:10 -0700
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> From: Martyn Williams <martyn at twics.com>
>
> I don't think the idea of the recipient setting the fees would do much
> either. Heavy users, who are presumably those most bothered and most
vocal
> about mass e-mail, would not want to impose a large incoming fee because
of
> the heavy use they make of the Internet. Thus mass emailers also wouldn't
> be detered. It would also have to be very sophisticated because I might
> want to impose a $1 a message charge on spammers but would want mailing
> lists and email-delivered services to come in for free.
More people should learn to play chess. If you charge $1 for spam, but let
mailing lists come in for free, what is the next move for the spammers?
They will send spam via unmoderated mailing lists that you subscribe to
(such as this one).
I vote for authenticated mailing, then I can filter the mail the way I want
to.
Received: from ietf.org by ietf.org id aa25099; 11 Mar 97 8:00 EST
Received: from smtpgw.ed.nce.sita.int by ietf.org id aa25044; 11 Mar 97 7:59 EST
Return-Path: <steen.larsen at smtpgw>
Received: from rdsita.rd-sita.fr by smtpgw.ed.nce.sita.int (8.7.5/SitaNet-1.5)
id NAA07500; Tue, 11 Mar 1997 13:54:23 +0100 (MET)
Received: from slarsen.ed.nce.sita.int (pc-edstl.ed.nce.sita.int) by rdsita.rd-sita.fr (5.0/SMI-SVR4)
id AA01175; Tue, 11 Mar 1997 13:55:31 --100
Message-Id: <3325566B.EA8 at ed.nce.sita.int>
Date: Tue, 11 Mar 1997 13:56:12 +0100
Sender:ietf-request at ietf.org
From: Steen Larsen <steen.larsen at ed.nce.sita.int>
Reply-To: steen.larsen at ed.nce.sita.int
Organization: SITA R&D Nice
X-Mailer: Mozilla 4.0b2 (Win95; I)
Mime-Version: 1.0
To: John Harvey <johnbob at io.com>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - Not needed
X-Priority: 3 (Normal)
References: <Pine.A32.3.95.970311010201.18204A-100000 at loopback>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
John Harvey wrote:
Perhaps we could develop a fetch based email system. Instead of
sending
out the body of the message itself send a message id and a location
from
which to fetch it. ....
MIME has this already. It is also common to use e-mail with HTML where
the main content
is retrieved by following a URL.
Best regards
Steen Larsen
--
Steen Koefoed Larsen
SITA R&D Nice, France | @ Home
E-mail: steen.larsen at ed.nce.sita.int | NEW E-mail: steen at who.net
Phone : +33 4 92.96.63.67 | GSM Mobile: +45 40512486
Fax : +33 4 92.96.64.92 | or (French) +33 6 09090568
Disclaimer: This letter may reflect my personal opinion.
*** Syntax? Why not - they tax everything else! ***
Received: from ietf.org by ietf.org id aa25210; 11 Mar 97 8:03 EST
Received: from tucows.alphanet.com.br by ietf.org id aa25169; 11 Mar 97 8:03 EST
Received: from tucows.alphanet.com.br (andre at tucows.alphanet.com.br [200.246.167.105]) by tucows.alphanet.com.br (8.7.5/8.7.3) with SMTP id KAA02452; Tue, 11 Mar 1997 10:00:19 -0300
Date: Tue, 11 Mar 1997 10:00:18 -0300 (EST)
Sender:ietf-request at ietf.org
From: Andre Correa <andre at tucows.alphanet.com.br>
Reply-To: Andre Correa <andre at tucows.alphanet.com.br>
To: Keith Moore <moore at cs.utk.edu>
cc: Kent Crispin <kent at songbird.com>, MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: <199703102257.RAA04616 at ig.cs.utk.edu>
Message-ID: <Pine.LNX.3.93.970310204810.891A-100000 at tucows.alphanet.com.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hello, I have no idea how this mails from IETF came to me, anyway
I have an opinion about it all: (and it is good to be here)
I use and work with Internet for 3 years and I received a little
number of unwanted mails, maybe, I am a luck guy, but I dont want to pay
to send or to receive mails, I want it to stay the way it is. Why dont
create this service of "mesage center" for those who want to have their
mails filtred, this guys will pay for the service of filtering their
e-mail...
Other thing, what we will gonna do with the large mailling lists??
Who will pay to send this mails for tousands of users??
My way looks better for me. Till now the Internet was a free field
and must continue this way!!! We must find and make something realy strong
and definitive with the bombers and guys that send unwanted mails.
Anyway this is just my opinion...
[]s.
<Andre>
Received: from ietf.org by ietf.org id aa26269; 11 Mar 97 8:19 EST
Received: from ns.jck.com by ietf.org id aa26195; 11 Mar 97 8:18 EST
Received: from tp7.Jck.com ("port 1434"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-7 #21705) with SMTP id <0E6VRI0HI005N4 at a4.jck.com>
for ietf at ietf.org; Tue, 11 Mar 1997 08:15:36 -0500 (EST)
Date: Tue, 11 Mar 1997 08:15:35 -0500 (EST)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: call for a new email infrastructure
In-reply-to: <199703111221.FAA20361 at primenet.com>
To: ietf at ietf.org
Message-id: <SIMEON.9703110835.Q at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1b1 Build (5)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
Looks like this discussion is going to go on forever, with
a S/N ratio just above spam. Let me try to draw a
few threads together, at least from the perspective
of one person who receives a *lot* of email.
* The thing I don't like about spam is that it is
unsolicited, has content I'm not interested in, takes up
bandwidth and time (on days when I pull mail through a
high-speed link, email trash (of any flavor) bothers me
less than when I have to suck it through a dialup-speed
connection, where I can painlessly delete it. I get most
of my smail at a post office box. The people in the post
office used to tease me, as I carried things directly from
the box to the trash barrel, that they had to do a lot of
work to deliver the stuff. I told them that they were paid
to deliver it; I wasn't paid to either read it or to carry
it around.
IMAP provides some help for this problem during the window
between when lots of people start using it and when the
spammers wise up enough to stop sending out messages with
subject lines like "!!!earn quick cash!!!"
* "Charge sender" changes the economic incentives a bit,
but I'm no more interested in receiving unsolicited trash
email from those who can pay than from those who can't/
won't. I think it would make useful social policy in some
ways, but that it isn't much of a solution.
* Selective sender charges, based on review of who is
sending, would either require a trusted mail backbone
(e.g., an official provider similar to national Post
Offices interconnected by treaties or the arrangements
anticipated between X.400 ADMDs) or would effectively
eliminate relays and most gateways from the Internet. Now,
while I consider relays and gateways to be the
sources of many problems, eliminating them would severely
reduce the range and scope of Internet mail.
* I would value the combination of authenticated mail and
server-based filters that would permit incoming mail to be
sorted into (at least) five filters/priorities:
(i) authenticated mail from sources on a white list
(ii) authenticated and verifiable mail from
other sources not falling into category (iv)
(iii) unidentified and unauthenticated mail
(iv) authenticated or unauthenticated mail from sources
on a black list
I might choose to trash the fourth category entirely; it
might take a l-o-n-g time for me to get around to reading
the third. And the ability to make these distinctions
would clearly permit a relay to reject any traffic not from
one of its customers, which would eliminate some of the
current problems without imposing intrastructure changes.
To do better than that, I need server-based content
analysis of incoming messages, content analysis that is
good enough to distinguish trash from discussions of trash
in which I might be interested. That is a seriously hard
problem unless I hire a human being to filter my mail.
What do we need for this?
-- Some agreement on standards for authenticated and
verifiable mail, and wide deployment of things that reflect
those standards. (Very hard, apparently)
-- Standards and tools for management of server-based
filters that can do the work above (and more). (Shouldn't
be rocket science, but we haven't been able to focus IETF
energy on this in the last several years)
-- No basic infrastructure changes
--john
Received: from ietf.org by ietf.org id aa27499; 11 Mar 97 8:35 EST
Received: from box.nl by ietf.org id aa27415; 11 Mar 97 8:33 EST
Received: from cs-gj3-a11.hro.nl (cs-gj3-a11.hro.nl [145.24.129.143]) by box.nl (8.7.5/8.6.9) with SMTP id OAA04876 for <ietf at ietf.org>; Tue, 11 Mar 1997 14:30:26 +0100
Date: Tue, 11 Mar 1997 14:30:26 +0100
Message-Id: <199703111330.OAA04876 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa27521; 11 Mar 97 8:35 EST
Received: from box.nl by ietf.org id aa27466; 11 Mar 97 8:35 EST
Received: from cs-gj3-a11.hro.nl (cs-gj3-a11.hro.nl [145.24.129.143]) by box.nl (8.7.5/8.6.9) with SMTP id OAA04890 for <ietf at ietf.org>; Tue, 11 Mar 1997 14:31:27 +0100
Date: Tue, 11 Mar 1997 14:31:27 +0100
Message-Id: <199703111331.OAA04890 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa27464; 11 Mar 97 8:35 EST
Received: from ietf.ietf.org by ietf.org id aa27362; 11 Mar 97 8:33 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: social at ietf38.fedex.net
Subject: 38th IETF Social
Date: Tue, 11 Mar 1997 08:33:21 -0500
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9703110833.aa27362 at ietf.org>
FedEx presents an evening of Da' Blues by Jo Jo and Delwood, the Other
Brothers of "The Other Brothers Blues" band at the Memphis Peabody Hotel
Skyway Ballroom.
They are on a mission from God, to party with the IETF. They are told the
live band, dancing to their favorite music, unlimited Arcade games,
Caricaturists, Cool View, Memphis Food, and Tubs of Beer will be well worth
the drive from Chicago.
DATE:
Tuesday, April 8th, 1997
TIME:
7 p.m.
LOCATION:
Memphis Peabody Hotel Skyway Ballroom
149 Union Avenue
Memphis, TN
The Peabody is located within walking distance or a trolley ride from most
of the downtown hotels.
PAYMENT:
US $30.00 in advance, (cash or check drawn on a U.S. bank only). Advance
payment will be taken at the Social Event table near the IETF Registration
Desk during registration hours.
COCKTAILS AND DINNER:
Hosted beer, wine and soft drinks will be served from 7:00 p.m. - 10:00 p.m.
MENU:
Memphis' World Famous Corky's BBQ
Baked Beans
Slaw
Grilled Vegetable Pita Pockets
Potato Skins with assorted toppings
Hot & Spicy Chicken Wings
Chinese Egg Rolls with Hot Mustard
Sliced Roast Turkey
French/Herb Rolls
Chips & Dips
Brownies
Lots of Good Food!
---------------------------------------------------------------------------
REGISTRATION FORM
RSVP to: social at ietf38.fedex.net SUBJECT: RSVP IETF Social
Memphis IETF Social
Hosted by FedEx
Peabody Hotel Skyway Ballroom
Tuesday, April 8th, 1997
7 p.m.
Cash (U.S. dollars) or company/personal checks (drawn on U.S. banks) are
acceptable. Credit Cards, purchase orders, money orders, bank checks, and
traveler's checks cannot be accepted.
NAME ________________________________________________
ORGANIZAION ________________________________________
NUMBER OF RESERVATIONS REQUESTED ___________________
Note: Registrations confirmed at http://ietf38.fedex.net/social.html
Received: from ietf.org by ietf.org id aa27641; 11 Mar 97 8:38 EST
Received: from smtpgw.ed.nce.sita.int by ietf.org id aa27594; 11 Mar 97 8:38 EST
Return-Path: <steen.larsen at smtpgw>
Received: from rdsita.rd-sita.fr by smtpgw.ed.nce.sita.int (8.7.5/SitaNet-1.5)
id OAA07676; Tue, 11 Mar 1997 14:33:15 +0100 (MET)
Received: from slarsen.ed.nce.sita.int (pc-edstl.ed.nce.sita.int) by rdsita.rd-sita.fr (5.0/SMI-SVR4)
id AA01428; Tue, 11 Mar 1997 14:34:23 --100
Message-Id: <33255F86.4453 at ed.nce.sita.int>
Date: Tue, 11 Mar 1997 14:35:03 +0100
Sender:ietf-request at ietf.org
From: Steen Larsen <steen.larsen at ed.nce.sita.int>
Reply-To: steen.larsen at ed.nce.sita.int
Organization: SITA R&D Nice
X-Mailer: Mozilla 4.0b2 (Win95; I)
Mime-Version: 1.0
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - MUSE comments
X-Priority: 3 (Normal)
References: <Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd wrote:
Not for any sort of sender-pays that I have proposed. You seem to
be
making the assumption that the sender pays some sort of actual
network
costs in all cases. What you want is to require the sender to pay
whatever the receiver asks, if they want their mail to get through,
with
the receiver being easily able to exempt known correspondents and
mailing
lists and the like.
Yes, we don't want to junk good old SMTP just to deal with spam.
The above is a good idea. We will only read mail that arrives with an
embedded payment.
Our friends will get free personal e-cash for that purpose. Spammers
will have to
enclose real hard-currency e-cash.
Mail without sufficient payment could simply be bounced, the bounce
message
could include e-cash with a statement that it can only be used for
personal e-mail
purposes. If somebody violates that contract, we sue.
If I am willing to read junk-mail for a price then the bounce message
also includes
my required price and payment method for reading spam mail.
Note: The "personal e-cash" could be a simple string/password that lets
mail through.
This string could be copyrighted forbidding its use for spamming
purposes.
I don't claim they are final polished proposals, but what I wish for
is full
implementation and deployment of ubiquitious email security and
optional
charging capabilities along the lines of
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-muse-01.txt> and
<ftp://ftp.isi.edu//internet-drafts/draft-eastlake-internet-payment-02.txt>.
The MUSE document tries to move security/payment functionality from the
user agent to the SMTP servers. I think this is a bad idea. Keeping as
much
functionality in the UA as possible makes it much easier for users to
start using new
features: They don't have to wait for the whole SMTP infrastructure to
be upgraded,
instead they buy a new UA and use it immediately with similar users.
This is why SMTP / RFC 822 has been so successful compared to X.400.
(X.400
tried to put tons of cuntionality into the MTAs)
So please define some RFC 822 headers to contain the payment strings.
Best regards
Steen Larsen
PS. As you said, many different mechanisms may be needed to stop
spam. I do not rule
out that SMTP level payment can be used too. I just think the
other is more important.
--
Steen Koefoed Larsen
SITA R&D Nice, France | @ Home
E-mail: steen.larsen at ed.nce.sita.int | NEW E-mail: steen at who.net
Phone : +33 4 92.96.63.67 | GSM Mobile: +45 40512486
Fax : +33 4 92.96.64.92 | or (French) +33 6 09090568
Disclaimer: This letter may reflect my personal opinion.
*** Syntax? Why not - they tax everything else! ***
Received: from ietf.org by ietf.org id aa27854; 11 Mar 97 8:41 EST
Received: from box.nl by ietf.org id aa27810; 11 Mar 97 8:41 EST
Received: from cs-gj3-a11.hro.nl (cs-gj3-a11.hro.nl [145.24.129.143]) by box.nl (8.7.5/8.6.9) with SMTP id OAA04943 for <ietf at ietf.org>; Tue, 11 Mar 1997 14:38:35 +0100
Date: Tue, 11 Mar 1997 14:38:35 +0100
Message-Id: <199703111338.OAA04943 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
remove
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa02527; 11 Mar 97 10:11 EST
Received: from achilles.ctd.anl.gov by ietf.org id aa02353; 11 Mar 97 10:07 EST
Received: from Raiken.fred.net (raiken.fred.net [205.161.109.24]) by achilles.ctd.anl.gov (8.6.11/8.6.11) with SMTP id JAA02208; Tue, 11 Mar 1997 09:03:20 -0600
Message-Id: <2.2.32.19970311150626.007574d0 at pop3.ctd.anl.gov>
X-Sender: aiken at pop3.ctd.anl.gov
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Mar 1997 10:06:26 -0500
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Bob Aiken <raiken at anl.gov>
Subject: RE: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 01:34 AM 3/11/97 -0500, you wrote:
>Any reasonable system would only collect a payment if the mail is
>accepted.
Accepted by whom? A lot of people use POP and IMAP servers which
"accept" the email for said person at mailgw.dom.dom and its not until
either a user glances at the headers (IMAP) or sucks down the mail
(POP) before the end user can decide if they WANT a message or not.
Is acceptance at the MTA (POP or IMAP servers) or at the UA (Eudora,
MX, ...)?
I agree with Tony Hain in that the sender paying has some major problems -
Unless of course we have the sender DIRECTLY PAY the receiver, i.e. change
the model of sender A paying ISP P to spam anyone on ISPs X,Y, and Z - to
one where
sender A must pay ISP P as well as the receiver of the spam. Just because
spammer A pays ISP P does not give them the right to send me email when I
have no agreement with either ISP P or the spammer. I would think blocking
at my MTA or host is not illegal (although I qualify this statement with the
fact I am not - nor wish to be a lawyer). The Internet is not the US postal
system (Thank god for that) and we shold endeavor to make sure it does not
become one, therefore the fact that the US postal system allows Spammers to
send loads of unsolicited
garbage everyday to many people (and its illegal for the postoffice to
filter - although they do this randomly by loosing mail from time to time)
should not
restrict us from pursuing better ways (i.e., the sender of spam MUST pay me
to accept their SPAM since I pay my IPS etc.) to solve this issue. This
would do wonders in advancing electronic commerce and
cyberbucks/cybergold/cyberchits. Consider sender A sending a mesg to B
saying I am sending you UNSOLICITED garbage and I will pay you x to accept
it- thus paying receiver B (assuming B accepts it - B could also refuse to
accept it).
bob
>
>Donald
>
>On Mon, 10 Mar 1997, Tony Hain wrote:
>
>> Date: Mon, 10 Mar 1997 18:51:17 -0800
>> From: Tony Hain <tonyhain at microsoft.com>
>> To: Martyn Williams <martyn at twics.com>, ietf at ietf.org
>> Subject: RE: call for a new email infrastructure
>>
>> Another 'feature' of sender pays would be legal action if arbitrary
>> blocking (like that done now) is installed. Since the sender has paid
>> for the right it would be more difficult to argue the bits should be
>> blocked or hampered in any way before hitting the destination mail box.
>> This sounds like a box that should be left closed.
>>
>> Tony
>
>=====================================================================
>Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
> 318 Acton Street +1 508-371-7148(fax) dee at world.std.com
>Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
>http://www.cybercash.com http://www.eff.org/blueribbon.html
>
>
>
Robert J. Aiken (Bob), Argonne National Lab,
Network Research Manager, raiken at anl.gov, 301-271-2919
"silence can be a speech"
Received: from ietf.org by ietf.org id aa03174; 11 Mar 97 10:29 EST
Received: from ns1.evcom.net by ietf.org id aa03081; 11 Mar 97 10:27 EST
Received: from eci-1 (eci-1.evcom.net [208.136.203.11]) by ns1.evcom.net (8.8.5/8.6.12) with ESMTP id KAA27569 for <ietf at ietf.org>; Tue, 11 Mar 1997 10:23:56 -0500
Message-Id: <199703111523.KAA27569 at ns1.evcom.net>
Sender:ietf-request at ietf.org
From: Alex <alexa at evcom.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: remove
Date: Tue, 11 Mar 1997 10:21:56 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa04257; 11 Mar 97 10:47 EST
Received: from mailrelay1.csn.net by ietf.org id aa03977; 11 Mar 97 10:43 EST
Received: from [199.117.162.164] (tang.csn.net [199.117.162.164]) by mailrelay.csn.net (8.7.5/8.7.3) with ESMTP id IAA08261; Tue, 11 Mar 1997 08:39:33 -0700
X-Sender: duffy at medusa.csn.net
Message-Id: <l03020904af4b2d2f00d0 at [199.117.162.164]>
In-Reply-To: <2.2.32.19970311150626.007574d0 at pop3.ctd.anl.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Mar 1997 08:44:12 -0700
To: Bob Aiken <raiken at anl.gov>
Sender:ietf-request at ietf.org
From: Rick Duffy <duffy at sni.net>
Subject: RE: call for a new email infrastructure
Cc: "Donald E. Eastlake 3rd" <dee at cybercash.com>, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 10:06 AM -0500 3/11/97, Bob Aiken wrote:
>At 01:34 AM 3/11/97 -0500, you wrote:
>>Any reasonable system would only collect a payment if the mail is
>>accepted.
>
>Accepted by whom? A lot of people use POP and IMAP servers which
>"accept" the email for said person at mailgw.dom.dom and its not until
>either a user glances at the headers (IMAP) or sucks down the mail
>(POP) before the end user can decide if they WANT a message or not.
>Is acceptance at the MTA (POP or IMAP servers) or at the UA (Eudora,
>MX, ...)?
>
>I agree with Tony Hain in that the sender paying has some major problems -
>Unless of course we have the sender DIRECTLY PAY the receiver, i.e. change
>the model of sender A paying ISP P to spam anyone on ISPs X,Y, and Z - to
>one where
>sender A must pay ISP P as well as the receiver of the spam. Just because
>spammer A pays ISP P does not give them the right to send me email when I
>have no agreement with either ISP P or the spammer. I would think blocking
>at my MTA or host is not illegal (although I qualify this statement with the
>fact I am not - nor wish to be a lawyer). The Internet is not the US postal
>system (Thank god for that) and we shold endeavor to make sure it does not
>become one, therefore the fact that the US postal system allows Spammers to
>send loads of unsolicited
>garbage everyday to many people (and its illegal for the postoffice to
>filter - although they do this randomly by loosing mail from time to time)
>should not
>restrict us from pursuing better ways (i.e., the sender of spam MUST pay me
>to accept their SPAM since I pay my IPS etc.) to solve this issue. This
>would do wonders in advancing electronic commerce and
>cyberbucks/cybergold/cyberchits. Consider sender A sending a mesg to B
>saying I am sending you UNSOLICITED garbage and I will pay you x to accept
>it- thus paying receiver B (assuming B accepts it - B could also refuse to
>accept it).
If email of this type had to be clearly identified as such (probably by some
new protocol), wouldn't it be fairly easy to incorporate an automated method
of simply accepting all spam email, and trashing it immediately, and collect
the chits? If so, then this method would not be looked on favorably by the
senders, and so would encourage them to not play along.
... Rick
Received: from ietf.org by ietf.org id aa06079; 11 Mar 97 11:19 EST
Received: from deliverator.io.com by ietf.org id aa05837; 11 Mar 97 11:14 EST
Received: from hollerith.io.com (hollerith.io.com [199.170.88.21])
by deliverator.io.com (8.8.5/8.8.5) with ESMTP id JAA06184;
Tue, 11 Mar 1997 09:15:40 -0600 (CST)
Received: from loopback (dialup-01-127.austin.io.com [199.170.89.127]) by hollerith.io.com (8.8.5/8.6.12) with SMTP id JAA24340; Tue, 11 Mar 1997 09:15:36 -0600 (CST)
Date: Tue, 11 Mar 1997 09:16:18 -0600 (CST)
Sender:ietf-request at ietf.org
From: John Harvey <johnbob at io.com>
X-Sender: johnbob at loopback
To: Steen Larsen <steen.larsen at ed.nce.sita.int>
cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - Not needed
In-Reply-To: <3325566B.EA8 at ed.nce.sita.int>
Message-ID: <Pine.A32.3.95.970311090035.16818A-100000 at loopback>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 11 Mar 1997, Steen Larsen wrote:
> MIME has this already. It is also common to use e-mail with HTML where
> the main content
> is retrieved by following a URL.
Yes, the mechanism exists with MIME. But there is no policy that all must
use it.
I'm trying to find a way that the basic mail system requires accurate
identification of the source. Some way that a junkmail message body never
leaves the source except to people who want it. Some way that the initial
unsolicited part of the message is a small as possible, contains no
text (not even a subject line) and can be used for filtering.
I understand why people don't want to change or give up SMTP. Would
anyone be opposed to having SMTP and a new system coexist?
-john
John Harvey Email advertisers: put me on your "don't call, don't email" list.
home: johnbob at io. com http://www .io. com/~johnbob/
X-No-Archive: Yes
Received: from ietf.org by ietf.org id aa07365; 11 Mar 97 11:51 EST
Received: from mailhost2.cac.washington.edu by ietf.org id aa06926;
11 Mar 97 11:45 EST
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
by mailhost2.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP
id IAA02256; Tue, 11 Mar 1997 08:43:01 -0800
Date: Tue, 11 Mar 1997 08:40:37 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: RE: call for a new email infrastructure
To: Tony Hain <tonyhain at microsoft.com>
cc: Martyn Williams <martyn at twics.com>, ietf at ietf.org
In-Reply-To: <2120C028D567CF11BB8700805FD4CC4C01E6B2EE at RED-11-MSG.dns.microsoft.com>
Message-ID: <MailManager.858098437.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 10 Mar 1997 18:51:17 -0800, Tony Hain wrote:
> Another 'feature' of sender pays would be legal action if arbitrary
> blocking (like that done now) is installed. Since the sender has paid
> for the right it would be more difficult to argue the bits should be
> blocked or hampered in any way before hitting the destination mail box.
I will happily accept advertising from any sender who pays me $1 per message.
Received: from ietf.org by ietf.org id aa08749; 11 Mar 97 12:22 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa08227; 11 Mar 97 12:11 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id MAA16758;
Tue, 11 Mar 1997 12:08:42 -0500
Message-Id: <199703111708.MAA16758 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: John Harvey <johnbob at io.com>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure - Not needed
In-Reply-To: Your message of "Tue, 11 Mar 1997 09:16:18 CST."
<Pine.A32.3.95.970311090035.16818A-100000 at loopback>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <Pine.A32.3.95.970311090035.16818A-100000 at loopback>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-2014313000P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Mar 1997 12:08:41 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-2014313000P
Content-Type: text/plain; charset=us-ascii
On Tue, 11 Mar 1997 09:16:18 CST, John Harvey said:
> unsolicited part of the message is a small as possible, contains no
> text (not even a subject line) and can be used for filtering.
The biggest problem with the "only send a URL" scheme is that you have just
effectively made it impossible to send e-mail from a site that is behind a
firewall, or is dialup and not always connected. Also, some people pay
by-the-minute for connect time - if it's a small note (such as this one), the
actual message can be downloaded in 2-3 seconds over even a 14.4 modem, but if
you actually want to *read* the note, you then have to go through another HTTP
connection (or whatever), and possibly incur a 2-3 *minute* wait if the remote
server isn't able to respond, or the network is down, etc. Now, if you get 60
messages from a mailing list, instead of having to wait (and pay for) 3-4
minutes of "air time", you might be looking at an *hour*.
Think of being put on "hold" while using a cellular phone. Multiple times. ;)
Also, the less you include in the "wrapper", the *less* filtering you can do.
I happen to do a *LOT* of filtering based on the Subject: field, and even some
filtering based on the body...
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-2014313000P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMyWRltQBOOoptg9JAQGo+AQAmH0KYwJv6S2DRPJtXwPqGKiZrCKOLh+G
kYeOKvbmLUv83bVMOuTbfZukr+bXq17xpq73u/PeDlNitMFZIKLtKOGxcLOv87gV
SpVoJT7gwAAKMNX4+ReIU5paTUKpg7zCS3HQfdlefPOrUkNA2YpAr+8xVBrwKAEx
AMU9cWHMevw=
=4mht
-----END PGP MESSAGE-----
--==_Exmh_-2014313000P--
Received: from ietf.org by ietf.org id aa08773; 11 Mar 97 12:22 EST
Received: from mailhost1.cac.washington.edu by ietf.org id aa08529;
11 Mar 97 12:20 EST
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP
id JAA01099; Tue, 11 Mar 1997 09:16:53 -0800
Date: Tue, 11 Mar 1997 09:15:41 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: Re: call for a new email infrastructure
To: Valdis.Kletnieks at vt.edu
cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
In-Reply-To: <199703111709.MAA16794 at black-ice.cc.vt.edu>
Message-ID: <MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 11 Mar 1997 12:08:56 -0500, Valdis.Kletnieks at vt.edu wrote:
> I might be dense, but who will pay for the IETF mailing list under this
> model?
In the model that I envision, the act of subscribing to a mailing list would
constitute agreement to waive charges.
Received: from ietf.org by ietf.org id aa08775; 11 Mar 97 12:23 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa08362; 11 Mar 97 12:14 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id MAA16794;
Tue, 11 Mar 1997 12:09:00 -0500
Message-Id: <199703111709.MAA16794 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Mark Crispin <MRC at panda.com>
Cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Mon, 10 Mar 1997 14:03:54 PST."
<MailManager.858031434.366.mrc at Ikkoku-Kan.Panda.COM>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <MailManager.858031434.366.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1332013890P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Mar 1997 12:08:56 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1332013890P
Content-Type: text/plain; charset=us-ascii
On Mon, 10 Mar 1997 14:03:54 PST, Mark Crispin said:
> But, more importantly, it's doubtful that the spammers would want their mail
> to be stamped with "bulk mail" postage, given that it would then be trivial
> for sites to toss out all bulk mail unconditionally.
I might be dense, but who will pay for the IETF mailing list under this model?
This is *not* a facetious question. I'm the postmaster of a system that runs
well over 700 different mailing lists, anywhere from 250K to 500K outbound
postings a day (we have one 4,000+ subscriber list that gets hit by up to 100
postings a day all by itself). In such a scenario, who pays?
Does the person who posted the original notice pay for all the deliveries? If
so, how does he control costs? I have *NO* idea how many IETF subscribers
there are - especially considering sub-exploders behind firewalls and the like.
If the person says "don't spend more than $0.75 US for this posting", what
happens when the money runs out? Note that you probably do *NOT* want to
enable before-posting checking of the estimated cost, for 2 reasons: (a)
simple performance and (b) it provides a nice covert channel for spammers to
evaluate high price-performance lists for their spamming..
A quick check of yesterday's SMTP logs for our Listserv machine reveals a total
of 211,800 connections, to 6,173 different hostnames. Aggregating by
second-level domain names only reduces it to 3,496 different ones (note that
this counts *everything* under 'co.uk' or 'com.au' as one site....)
Now, let's examine the implications of this. Like many organizations, Virginia
Tech has to be careful who and how we enter into contractual obligations with
(in particular, our beancounters don't like it when we get invoiced by people
we haven't sent a purchase order or other agreement in advance). We are *NOT*
going to be able to negotiate the equivalent of the X.400 PRMD/ADMD stuff with
6,000+ different remote sites, nor are we going to be able to actually settle
up with 6,000+ other sites.
The other alternative (massive interchanges that will do all that for you)
appears to be a non-starter as well. There's a scaling problem here - by the
time you narrow it down to some number X interchanges small enough that each
member of X is able to negotiate (X-1) interconnection agreements, each one has
to be able to handle 1/X'th of the *entire* Internet mail load. Ask the
people at AOL what it's like to try to handle 1/10th (or whatever it is)
of the Internet ;)
We have enough trouble building a IP routing interconnect that just swaps
packets back and forth. Imagine what would happen to MAE-East if it had
to do packet counting, message counting, message recipient filtering,
and chargebacks and settlements.....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_1332013890P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMyWRptQBOOoptg9JAQH3VwP/b4CYFRbMlRq2m6hC3sCqsUy+/aF4OCvD
oKua6WiGQrRsad2vPqWoJpGlpXNfP0LSPESk9mSFlSySWCjKYXk3Mo8UtlOKjXOL
f7Pl4koRk9Fn8t9ZoboDa45134eGiUkH1Igm85r04f5AT4zEMXYCu3c9QQjAl4Ks
XjYHZudytwU=
=AnRF
-----END PGP MESSAGE-----
--==_Exmh_1332013890P--
Received: from ietf.org by ietf.org id aa11085; 11 Mar 97 13:08 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa10797; 11 Mar 97 13:05 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id NAA18342;
Tue, 11 Mar 1997 13:01:24 -0500
Message-Id: <199703111801.NAA18342 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Mark Crispin <MRC at panda.com>
Cc: mailcost-l at listserv.vt.edu, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Tue, 11 Mar 1997 09:15:41 PST."
<MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1337506282P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Mar 1997 13:01:24 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_1337506282P
Content-Type: text/plain; charset=us-ascii
(Administrivia - I've set up a Listserv mailing list called
'mailcost-l at listserv.vt.edu' for further discussion on this. Send e-mail
to 'listserv at listserv.vt.edu' with "subscribe mailcost-l Your Name" to
subscribe. You will have to reply to an "OK' magic cookie to finish
the subscription process).
On Tue, 11 Mar 1997 09:15:41 PST, Mark Crispin said:
> In the model that I envision, the act of subscribing to a mailing list would
> constitute agreement to waive charges.
Umm.. an agreement by *whom*? If one of my users subscribes to a mailing
list, who will pay for that mail? And for that matter, who is paying whom
for person-to-person mail? Does the sender himself pay? Does the
sender's provider pay the receiver's provider, and then charge the sender?
And more importantly, how does the receiving provider "know" that an incoming
mail is a "list" posting? Does the subscriber have to do it through the
provider (careful here - think privacy considerations)? If not, how does
the receiving provider know it is "real" list mail as opposed to a spam list?
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_1337506282P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMyWd8tQBOOoptg9JAQHLHgP+M11seg0+KuVaAriQ5cbnx5BZl/KiZWta
twC/piODGOgWy8PrKoJs0P+L2pqfmU/sq2or1uSk2eL+IwimEPUTKVkMPXr3yG3B
1WoEnHPeAp/7c/6Dnje2GeoI4qE0hYm0ymzGcQYlInru9p/geMs9/kKMAKYComnd
2OIJmIJesBY=
=lPSz
-----END PGP MESSAGE-----
--==_Exmh_1337506282P--
Received: from ietf.org by ietf.org id aa12330; 11 Mar 97 13:36 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa12257;
11 Mar 97 13:34 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA03583; Tue, 11 Mar 97 13:31:28 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA23330; Tue, 11 Mar 1997 13:31:22 -0500
Date: Tue, 11 Mar 1997 13:31:22 -0500
Message-Id: <9703111831.AA23330 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Mark Crispin <MRC at panda.com>
Cc: Valdis.Kletnieks at vt.edu, Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
In-Reply-To: Mark Crispin's message of Tue, 11 Mar 1997 09:15:41 -0800 (PST),
<MailManager.858100541.5225.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Subject: Re: call for a new email infrastructure
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Tue, 11 Mar 1997 09:15:41 -0800 (PST)
From: Mark Crispin <MRC at panda.com>
In the model that I envision, the act of subscribing to a mailing list would
constitute agreement to waive charges.
Ok, so how do you prevent spammers from spamming mailing lists?
One possible solution: Only allow people who are on the mailing list to
send to the mailing list. (Problems with lists that have exploders, for
people who read mailing lists via news, etc.)
A further problem: What if spammers subscribe to the mailing list, and
then send a spam?
One possible solution: Make each person sign an agreement before they
join that they won't do this. (Problems of what's legally binding, what
the sanctions are if they violate the agreement, etc.)
Moral of the story: There are no easy answers.....
- Ted
Received: from ietf.org by ietf.org id aa14636; 11 Mar 97 14:40 EST
Received: from quackerjack.cc.vt.edu by ietf.org id aa14536; 11 Mar 97 14:36 EST
Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30])
by quackerjack.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id OAA28995; Tue, 11 Mar 1997 14:33:50 -0500 (EST)
Received: from [128.173.12.232] (sears.cns.vt.edu [128.173.12.232])
by sable.cc.vt.edu (8.8.4/8.8.4) with SMTP
id OAA20251; Tue, 11 Mar 1997 14:33:50 -0500 (EST)
X-Sender: sears at mail.vt.edu
Message-Id: <v02140b03af4b62662a9c at [128.173.12.232]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 Mar 1997 14:34:24 -0500
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Sender:ietf-request at ietf.org
From: pris sears <sears at vt.edu>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
> Date: Tue, 11 Mar 1997 09:15:41 -0800 (PST)
> From: Mark Crispin <MRC at panda.com>
>
> In the model that I envision, the act of subscribing to a mailing list would
> constitute agreement to waive charges.
>
>Ok, so how do you prevent spammers from spamming mailing lists?
>
>One possible solution: Only allow people who are on the mailing list to
>send to the mailing list. (Problems with lists that have exploders, for
>people who read mailing lists via news, etc.)
yes, and use a confirmation system, ie, user sends subscribe request,
listserv sends confirmation which must be replied to to complete
subscription. this weeds out subs from fake addresses, and jokers
subscribing for someone else, as we have seen happen lately.
>A further problem: What if spammers subscribe to the mailing list, and
>then send a spam?
boot 'em off the list asap and put them on a blacklist. when the sub.
confirmation goes out, it should specifically say that offtopic/commercial
mail is prohibited and grounds for being booted permanently from the list.
i hate spam, but the only spam that really bothers me is what comes from
faked addresses and domains and cannot be traced to the sender or a
postmaster. i wouldn't mind a system where mail servers look up from
addresses to make sure they are real and dump the mail before sending to
users if they are faked. if i get spam, i can deal with it myself as long
as i can get to the person that sent it (or their isp).
postmasters sharing blacklists and denying mail by domain from serious
offenders can also be very effective. i expect mail from spamford's new
domain to be universally bit-bucketed before i ever have to look at any of
it :)
_____________________________________________________________
Thanks for your kind attention - I'm outta here!
Pris Sears | sears at vt.edu | http://sears.cns.vt.edu/ | 231-2305
Received: from ietf.org by ietf.org id aa15766; 11 Mar 97 15:06 EST
Received: from ns1.BayNetworks.COM by ietf.org id aa15583; 11 Mar 97 15:05 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id LAA25852; Tue, 11 Mar 1997 11:59:30 -0800 (PST)
for <ietf at ietf.org>
Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP
id MAA25383; Tue, 11 Mar 1997 12:02:22 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:02:22 -0800 (PST)
Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102])
by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id MAA24162; Tue, 11 Mar 1997 12:02:18 -0800
for <ietf at ietf.org>
Received: from java-pc (java-pc.engwest.baynetworks.com [134.177.115.78])
by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529
ID# 0-13459) with SMTP id AAA27232 for <ietf at ietf.org>;
Tue, 11 Mar 1997 12:02:17 -0800
Message-Id: <3.0.32.19970311120109.00921b30 at sc-mail2.corpwest.baynetworks.com>
X-Sender: tlavian at sc-mail2.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 12:01:10 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Tal Lavian <Tal_Lavian at baynetworks.com>
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa16058; 11 Mar 97 15:10 EST
Received: from egoshin.genesyslab.com by ietf.org id aa15950;
11 Mar 97 15:09 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id MAA08534; Tue, 11 Mar 1997 12:07:45 -0800
Date: Tue, 11 Mar 1997 12:07:45 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703112007.MAA08534 at egoshin.genesyslab.com>
To: sears at vt.edu, tytso at mit.edu
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: pris sears <sears at vt.edu>
>>A further problem: What if spammers subscribe to the mailing list, and
>>then send a spam?
>
>boot 'em off the list asap and put them on a blacklist. when the sub.
>confirmation goes out, it should specifically say that offtopic/commercial
>mail is prohibited and grounds for being booted permanently from the list.
Yet additional problem - somebody do it as YOU. Of course, decision
is E-sign. But this decision draw another problem - we are need to maintain
multiple secret keys for multiple mail-lists etc. Do you want this deal
in connection with E-mail lists ? I am not...
More over that could you do with export restrictions on this way (just now) ?
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa16091; 11 Mar 97 15:10 EST
Received: from ns1.BayNetworks.COM by ietf.org id aa16002; 11 Mar 97 15:09 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost2.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id MAA25993; Tue, 11 Mar 1997 12:04:01 -0800 (PST)
for <ietf at ietf.org>
Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP
id MAA00138; Tue, 11 Mar 1997 12:06:52 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:06:52 -0800 (PST)
Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102])
by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id MAA24559; Tue, 11 Mar 1997 12:06:52 -0800
for <ietf at ietf.org>
Received: from java-pc (java-pc.engwest.baynetworks.com [134.177.115.78])
by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529
ID# 0-13459) with SMTP id AAA27862 for <ietf at ietf.org>;
Tue, 11 Mar 1997 12:06:50 -0800
Message-Id: <3.0.32.19970311120542.00949660 at sc-mail2.corpwest.baynetworks.com>
X-Sender: tlavian at sc-mail2.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 12:05:43 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Tal Lavian <Tal_Lavian at baynetworks.com>
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
Received: from ietf.org by ietf.org id aa16142; 11 Mar 97 15:11 EST
Received: from ns3.BayNetworks.COM by ietf.org id aa15779; 11 Mar 97 15:06 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost1.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id MAA19640; Tue, 11 Mar 1997 12:03:44 -0800 (PST)
for <ietf at ietf.org>
Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP
id MAA29950; Tue, 11 Mar 1997 12:03:35 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:03:35 -0800 (PST)
Received: from sc-mail2.corpwest.BayNetworks.com (sc-mail2-hme0.corpwest.baynetworks.com [134.177.64.102])
by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP
id MAA24249; Tue, 11 Mar 1997 12:03:35 -0800
for <ietf at ietf.org>
Received: from java-pc (java-pc.engwest.baynetworks.com [134.177.115.78])
by sc-mail2.corpwest.BayNetworks.com (post.office MTA v2.0 0529
ID# 0-13459) with SMTP id AAA27384 for <ietf at ietf.org>;
Tue, 11 Mar 1997 12:03:34 -0800
Message-Id: <3.0.32.19970311120227.00921b30 at sc-mail2.corpwest.baynetworks.com>
X-Sender: tlavian at sc-mail2.corpwest.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 12:02:27 +0000
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Tal Lavian <Tal_Lavian at baynetworks.com>
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove Tal Lavian <Tal_Lavian at sc-mail2.corpwest.baynetworks.com>
Received: from cnri by ietf.org id aa16317; 11 Mar 97 15:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17007;
11 Mar 97 15:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA11684 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 18:25:15 GMT
Message-Id: <3325A2EA.69D7 at dascom.com>
Date: Tue, 11 Mar 1997 10:22:34 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: cat-ietf at mit.edu
Subject: Re: GSSAPI and SSL?
References: <Roam 0.9.4.858052094.26887.mre at jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Yes. That is an interesting approach. And is somewhat similiar to the
proposal from the SSL community to incorporate DCE/Kerberos suites into
SSL. But I was actually thinking of a more straightforward layering
that *would* maintain the SSL protocol on the wire for interoperability
purposes. That way I have a GSSAPI based application that can either
speak DCE or SSL - as the customer desires.
Basically, I'm just trying to get a handle on how much activity and
interest there is in GSSAPI these days. It seems like all the attention
is focused on SSL now and I should migrate my app over to that.
But then again, I keep hearing references to SSL problems wrt to
scaling, single point of failure, and susceptibility to attacks such as
replay.
- John
Mike Eisler wrote:
>
> > Is anyone looking into (or have done) integration of SSL under the
> > GSSAPI?
> > Is there any interest in the GSSAPI community in this?
> > Or do you view these things as virtually interchangeable (i.e. solves
> > the same problem)?
> > Does this even make any sense?
>
> I've had similar thoughts. One could create a GSS-API mechanism that mimiced
> SSL's CipherSuites as QOP values (using the same numerical values). And one
> could also mimic SSL's CipherSuite negotiation during the
> GSS_Init_sec_context/GSS_Accept_sec_context handshake.
>
> The value in this would be in simplifying the deployment of protocols that use
> GSS-API security into operating environments that favor SSL (for example web
> browsers). While the result would NOT be the SSL protocol, it would be
> security equivalent to what SSL delivers. Presumably, if the operating
> environment has modularized the SSL layer appropriately, the GSS-SSL
> mechanism could share code with the SSL protocol's API:
>
> internal SSL-api GSS-API
> | |
> ssl-protocol engine gss-ssl-mech
> \ /
> ssl-crypto-code
>
> -
>
> Mike Eisler
> SunSoft, Inc.
> mre at Eng.Sun.Com
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa17225; 11 Mar 97 15:27 EST
Received: from ns3.BayNetworks.COM by ietf.org id aa17038; 11 Mar 97 15:25 EST
Received: from ns1.BayNetworks.COM ([134.177.1.107])
by mailhost1.BayNetworks.COM (8.8.5/BNET-96/12/06-E) with ESMTP
id MAA20305; Tue, 11 Mar 1997 12:22:18 -0800 (PST)
for <ietf at ietf.org>
Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17])
by ns1.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with SMTP
id MAA01249; Tue, 11 Mar 1997 12:22:12 -0800 (PST)
for <ietf at ietf.org>
Posted-Date: Tue, 11 Mar 1997 12:22:12 -0800 (PST)
Received: from jgarcia.corpeast.baynetworks.com ([192.32.108.105]) by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1)
id AA14465; Tue, 11 Mar 97 15:22:12 EST
Message-Id: <3.0.32.19970311142141.006dff54 at bl-mail2.corpeast.baynetworks.com>
X-Sender: jgarcia at bl-mail2.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 11 Mar 1997 14:21:42 -0600
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Jorge Garcia <jgarcia at baynetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa18285; 11 Mar 97 15:38 EST
Received: from MAILBOX.ADM.RL.AF.MIL by ietf.org id aa18197; 11 Mar 97 15:36 EST
Received: from SHAGGY.C3D.RL.AF.MIL (SHAGGY.C3D.RL.AF.MIL [128.132.39.57]) by mailbox.adm.rl.af.mil (8.8.5/8.7.6) with SMTP id PAA20586; Tue, 11 Mar 1997 15:33:06 -0500 (EST)
Received: by SHAGGY.C3D.RL.AF.MIL with Microsoft Mail
id <01BC2E31.7E5D7320 at SHAGGY.C3D.RL.AF.MIL>; Tue, 11 Mar 1997 15:32:56 -0500
Message-ID: <01BC2E31.7E5D7320 at SHAGGY.C3D.RL.AF.MIL>
Sender:ietf-request at ietf.org
From: "C.J. Maciag" <maciagc at rl.af.mil>
To: "Theodore Y. Ts'o" <tytso at mit.edu>, 'pris sears' <sears at vt.edu>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: call for a new email infrastructure
Date: Tue, 11 Mar 1997 15:32:55 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
>A further problem: What if spammers subscribe to the mailing list, and
>then send a spam?
>boot 'em off the list asap and put them on a blacklist...
Ahhh... A great idea. But where would we put such a blacklist? And how do we prevent
would-be spammers from adding legitimate users to the blacklist and cause denial-of-service
to legitimate subscribers. To say that only ISPs are allowed to access the list would
be shortsighted, as the operation of this (the IETF exploder) illustrates.
>i hate spam, but the only spam that really bothers me is what comes from
>faked addresses and domains and cannot be traced to the sender or a
>postmaster. i wouldn't mind a system where mail servers look up from
>addresses to make sure they are real and dump the mail before sending to
>users if they are faked. if i get spam, i can deal with it myself as long
>as i can get to the person that sent it (or their isp).
This I like even better. We have the ability to do a DNS lookup on users of other services
(e.g. Web access), why not build in this feature to mail exploders (and other post office
devices) to reject SMTP/X.400 packets from illegitimate users? I think this enhancement
could be handled with only minor modifications to the local mail server, and not to the
SMTP/X.400 protocol.
Chet
_______________________________________________________
Chester J. Maciag
Network Security Engineer
US Air Force Rome Laboratory
525 Brooks Rd, Rome NY 13441-4505
DSN 587 (315) 330-1875
maciagc at rl.af.mil
"The network itself has become a theater of operation"
Received: from ietf.org by ietf.org id aa21213; 11 Mar 97 16:15 EST
Received: from gdansk.Berkeley.EDU by ietf.org id aa21126; 11 Mar 97 16:13 EST
Received: by gdansk. (SMI-8.6/SMI-SVR4)
id NAA14923; Tue, 11 Mar 1997 13:12:15 -0800
Date: Tue, 11 Mar 1997 13:12:15 -0800
Sender:ietf-request at ietf.org
From: cclee at gdansk
Message-Id: <199703112112.NAA14923 at gdansk.>
To: ietf at ietf.org
Subject: remove
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: YfVq8ZG93T9hKQ7T7uaYzA==
Source-Info: From (or Sender) name not authenticated.
please remove cclee at gdansk.berkeley.edu
Received: from ietf.org by ietf.org id aa21522; 11 Mar 97 16:24 EST
Received: from egoshin.genesyslab.com by ietf.org id aa21466;
11 Mar 97 16:23 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id NAA08805; Tue, 11 Mar 1997 13:21:18 -0800
Date: Tue, 11 Mar 1997 13:21:18 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703112121.NAA08805 at egoshin.genesyslab.com>
To: Claudio.Allocchio at elettra.trieste.it, ietf at ietf.org
Subject: re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
Here is some scetch of proposal on authentificated mail transfer.
(Unfortunately I can't attend Memphys IETF, sorry)
Advantage of it is coexistence with current SMTP.
- Leonid Yegoshin, LY22
Main flow of authentification of mail transfering.
A. TCP/IP protocol changes.
1) Sender use some additional SMTP command to setup authentification.
(alternative: use another TCP port)
2) Receiver check host address in "MAIL FROM" of SMTP to match IP address of
sender. If correct - OK, next phase. If not - check IP (DNS ?) address of
sender in trusted mail gateways list (which support authentificated mail
transfer).
3) If address was not correct - reject mail permanent.
4) Next phase: after receiving mail body receiver insert in headers some line
identified receiver itself (like Received, but with more strong syntax).
And replace some another predefined line to show authentificated
reception.
X) During non-authentificated SMTP - delete predefined line to show
non-authentificated SMTP.
B. Human procedures to support trusted authentificated E-mail gateway
infrastructure (can be changed by Internet community, of course)
1) If you receive E-mail which don't corresponent sender address via
authentificated protocol send it back to nearest gateway and wait
explanation. After receiving it/not receiving it - decide do you
want to leave this nearest gateway in trusted list.
2) If you are a trusted gateway maintainer and receive E-mail about problem
with authentification - check correctness of E-mail passed gateway
in receiver identified line (it can have crypted time/hope count).
If it correct - check previous gateway in trusted gateway list and
ask him. After receiving explanation/not receiving - decide do you
want to leave this gateway in trusted list and answer originator of
request.
3) E-mail list holder is or is NOT trusted gateway and can send E-mail
with "MAIL FROM" equal its own host address. But E-mail list holder
can check authentification and reproduce it during delivery.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa22772; 11 Mar 97 16:50 EST
Received: from spheara.io360.com by ietf.org id aa22539; 11 Mar 97 16:47 EST
Received: (from stevek at localhost) by spheara.io360.com (8.7.6/8.6.10-io360) id QAA11036; Tue, 11 Mar 1997 16:44:15 -0500 (EST)
Message-ID: <Mutt.19970311164415.stevek at spheara.io360.com>
Date: Tue, 11 Mar 1997 16:44:15 -0500
Sender:ietf-request at ietf.org
From: Steve Kann <stevek at stevek.com>
To: Tal Lavian <Tal_Lavian at baynetworks.com>
Cc: ietf at ietf.org
Subject: Re: remove
References: <3.0.32.19970311120542.00949660 at sc-mail2.corpwest.baynetworks.com>
X-Mailer: Mutt 0.58.1
Mime-Version: 1.0
X-Blank-Header-Line: (this header intentionally left blank)
Source-Info: From (or Sender) name not authenticated.
Tal Lavian writes:
> remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
You know, Mr Lavian, that behaviour such as posting "remove" messages to
a list that has (probably) reaches thousands of the most influential
internet professionals does not look good for your company.
One wonders if this is their example of netiquette in this public forum,
then what kinds of net-unfriendly things do their routers do behind the
scenes when no one knows?
-SteveK
--
Steve Kann i/o 360 digital design 841 Broadway, Suite 502
PGP 1024/C0145E05 F2 D6 24 83 9E 52 9A 61 AA BB 97 61 5C A1 B8 CE
Personal:stevek at SteveK.COM Business: stevek at io360.com
Received: from ietf.org by ietf.org id aa23022; 11 Mar 97 16:53 EST
Received: from rover.cygnus.com by ietf.org id aa22811; 11 Mar 97 16:51 EST
Received: (from marc at localhost) by rover.cygnus.com (8.7.6/8.6.12) id QAA28102; Tue, 11 Mar 1997 16:48:56 -0500 (EST)
To: ietf at ietf.org
Subject: removing yourself
Sender:ietf-request at ietf.org
From: Marc Horowitz <marc at cygnus.com>
Date: 11 Mar 1997 16:48:55 -0500
Message-ID: <t53g1y2t7zs.fsf at rover.cygnus.com>
Lines: 17
X-Mailer: Gnus v5.3/Emacs 19.34
Source-Info: From (or Sender) name not authenticated.
let's try this again.
sending mail to the entire list doesn't get you off. instead, it
makes you look ignorant. To quote from
http://www.ietf.org/mailinglists.html:
To join the IETF general discussion list, send a request to:
ietf-request at ietf.org and enter the word subscribe in the Subject line
of the message.
To unsubscribe, send a request as described above but containing
unsubscribe in the Subject line. Note: do not attempt to subscribe or
unsubscribe by sending mail directly to the lists themselves -- this
will not result in the desired action but will irritate thousands of
list subscribers.
Marc
Received: from ietf.org by ietf.org id aa23253; 11 Mar 97 16:58 EST
Received: from www.atr.net by ietf.org id aa23048; 11 Mar 97 16:54 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id ja000347 for <ietf at ietf.org>; Tue, 11 Mar 1997 16:51:42 +0000
Message-ID: <3325D3ED.7007 at atr.net>
Date: Tue, 11 Mar 1997 16:51:41 -0500
Sender:ietf-request at ietf.org
From: Turner W Rentz III <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advance Technology and research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: Leonid Yegoshin <egoshin at genesyslab.com>
CC: ietf at ietf.org
Subject: Re: call for a new email infrastructure
References: <199703112007.MAA08534 at egoshin.genesyslab.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at warp.atr.net
Source-Info: From (or Sender) name not authenticated.
Leonid Yegoshin wrote:
> Yet additional problem - somebody do it as YOU. Of course, decision
> is E-sign. But this decision draw another problem - we are need to maintain
> multiple secret keys for multiple mail-lists etc. Do you want this deal
> in connection with E-mail lists ? I am not...
> More over that could you do with export restrictions on this (the) way
Someone once told me the Russian Language conjugates the noun, so in
this context, the english is readable.
First -
1. Authentication
- This means that it comes from you
2. Certification
- This means that it comes from you,
and you make sure that it gets to whom
you want to send it.
Export restrictions will prohibit RSA keys greater than 40 bits.
It is my understanding that key length will go up soon.
--
T. Rentz, III "The Internet is the Garden of Eden."
Software Engineer
http://www.atr.net/people/treyr
Received: from ietf.org by ietf.org id aa23254; 11 Mar 97 16:58 EST
Received: from newra.src.umd.edu by ietf.org id aa23137; 11 Mar 97 16:56 EST
Received: from volt.isr.umd.edu (volt.isr.umd.edu [128.8.111.165])
by newra.src.umd.edu (8.8.5/8.8.5) with SMTP id QAA21362
for <ietf at ietf.org>; Tue, 11 Mar 1997 16:51:47 -0500 (EST)
X-Orig-Sender: mayssat at newra.src.umd.edu
Message-ID: <3325D3F2.167EB0E7 at isr.umd.edu>
Date: Tue, 11 Mar 1997 16:51:46 -0500
Sender:ietf-request at ietf.org
From: Mayssat Robert <mayssat at isr.umd.edu>
X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.4 sun4m)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: remove
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa23252; 11 Mar 97 16:58 EST
Received: from notes.technicalpeople.com by ietf.org id aa23138;
11 Mar 97 16:56 EST
Received: by tpi_notes.technicalpeople.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BC2E34.2A8AD550 at tpi_notes.technicalpeople.com>; Tue, 11 Mar 1997 15:52:04 -0600
Message-ID: <c=US%a=_%p=TPI%l=TPI_NOTES-970311215202Z-316 at tpi_notes.technicalpeople.com>
Sender:ietf-request at ietf.org
From: Kyle Hendricksen <KyleH at technicalpeople.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject:
Date: Tue, 11 Mar 1997 15:52:02 -0600
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Encoding: 1 TEXT
Source-Info: From (or Sender) name not authenticated.
remove
Received: from ietf.org by ietf.org id aa23523; 11 Mar 97 17:00 EST
Received: from cannon.ecf.toronto.edu by ietf.org id aa23455;
11 Mar 97 16:59 EST
Received: by cannon.ecf.toronto.edu id <10411>; Tue, 11 Mar 1997 16:56:45 -0500
Sender:ietf-request at ietf.org
From: ARJANGPOUR SOURENA <arjangp at ecf.toronto.edu>
To: ietf at ietf.org
Subject: remove
Message-Id: <97Mar11.165645edt.10411 at cannon.ecf.toronto.edu>
Date: Tue, 11 Mar 1997 16:56:43 -0500
Source-Info: From (or Sender) name not authenticated.
please remove arjangp at ecf.toronto.edu
Received: from ietf.org by ietf.org id aa24934; 11 Mar 97 17:18 EST
Received: from asic.sec.samsung.co.kr by ietf.org id aa24886;
11 Mar 97 17:17 EST
Received: from shc.sec.samsung.co.kr ([168.219.203.8]) by asic.sec.samsung.co.kr (8.6.12h2/8.6.9) with SMTP id HAA07681 for <ietf at ietf.org>; Wed, 12 Mar 1997 07:07:01 +0900
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: shc <shchung at asic.sec.samsung.co.kr>
Subject: remove
Message-Id: SHCHUNGe6xrsz0*SHCHUNGe6xrt10*2
Date: 12 Mar 97 07:17:27
X-Priority: 3 (Normal)
X-GWSamsung-Value: 1
X-GWSamsung-StatusMsg: 0
X-GWSamsung-Trace: 1
X-GWSamsung-MsgID: SHCHUNGe6xrsz0*SHCHUNGe6xrt10*2
X-GWSamsung-PassCount: 0
X-GWSamsung-TraceInet: 1
X-GWSamsung-OrigAddress: ietf at ietf.org
X-Mailer: "Groupware E-Mail". Version 1.02.050
Mime-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
[Mailer: "Groupware E-Mail". Version 1.02.050]
please remove shchung at asic.sec.samsung.co.kr
-------------------------------------------------------------------=
--
SUNG-HYUN CHUNG
ASIC CENTER, CTO, SUWON COMPLEX
Tel) 82-331-200-3420 Fax) 82-331-200-3122
E-mail) shchung at asic.sec.samsung.co.kr
-------------------------------------------------------------------=
--=
Received: from cnri by ietf.org id aa27118; 11 Mar 97 17:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21202;
11 Mar 97 17:56 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA17856 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 20:52:58 GMT
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: johnn at dascom.com, cat-ietf at mit.edu
Subject: Re: GSSAPI and SSL?
References: <Roam 0.9.4.858052094.26887.mre at jurassic.eng.sun.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 11 Mar 1997 15:52:38 -0500
In-Reply-To: Mike Eisler's message of Mon, 10 Mar 1997 19:48:14 -0800 (PST)
Message-Id: <t53lo7utall.fsf at rover.cygnus.com>
Lines: 51
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Mike Eisler <Michael.Eisler at eng.sun.com> writes:
>> I've had similar thoughts. One could create a GSS-API mechanism
>> that mimiced SSL's CipherSuites as QOP values (using the same
>> numerical values). And one could also mimic SSL's CipherSuite
>> negotiation during the GSS_Init_sec_context/GSS_Accept_sec_context
>> handshake.
>>
>> The value in this would be in simplifying the deployment of
>> protocols that use GSS-API security into operating environments
>> that favor SSL (for example web browsers). While the result would
>> NOT be the SSL protocol, it would be security equivalent to what
>> SSL delivers. Presumably, if the operating environment has
>> modularized the SSL layer appropriately, the GSS-SSL mechanism
>> could share code with the SSL protocol's API:
>>
>>
>> internal SSL-api GSS-API
>> | |
>> ssl-protocol engine gss-ssl-mech
>> \ /
>> ssl-crypto-code
I've had similar thoughts to Mike's but I'd splice it in somewhat
differently. SSL has two advantages. From an application author's
point of view, you have a sockets-like api which implements a secure
channel. From a security point of view, you have a deployed key
infrastructure (which is somewhat fragmented and incomplete, but
between netscape, verisign, and RSA, it's getting somewhere):
internal ssl api
|
x.509 + sockets
I would add gssapi in there as a cryptosuite:
internal ssl (tls) api
|
(gssapi, x.509) + sockets
|
x.509-ssl, kerberos, spkm, whatever
This would let new and old ssl apps continue to work together. A pair
of new ssl apps could use any gssapi mechanism instead of x.509
certificates. Also, apps which didn't want to use ssl could still
take advantage of the key management infrastructure (mainly the
widely-known commercial CA's) growing up around SSL.
Adding gssapi here would be very similar to Ari's kerberos draft.
Marc
Received: from ietf.org by ietf.org id aa27989; 11 Mar 97 18:07 EST
Received: from atlas.xylogics.com by ietf.org id aa27759; 11 Mar 97 18:04 EST
Received: from huey.xylogics.com (huey.xylogics.com [132.245.32.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id SAA06099; Tue, 11 Mar 1997 18:00:48 -0500 (EST)
Received: by huey.xylogics.com id AA16863 (4.1/UK-doug-951219);
Tue, 11 Mar 97 18:00:48 EST
Sender:ietf-request at ietf.org
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Tue, 11 Mar 97 18:00:48 EST
Message-Id: <16863.9703112300 at huey.xylogics.com>
To: stevek at stevek.com
Cc: Tal_Lavian at baynetworks.com, ietf at ietf.org
In-Reply-To: Steve Kann's message of Tue, 11 Mar 1997 16:44:15 -0500 <Mutt.19970311164415.stevek at spheara.io360.com>
Subject: remove
Source-Info: From (or Sender) name not authenticated.
Sorry Steve, but I feel compelled to defend my company. Lots of
idiots unsubscribe to the main list and nobody ever blames their
company for that. No company is populated entirely by wisened
network guru's and every company has its share of idiots. Just
look at the rash of unsubscribes which follow every message
telling people how to unsubscribe properly.
Don't forget that your message (OK, and this one) could be
considered spam too!
> You know, Mr Lavian, that behaviour such as posting "remove" messages to
> a list that has (probably) reaches thousands of the most influential
> internet professionals does not look good for your company.
>
> One wonders if this is their example of netiquette in this public forum,
> then what kinds of net-unfriendly things do their routers do behind the
> scenes when no one knows?
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(508) 916-4237 Pick two!
Received: from ietf.org by ietf.org id aa29387; 11 Mar 97 18:20 EST
Received: from noc.msc.edu by ietf.org id aa29286; 11 Mar 97 18:18 EST
Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
id AA12914; Tue, 11 Mar 97 17:15:56 -0600
Sender:ietf-request at ietf.org
From: Tim Salo <salo at msc.edu>
Received: (salo at localhost) by uh.msc.edu (8.7.1/8.6.6) id RAA23372; Tue, 11 Mar 1997 17:15:56 -0600 (CST)
Date: Tue, 11 Mar 1997 17:15:56 -0600 (CST)
Message-Id: <199703112315.RAA23372 at uh.msc.edu>
To: Tal_Lavian at baynetworks.com, stevek at stevek.com
Subject: Re: remove
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
> Date: Tue, 11 Mar 1997 16:44:15 -0500
> From: Steve Kann <stevek at stevek.com>
> To: Tal Lavian <Tal_Lavian at baynetworks.com>
> Cc: ietf at ietf.org
> Subject: Re: remove
>
> Tal Lavian writes:
> > remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
>
> You know, Mr Lavian, that behaviour such as posting "remove" messages to
> a list that has (probably) reaches thousands of the most influential
> internet professionals does not look good for your company.
If this were a rare event, one might be justified in suspecting pilot error.
However, given the fairly regular rate at which "remove" messages are
submitted to this mail list, (followed by a bunch of "don't do that"
messages), one should probably dig a bit deeper for an explanation.
Perhaps, the "thousands of the most influential internet professionals"
ought to be a bit embarrassed at having developed technology which is
repeatedly demonstrated to have such poor usability characteristics.
Only half in jest,
-tjs
Received: from cnri by ietf.org id aa00883; 11 Mar 97 18:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22173;
11 Mar 97 18:41 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA19564 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 21:33:15 GMT
Message-Id: <3325CF7F.3EF6 at trsvr.tr.unisys.com>
Date: Tue, 11 Mar 1997 16:32:47 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
Subject: SSL underneath GSS-API/SSPI (again)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
There has been some interesting discussion over the last few days, on
both ssl-talk and cat-ietf, on the subject of putting SSL underneath
GSS-API. Opinions were all over the map: =94yes, you could do that, but
why would you want to?=94 - =94we tried it, but we had to make a lot of
assumptions in SSL and it wasn't useful=94 - =94we really want to decoupl=
e
our applications from the underlying mechanism=94.
In Microsoft's Security Design review (Sept 96), they presented an
architectural picture with SSL sitting alongside Kerberos (and NTLM and
other mechanisms) underneath GSS-API (or rather, Microsoft's SSPI
equivalent). Yet Eric Murray tells us he's already tried that and it was
essentially a failure.
I'd be very interested in hearing Microsoft comment on Eric's
experience, and for them to tell us how things are going with the
SSL-under-SSPI development.
Meanwhile, my own view is that it makes little sense to impose
mechanism-specific APIs on applications. There is a lot of benefit to
having an API that runs over multiple mechanisms. (And yes, I'm aware of
the idealized view that applications should call DCOM or RPC, and the
mechanism interface is below that - but there are many situations
(probably mostly legacy c/s interactions) where that model won't work.)
It seems to me that there are, in general, two interfaces needed for the
average GSS mechanism - one for applications, one for management. The
management API is used to set policy, and therefore must be
mechanism-specific (for example, such policy issues would be, in SSL,
cipher-suite/QoS mappings, key exchange mechanism, and any other
mechanism-specific aspect of behavior that most applications would not
want to have to bother with).
I'm somewhat surprised by how little traffic this topic has generated.
To me, it looks like a real disaster if GSS apps currently using
Kerberos have to be rewritten to some ad hoc interface on top of SSL,
(or whatever the next mechanism is) rather than have the new mechanisms
sit underneath the old interface.
BTW, if anyone wants a summary of messages on this thread to date, I
collected most of them at
http://www.chesco.com/~buffam/Security/Articles/gss-ssl.txt
--=20
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa03867; 11 Mar 97 19:37 EST
Received: from quackerjack.cc.vt.edu by ietf.org id aa03786; 11 Mar 97 19:35 EST
Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30])
by quackerjack.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id TAA09011 for <ietf at ietf.org>; Tue, 11 Mar 1997 19:32:24 -0500 (EST)
Received: from [128.173.34.111] (as5200-1.sl037.cns.vt.edu [128.173.34.111])
by sable.cc.vt.edu (8.8.4/8.8.4) with SMTP
id TAA30969 for <ietf at ietf.org>; Tue, 11 Mar 1997 19:32:22 -0500 (EST)
Date: Tue, 11 Mar 1997 19:32:22 -0500 (EST)
X-Sender: sears at mail.vt.edu
Message-Id: <v01540b0211084bfa6fb2 at [128.173.34.111]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: pris sears <sears at vt.edu>
Subject: Re: all these 'remove's
Source-Info: From (or Sender) name not authenticated.
I think sending personal email to help the hapless soul that wants to be
removed would be more effective than sending instructions to the list - the
general list already knows how, and the spammed-out user trying to get off
the list probably is just deleting everything from it and not seeing those
unsub instructions sent to the list.
This list seems to be the victim of someone stealing email addresses and
forging subscriptions for other people, maybe it is time to start saving
subscribe requests and checking headers to see if it is all coming from one
place, and/or implement a reply-required subscription?
Here's my boilerplate to send to the individual when I see unsubs on this list:
-------
some joker must have signed you up to the ietf list -
here is how to get off the list, taken from this web page:
http://www.ietf.org/mailinglists.html:
To join the IETF general discussion list, send a request to:
ietf-request at ietf.org and enter the word subscribe in the Subject line
of the message.
Substitute unsubscribe in the above instructions to leave the list. Note:
do not attempt to subscribe or unsubscribe by sending mail directly to the
lists themselves.
good luck!
------
Might also change the subject line to something catchy like "How to get off
the list!"
---------------------------------------------------
pris sears*http://128.173.12.232/*sears at vt.edu*
Received: from cnri by ietf.org id aa04338; 11 Mar 97 19:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23183;
11 Mar 97 19:48 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA22974 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 22:51:00 GMT
Date: Tue, 11 Mar 1997 16:50:47 -0600
Message-Id: <199703112250.QAA27942 at pembroke.ctd.anl.gov>
From: Doug Engert <DEEngert at anl.gov>
To: cat-ietf at mit.edu
Cc: authtf at es.net
Subject: Usage of the Kerberos 5 Transited Field
Precedence: bulk
I have a concern about the use of the Transited field of the
Kerberos 5 ticket. "draft-ietf-cat-kerberos-pk-cross-00.txt" and
"draft-ietf-cat-kerberos-pk-init-02.txt" both propose to add the names
of the certifiers in the certification path to the transited field of
the ticket. This is all well and good, but imposes additions
problems on current implementations.
RFC-1510 states in section 1.1: "...the hierarchical organization
allows an authentication path to be easily constructed. If a
hierarchical organization is not used, it may be necessary to consult
some database to construct an authentication path between realms."
And it also states: "It is important for the end-service to
know which realms were transited when deciding how much faith to place
in the authentication process". Thus the end-service will enforce some
policy based on its knowledge of which realms should be listed in the
transited field.
Most implementations of Kerberos use a default hierarchy defined by
the realm names of the client and end-service. This is used by the
client to obtain the necessary tickets, and is used by the
end-service to define the policy to be used for checking for an acceptable
authentication.
Here are my concerns:
o RFC-1510 does not state how a hierarchy is to be generated, and
there are a number of ways to do this. Most kerberos implementations
use the client and end-service realm names, and parse them in DNS
style. OSF/DCE uses the client and end-service realm names, but uses a
different separator character, and parses in the other direction. Thus
both are within the RFC specifications, but cross-realm authentication
is possible only when the two realms share an inter-realm
key. i.e. the transited field is null, and there is no problem with
determining the hierarchy between the two realms.
o When "pk-cross" and/or "pk-init" are implemented, most current
implementations of Kerberos will fail to function unless they are
modified to recognize a new policy, and not rely on the hierarchy
based on the realm names. In fact, even when the client and
end-service are with in the same realm, the transited field may
contain an entry if "pk-init" was used, and current end-services may
not accept this.
o RFC-1510 implies that the end-service should check the transited
field. But in most implementations, the intermediate TGSs also check
the transited field. When using the hierarchical approach this is
trivial, since it is easy to generate the same hierarchy from the
client and end-service realm names. But if "pk-init" and/or "pk-cross"
add additional entries to the transited filed, then each intermediate
KDC must know what policies are valid between the client and end-service.
o RFC-1510 does not require a TGS to check the transited field, it
only says an end-service should.
Here is what I would like to see changed:
o RFC-1510 or "pk-init" state that a TGS will always check the
transited field against the realm's policy before issuing a ticket
for an end-service in its realm.
This relieves the end service of having to check the policy itself if
it is willing to live with the realm's policy, although it is still
free to check it. This will simplify the the end-service processing,
and maintenance of any policy information which is now localized to the
TGSs.
This also says the the TGS does not need to check the transited field
when issuing a ticket for another realm. The only tickets issued for
another realm are for the other realm's TGS when doing cross-realm
authentication. This relieves the intermediate realm's TGS of having
to know (and enforce) the policy of the end-service's realm. It is
still free to do so, but unless the policy database is kept up to
date, it might interfere in some situations.
o The KRB_TGS_REP message be extended to allow for the client's TGS
to return, in addition to a ticket for the "closest" realm, an
authentication path which should be used to obtain the tickets to get
to the end-service's realm. (See RFC-1510 Section 3.3.3.)
Without this, either the client has to (1) rely on a hierarchy path
model of authentication, (2) maintain a configurable authentication
path table, or (3) rely on each of the intermediate TGS's to know the
path to the end-service's realm.
(1) Has the problem as stated above that different implementations of
kerberos have implemented the notion of a hierarchy differently. (2)
Has the maintenance problem of having this table on the client. (3)
Has the problem of the intermediate TGS's having to know the path to
the end-server's TGS.
Conclusion
The MIT Kerberos V5-1.0 release has the configurable authentication
path code which implements non-hierarchical authentication paths which
can be used to solve the above problems, but it suffers from a
maintenance view-point, and requires intermediate realms to also
maintain the authentication paths to all the other realms.
These two changes as outlined above, remove the responsibility of the
client, end-service and intermediate TGS's of having to know or to
check authentication paths. They place the responsibility on the
client's TGS to supply the path to the end-service's realm, and for
the end-service's TGS to check the authentication path. The changes
also streamline the processing, reduce the maintenance and allow for
the handling of the additional information being proposed by "pk-init"
and "pk-cross".
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Received: from ietf.org by ietf.org id aa05475; 11 Mar 97 20:23 EST
Received: from skyweyr.com by ietf.org id aa05325; 11 Mar 97 20:20 EST
Received: from [128.2.98.8] (SEUSS.RES.CMU.EDU [128.2.98.8])
by skyweyr.com (8.8.4/8.8.4) with ESMTP
id RAA12522 for <ietf at ietf.org>; Tue, 11 Mar 1997 17:17:32 -0800 (PST)
X-Sender: josh at grinch.res.cmu.edu
Message-Id: <v0302092daf4bb18e8bd7 at [128.2.98.8]>
In-Reply-To: <199703112315.RAA23372 at uh.msc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-URL: http://thelorax.skyweyr.com/josh.html
X-Planation: My mountain is waiting...
Date: Tue, 11 Mar 1997 20:06:47 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Joshua D. Baer" <josh at skyweyr.com>
Subject: Stopping "remove" messages (was "Re: remove")
Source-Info: From (or Sender) name not authenticated.
At 6:15 PM -0500 3/11/97, Tim Salo wrote:
> Perhaps, the "thousands of the most influential internet professionals"
> ought to be a bit embarrassed at having developed technology which is
> repeatedly demonstrated to have such poor usability characteristics.
If it makes anyone feel better, we're currently working on an Internet
draft for a set of headers to make this less common. The hope is to enable
client software to provide useful UI's for handling list mail. More
discussion is taking place on the List Headers Mail List:
<URL:mailto:list-header at arpp.carleton.ca?subject=subscribe>
Feel free to join in!
~Josh
-- ----------------------------------
Joshua D. Baer
SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login
Received: from cnri by ietf.org id aa06497; 11 Mar 97 20:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24104;
11 Mar 97 20:51 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA25447 at pad-thai.cam.ov.com>; Tue, 11 Mar 1997 23:50:36 GMT
Message-Id: <3325EF0E.F42 at dascom.com>
Date: Tue, 11 Mar 1997 15:47:26 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSSAPI and SSL?
References: <Roam 0.9.4.858108835.28738.mre at jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mike -
Thank you for the informative and helpful response.
I guess I am just demonstrating my ignorance of both GSS-API and SSL. I
had assumed from my casual investigation that GSS-API was ("just") an
API and that it was fully intended for developers to provide specific
mechanisms (such as Kerberos and SSL) underneath. Further, I'd thought
that the tokens were completely opaque to the application and were
mechanism specific - i.e. it is the role of the specific mechanism to
determine how the authentication/integrity/privacy gets implemented, as
SSL does.
I've also gathered from related postings that Microsoft is attempting
something similiar - i.e. a GSS-API w/ SSL and Kerberos and other things
underneath. I suppose I'll need to track what's going on with that
side. Does the MS GSS-API (SSI) have any resemblance to GSS-API?
Anybody got a spare pointer?
I'm also not sure what SASL is that you refer to?
Judging from the excellent summation of the discussion so far Bill
Buffman made, I suspect I'm not the only one suffering from confusion on
this point.
Thanks, John
*************
Mike Eisler wrote:
>
>
> The philosophy of GSS-API is that it creates tokens that the application
> has the freedom to package and transport between network peers as it
> wishes. SSL on the other hand specifies how the transport of signed and/or
> encrypted data works. So any layering you produce has to reconcile the
> two different philosophies. Effectively, you'd have to design a uniform
> protocol for how GSS-API tokens get transported, and also extend your
> application's protocol to switch among GSS-API, SSL, and no security:
>
> generic security layer
> / \
> SSL protocol for encapsulating GSS-API
> | | \
> | | GSS-API
> | |
> --------------------------------------------------------------------
> application protocol (with extensions for switching
> between SSL, GSS-API encapsulation,
> and no security).
>
> I haven't looked at SASL, but I suspect SASL would work as a way to extend
> most application protocols to switch among security frameworks. Alternatively,
> one could do something like the extensions to FTP for adding GSS-API and SSL.
> Your mileage will vary depending on the application protocol.
>
> The above looks sufficiently cumbersome (I know of at least one attempt to
> make it work that was abandoned) to make me want to have my application
> protocols use either just SSL (so in your case, take a look at the ID for
> adding Kerberos V5 to SSL), or GSS-API. Alternatively, wait for IPSEC. I
> think Dan McDonald of SunSoft (danmcd at Eng.Sun.Com) has put together, or is in
> the process of putting together some IDs (for the Informational track) for an
> API to IPSEC.
>
> For my application, ONC RPC, I picked GSS-API (see
> draft-ietf-oncrpc-rpcsec_gss-02.txt), simply because RPC already had support
> for encapsulating security parameters and I saw little need to use SSL's
> (politics isn't a good reason to do something redundant). And IPSEC
> authentication doesn't work well with RPC. If I need SSL security, I'll use a
> GSS-SSL mechanism or an equivalent. Personally, I see RPC as the preferred way
> to create new secure protocols that don't want to wait for IPSEC or can't use
> IPSEC, but obviously I have a bias (note affiliation below).
>
> As to the activity around GSS-API, there's quite a bit. For example, I have in
> my hand a white paper from Microsoft that details their use of GSS-API under
> NT 5.0.
>
> -Mike Eisler
> Solaris NFS Group, SunSoft, Inc.
> mre at Eng.Sun.Com
>
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa07060; 11 Mar 97 21:17 EST
Received: from external2.oc.com by ietf.org id aa07002; 11 Mar 97 21:16 EST
Received: from ocs2437.oc.com (d215-120.oc.com [192.82.215.120]) by oc.com (8.8.4/8.7.5) with SMTP id UAA10635; Tue, 11 Mar 1997 20:12:42 -0600 (CST)
Message-Id: <3.0.1.32.19970311201302.00e88668 at mailhost.oc.com>
X-Sender: cvg at mailhost.oc.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 11 Mar 1997 20:13:02 -0600
To: Tim Salo <salo at msc.edu>, Tal_Lavian at baynetworks.com, stevek at stevek.com
Sender:ietf-request at ietf.org
From: Cleve Graves <cvg at oc.com>
Subject: Re: remove
Cc: ietf at ietf.org
In-Reply-To: <199703112315.RAA23372 at uh.msc.edu>
Mime-Version: 1.0
Content-Type: text/enriched; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
As one of many list member 'lurkers' who don't post here often, but read
these discussions with great interest, I would like to suggest that Tal
is very likely correct in his view. I read the recent thread
<underline>"REMOVE" function</underline> with interest, smiles and
ultimately disappointment. Here we are supposed to be leaders in the
Internet community, and we can't take a simple action suggestion at face
value and implement it. OK! we are supposed to discuss it, but shouldn't
we DO SOMETHING when we get through discussing it?
I am very proud of the tremendous success we have achieved with the
Internet and it's technologies, but I think we need to recognize the
success has brought with it a greater responsibility for us. We've
spoken of the "Internet toaster" in the past on this list (many IPV*
threads) and we have succeeded to the point where Internet appliances ARE
being sold today at Sears, and family electronics stores everywhere
(WEBTV) with more to come. =20
What I feel we "leaders" need to do is raise our sights and recognize
that we got what we wanted, and accept the responsibility for making the
World Wide utility, which has something for EVERYONE, and more of these
users are joining us everyday. We must begin to assume and know that
MOST users today are not technical! AND it is those users we courted and
set about to attract when we started making the Internet. I feel we can
no longer approach user interface and usability issues with RTFM (read
the freakin' manual) responses. When we ignore the clear fact that our
users ARE GOING TO SEND REMOVE AND UNSUBSCRIBE messages to the list,
making those message work to actually get them off the list (and
subscribe them, too!) seems the be a clear "got to be done" sooner or
later REALITY! What has amazed me is that as leaders, we continue to
take the "later" approach.
Of all the discussion I re-read about this issue there seems to be two
general areas the discussions to fall into. One area is give them more
technology to use (we can't help it we are technology people).=20
Unfortunately these ideas all seem to boil down to give them new things
to read like appends and URL/headers (more RTFM) and when you know that
the guy with his remote on a webtv box will be one of those people trying
to get off.... HE AIN'T GONNA READ NOTHIN'!
The other area of discussion was about why we CAN'T just make the remove
message work! Actually, on closer review the discussion were about why
we couldn't make it work PERFECTLY! (another technical person trait
perfectionism). And if we can't make it work perfectly, then obviously
we should not do it. This too amazes me because I've NEVER gotten a
program that work perfectly the first time! As a technical person, I
expect BUGS, and know that as problems arise they will be addressed and
things will get better. ALL PROGRAMS WORK THIS WAY! In our
business(technology) we always ship a wine(programs) before its time! IN
FACT WE MUST... it is the only way to find out how REAL PEOPLE will use
what we create, then we make it work. The really successful programs are
the ones, which work the way the real users tell the programmers it
should work. In our case the REAL PEOPLE out there have sent us a clear
"how-it-should-work" message. If I send you a message saying to REMOVE
me, then take me of the list! Don't send the message to everyone and
don't expect me to RTFM, and don't expect that I'll read your flippin'
mail (RYFM) about how to do it right either.
So why don't we put a "remove/unsubscribe" filter in, monitor what it
takes out and doesn't take out, correct problems, and make out listserver
a model for what to expect a listserver to do now that we have Internet
toaster and "toaster USERS". And let us not forget that USER always has
been and always will be a four letter word.... Thank god, for what would
we be doing without them? =20
=09
Thanks for the many hours of great reading....
Cleve Graves
----------------------------------------------------
Off the router, onto the bridge, down
the firewall, nothin' but 'Net!!
----------------------------------------------------
At 05:15 PM 3/11/97 -0600, Tim Salo wrote:
>> Date: Tue, 11 Mar 1997 16:44:15 -0500
>> From: Steve Kann <<stevek at stevek.com>
>> To: Tal Lavian <<Tal_Lavian at baynetworks.com>
>> Cc: ietf at ietf.org
>> Subject: Re: remove
>>=20
>> Tal Lavian writes:
>> > remove Tal_Lavian at sc-mail2.corpwest.baynetworks.com
>>=20
>> You know, Mr Lavian, that behaviour such as posting "remove" messages
to
>> a list that has (probably) reaches thousands of the most influential
>> internet professionals does not look good for your company.
>
>If this were a rare event, one might be justified in suspecting pilot
error.
>However, given the fairly regular rate at which "remove" messages are
>submitted to this mail list, (followed by a bunch of "don't do that"
>messages), one should probably dig a bit deeper for an explanation.
>
>Perhaps, the "thousands of the most influential internet=20
professionals"
>ought to be a bit embarrassed at having developed technology which is
>repeatedly demonstrated to have such poor usability characteristics.
>
>Only half in jest,
>
> -tjs
>
Thanks,
----------------------------------------------------
Off the router, onto the bridge, down
the firewall, nothin' but 'Net!!
----------------------------------------------------
Cleve
Received: from cnri by ietf.org id aa10161; 11 Mar 97 22:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25704;
11 Mar 97 22:41 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <CAA00454 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 02:08:18 GMT
Message-Id: <640796DB4262D0118D3300805FD4EFCF93DC3B at RED-32-MSG.dns.microsoft.com>
From: Peter Brundrett <petebr at microsoft.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>
Subject: Optimistic snego
Date: Tue, 11 Mar 1997 17:53:40 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
I realize this is late in the review cycle for the snego-02 draft, but
would like to suggest the following proposal which may be of general
interest.
The requirement is to add support in the snego protocol that takes
advantage of an optimistic negotiation outcome. For many environments,
the preferred mechanism will be configured the same on both initiator
and target systems. Negotiation is still important in those
environments beacuse the negotiation mechanism list supports interaction
with services used less frequently that require a different mechanism,
perhaps from an older platform.
We would like to add an optional attribute to the negTokenReq for
environments where initiator and target are likely to be configured to
have the same preferential order of multiple security mechanisms. The
initiator should have the option of providing the initial security token
for the preferred mechanism piggybacked with the list of supported
mechanisms. The preferred mechanism is the first item in the mechanism
list.
The primary advantage of including the initial security token of the
preferred mechanism is that if the target preferred mechanism matches
the initiators preferred mechanism, no additional roundtrips are
incurred by using the negotiation protocol. Adding the initial security
token takes advantage of an optimistic outcome of the negotiation
without reducing security.
The initial security token from the desired mechanism of the initiator
is included in the negTokenRep.
Specific changes to the negotiation token in Section 4.2
MechType ::= OBJECT IDENTIFIER
MechTypeList ::= SEQUENCE OF MechType
NegTokenReq ::= SEQUENCE {
mechTypes[0] MechTypeList,
desiredToken[1] OCTET STRING OPTIONAL
}
The desiredToken is an optional field in the request that all target
implementations would not have to support. However for those targets
that do support piggybacking the initial desiredToken, an optimistic
negotiation response is also possible.
The negotiation procedure described in section 3.2 would add the
following optional behavior [in brackets]:
b) the initiator GSS-API implementation emits a negotion token
containing the set of supported security mechanism for the credentials
used for this context establishment, [and optionally the initial
security token for the preferred mechanism,] and indicates
GSS_CONTINUE_NEEDED status;
d) The GSS-API target deposits the token through invoking
GSS_Accept_sec_context. The target GSS-API implementation emits a
negotiation token containing which if any of the proposed mechanisms it
supports (or has selected).
[
If the preferred mechanism selected by the target matches the preferred
mechanism identified by the initiator and the initiator provides a
desiredToken, the target also deposits the desiredToken as the initial
token to GSS_Accept_sec_context for that mechanism. If the specific
mechanism GSS_Accept_sec_context is successful, the negotiation token
response contains the initial security token from that mechanism;
]
Section 5 provides examples of Security negotiation mechanism. The
additional subsection describes negotiation with initial context info.
5.4 Successful Negotiation with preferred mechanism info
(I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2),
and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2-
OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2.
(I) invokes GSS_Init_sec_context() with :
Input
mech_type = OID for negotiation mechanism or NULL, if the
negotiation mechanism is the default mechanism.
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenReq
The negotiation token (negTokenReq) contains three security mechanisms
with :
mechType = GSS-MECH1 or
mechType = GSS-MECH2-OPTION1 or
mechType = GSS-MECH2-OPTION2
desiredToken = output_token from GSS_Init_sec_context( first
mechType) as described in [1]
(I) sends to (T) the negotiation token.
(T) supports GSS-MECH1.
(T) receives the negotiation token (negTokenReq) from (I)
(T) invokes GSS_Accept_sec_context() with :
Input
input_token = negTokenReq
Output
major_status = GSS_CONTINUE_NEEDED
output_token = negTokenRep
The negotiation token (negTokenRep) contains :
negResult = accept (the negotiation result)
supportedMech : mechType = GSS-MECH1
MechSpecInfo = output_token from GSS_Accept_sec_context(
desiredToken )
(T) returns the negotiation token (negTokenRep) to (I)
(I) invokes GSS_Init_sec_context() with :
Input
input_token = negTokenRep
Output
major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed
output_token = initialContextToken (initial context token
for GSS-MECH1)
mech_type = GSS-MECH1
Specific implementations of the protocol can support the optimistic
negotiation by completing the security context establishment using the
agreed upon mechanism as described in [1].
Received: from ietf.org by ietf.org id aa18410; 12 Mar 97 3:31 EST
Received: from otherguy.gte.net by ietf.org id aa18274; 12 Mar 97 3:24 EST
Received: from dfw73150.gte.net (dfw73150.gte.net [206.124.73.150]) by smtp.gte.net (SMI-8.6/) via SMTP id CAA04285; Wed, 12 Mar 1997 02:18:03 -0600
Received: by dfw73150.gte.net with Microsoft Mail
id <01BC2E89.EFAC6060 at dfw73150.gte.net>; Wed, 12 Mar 1997 02:06:02 -0600
Message-ID: <01BC2E89.EFAC6060 at dfw73150.gte.net>
Sender:ietf-request at ietf.org
From: Stu McClure <smcclure at gte.net>
To: Keith Moore <moore at cs.utk.edu>,
'Andre Correa' <andre at tucows.alphanet.com.br>
Cc: Kent Crispin <kent at songbird.com>, "MRC at panda.com" <MRC at panda.com>,
"ietf at ietf.org" <ietf at ietf.org>
Subject: RE: call for a new email infrastructure
Date: Tue, 11 Mar 1997 22:41:59 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Andre,
I am one of the original members of the U.S. Defense Department TCP/IP =
Application development teams from the 1970's.
Your comments demonstrate a refreshing bit of common sense and =
innocence that reminds me of our brainstorming and design sessions when =
we created this infrastructure in the first place.
Thanks for your wisdom and your contribution. I hope they listen.
Stu McClure...
----------
From: Andre Correa
Sent: Tuesday, March 11, 1997 7:00 AM
To: Keith Moore
Cc: Kent Crispin; MRC at panda.com; ietf at ietf.org
Subject: Re: call for a new email infrastructure=20
Hello, I have no idea how this mails from IETF came to me, anyway
I have an opinion about it all: (and it is good to be here)
I use and work with Internet for 3 years and I received a little
number of unwanted mails, maybe, I am a luck guy, but I dont want to pay =
to send or to receive mails, I want it to stay the way it is. Why dont
create this service of "mesage center" for those who want to have their
mails filtred, this guys will pay for the service of filtering their
e-mail...
Other thing, what we will gonna do with the large mailling lists??
Who will pay to send this mails for tousands of users??
My way looks better for me. Till now the Internet was a free field
and must continue this way!!! We must find and make something realy =
strong
and definitive with the bombers and guys that send unwanted mails.
Anyway this is just my opinion...
[]s.
<Andre>
Received: from ietf.org by ietf.org id aa22186; 12 Mar 97 7:51 EST
Received: from fxiod04.is.chrysler.com by ietf.org id aa21968;
12 Mar 97 7:48 EST
Received: by fxiod04.is.chrysler.com; id AA09699; Wed, 12 Mar 97 07:45:53 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1)
id xma009685; Wed, 12 Mar 97 07:45:45 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10946; Wed, 12 Mar 1997 07:30:27 -0500 (EST)
Message-Id: <3.0.1.32.19970312072522.009a9100 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:25:22 -0500
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>,
Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
In-Reply-To: <Pine.SUN.3.91.970311013555.7676F-100000 at cybercash.com>
References: <199703110620.BAA08638 at ig.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 01:56 AM 3/11/97 -0500, Donald E. Eastlake 3rd wrote:
>
>You are making a lot of unwarranted assumptions about there being a poor
>user interface. You should also note that many spammers leave out .edu,
>.gov, and some other TLDs. So you are behind the poor people in .com for
>general spam volume.
Not to bring the evil eye....
I get 2-4 spams a day in a 400-500 message a day environment. I tend to
get more unsubscribe and the like than spams. But then, I don't use USENET.
As the cost of connectivity goes down, and access speeds go up, and UAs
improve, SPAM will move to a minor problem. Most SPAMs stay in my in box,
having failed my filters. Typically, 15 messages a day stay in my in box.
Thus SPAMs are easy to pitch manually. I have thought of adding a delete
filter for the text 'SPAM' in the subject, but then I would miss all of the
'lets kill SPAM messages' :) Of course this thread was carefully
subjected to avoid such filters....
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa22184; 12 Mar 97 7:51 EST
Received: from fxiod05.is.chrysler.com by ietf.org id aa21999;
12 Mar 97 7:48 EST
Received: by fxiod05.is.chrysler.com; id AA05817; Wed, 12 Mar 97 07:46:04 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1)
id xma005805; Wed, 12 Mar 97 07:45:45 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10948; Wed, 12 Mar 1997 07:30:27 -0500 (EST)
Message-Id: <3.0.1.32.19970312072809.00afeb30 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:28:09 -0500
To: John Harvey <johnbob at io.com>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure
In-Reply-To: <Pine.A32.3.95.970311010201.18204A-100000 at loopback>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 01:28 AM 3/11/97 -0600, John Harvey wrote:
>
>Perhaps we could develop a fetch based email system. Instead of sending
>out the body of the message itself send a message id and a location from
>which to fetch it.
...
>For mailing lists (that you subscribe to,
>like ietf) the message id and location could be forwarded instead of the
>body so that it can be fetched from the originator.
Never work for large lists. This means if I post to a large list, my
server on the end of a V.34 dedicated link (htt-consult.com) would be hit a
few thousand times for the fetch.
Yet another good idea that really makes basic functionality function worst.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa22187; 12 Mar 97 7:51 EST
Received: from fxiod05.is.chrysler.com by ietf.org id aa21998;
12 Mar 97 7:48 EST
Received: by fxiod05.is.chrysler.com; id AA05812; Wed, 12 Mar 97 07:46:04 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1)
id xma005804; Wed, 12 Mar 97 07:45:44 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10944; Wed, 12 Mar 1997 07:30:26 -0500 (EST)
Message-Id: <3.0.1.32.19970312071805.009b2170 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:18:05 -0500
To: Keith Moore <moore at cs.utk.edu>,
"Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org, moore at cs.utk.edu
In-Reply-To: <199703110620.BAA08638 at ig.cs.utk.edu>
References: <Your message of "Mon, 10 Mar 1997 18:37:07 EST." <Pine.SUN.3.91.970310171505.28778G-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 01:20 AM 3/11/97 -0500, Keith Moore wrote:
>
>The cure is worse than the disease.
The disease is societal. If you want to participate in public discussions
and/or have a publically findable email address, you will receive spam, no
matter what the mail payment process.
I have colleagues that have private PO boxes for business only mail.
Nothing comes to them but pre-established business communications. I have
managers here that we have schooled not to post to any public descussion
area, and we do not put there addresses up in any directory.
We have more important issues to solve. Deploying authenticated mail
systems for its real value (business communications) is a critical step.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa22185; 12 Mar 97 7:51 EST
Received: from fxiod04.is.chrysler.com by ietf.org id aa21983;
12 Mar 97 7:48 EST
Received: by fxiod04.is.chrysler.com; id AA09695; Wed, 12 Mar 97 07:45:53 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1)
id xma009686; Wed, 12 Mar 97 07:45:46 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA10950; Wed, 12 Mar 1997 07:30:28 -0500 (EST)
Message-Id: <3.0.1.32.19970312073710.009aa150 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 12 Mar 1997 07:37:10 -0500
To: John Harvey <johnbob at io.com>,
Steen Larsen <steen.larsen at ed.nce.sita.int>
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: call for a new email infrastructure - Not needed
Cc: ietf at ietf.org
In-Reply-To: <Pine.A32.3.95.970311090035.16818A-100000 at loopback>
References: <3325566B.EA8 at ed.nce.sita.int>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 09:16 AM 3/11/97 -0600, John Harvey wrote:
>Yes, the mechanism exists with MIME. But there is no policy that all must
>use it.
>I'm trying to find a way that the basic mail system requires accurate
>identification of the source. Some way that a junkmail message body never
>leaves the source except to people who want it. Some way that the initial
Multipart/Signed and/or S/MIME. We have already defined how to do it and
products are starting to trickle out.
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa26845; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26530; 12 Mar 97 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-kerb-chg-password-00.txt
Date: Wed, 12 Mar 1997 09:26:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26530 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : Kerberos Change Password Protocol
Author(s) : M. Horowitz
Filename : draft-ietf-cat-kerb-chg-password-00.txt
Pages : 4
Date : 03/10/1997
The Kerberos V5 protocol [RFC1510] does not describe any mechanism for
users to change their own passwords. In order to promote interoperability
between workstations, personal computers, terminal servers, routers, and
KDC's from multiple vendors, a common password changing protocol is
required.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-kerb-chg-password-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-password-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310114444.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-kerb-chg-password-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-kerb-chg-password-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310114444.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26853; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26459; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-negotiation-01.txt
Date: Wed, 12 Mar 1997 09:26:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26459 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Transparent Content Negotiation in HTTP
Author(s) : K. Holtman, A. Mutz
Filename : draft-ietf-http-negotiation-01.txt
Pages : 37
Date : 03/10/1997
HTTP allows web site authors to put multiple versions of the same
information under a single URL. Transparent content negotiation is a
mechanism, layered on top of HTTP, for automatically selecting the best
version when the URL is accessed. This enables the smooth deployment of
new web data formats and markup tags.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-negotiation-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-negotiation-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-negotiation-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310113845.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-negotiation-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-negotiation-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310113845.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26856; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26515; 12 Mar 97 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-bryant-00.txt
Date: Wed, 12 Mar 1997 09:27:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26515 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : APPN Implementer's Workshop Closed Pages Document
Author(s) : D. Bryant, P. Brittain
Filename : draft-rfced-info-bryant-00.txt
Pages : 22
Date : 03/10/1997
This document specifies
- a set of extensions to RFC 1795 designed to improve
the scalability of DLSw
- clarifications to RFC 1795 in the light of the
implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795.
No effort has been made to explain these existing protocols or
associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the
APPN Implementers Workshop (AIW). If you would like to participate in
future DLSw discussions, please subscribe to the DLSw RIG mailing lists by
sending a mail to majordomo at raleigh.ibm.com specifying 'subscribe aiw-dlsw'
as the body of the message.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-bryant-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-bryant-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-bryant-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310175002.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-bryant-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-bryant-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310175002.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26848; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26465; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-clarify-06.txt
Date: Wed, 12 Mar 1997 09:26:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26465 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Clarifications to the DNS Specification
Author(s) : R. Elz, R. Bush
Filename : draft-ietf-dnsind-clarify-06.txt
Pages : 14
Date : 03/10/1997
This draft considers some areas that have been identified as problems with
the specification of the Domain Name System, and proposes remedies for the
defects identified. Six separate issues are considered:
+ IP packet header address usage from multi-homed servers,
+ TTLs in sets of records with the same name, class, and type,
+ correct handling of zone cuts,
+ two minor issues concerning SOA records and their use,
+ the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label.
The first four of these are areas where the correct behaviour
has been somewhat unclear, we seek to rectify that. The other two
are already adequately specified, however the specifications seem
to be sometimes ignored. We seek to reinforce the existing specifications.
This version tightens the procedures to be followed when a server receives
an RRSet with varying TTLs on the RRs comprising the RRSet. This is an
attempt to limit the spread of bogus data. This paragraph will be deleted
from the final version of this document.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-clarify-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-clarify-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310131514.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-clarify-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-clarify-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310131514.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26990; 12 Mar 97 9:31 EST
Received: from ietf.ietf.org by ietf.org id aa26526; 12 Mar 97 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-dhcp-dns-03.txt
Date: Wed, 12 Mar 1997 09:27:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26526 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Interaction between DHCP and DNS
Author(s) : Y. Rekhter
Filename : draft-ietf-dhc-dhcp-dns-03.txt
Pages : 7
Date : 03/10/1997
DHCP provides a powerful mechanism for IP host autoconfiguration. However,
the autoconfiguration provided by DHCP does not include updating DNS, and
specifically updating the name to address and address to name mappings
maintained by DNS.
This document specifies how DHCP clients and servers should use the
Dynamic DNS Updates mechanism to update the DNS name to address and
address to name mapping, so that the mappings for DHCP clients would be
consistent with the IP addresses that the clients acquire via DHCP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-dhcp-dns-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-dns-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310141915.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dhcp-dns-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dhcp-dns-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310141915.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26852; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26499; 12 Mar 97 9:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-weider-iab-char-wrkshop-01.txt
Date: Wed, 12 Mar 1997 09:27:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120927.aa26499 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Report of the IAB Character Set Workshop held 29
February - 1 March, 1996
Author(s) : C. Weider, C. Preston, K. Simonsen, H. Alvestrand,
R. Atkinson, M. Crispin, P. Svanberg
Filename : draft-weider-iab-char-wrkshop-01.txt
Pages : 27
Date : 03/10/1997
This report details the conclusions of an IAB-sponsored invitational
workshop held 29 February - 1 March, 1996, to discuss the use of character
sets on the Internet. It motivates the need to have character set handling
in Internet protocols which transmit text, provides a conceptual framework
for specifying character sets, recommends the use of MIME tagging for
transmitted text, recommends a default character set *without* stating that
there is no need for other character sets, and makes a series of
recommendations to the IAB, IANA, and the IESG for furthering the
integration of the character set framework into text transmission
protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-weider-iab-char-wrkshop-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-weider-iab-char-wrkshop-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-weider-iab-char-wrkshop-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310144523.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-weider-iab-char-wrkshop-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-weider-iab-char-wrkshop-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310144523.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26842; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26405; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ftp-wg at hops.ag.utk.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ftpext-intl-ftp-01.txt
Date: Wed, 12 Mar 1997 09:26:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26405 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Extensions to FTP Working
Group of the IETF.
Title : Internationalization of the File Transfer Protocol
Author(s) : B. Curtin
Filename : draft-ietf-ftpext-intl-ftp-01.txt
Pages : 15
Date : 03/10/1997
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123
Section 4 [RFC1123], is one of the oldest and widely used protocols on the
Internet. The protocol's primary character set, 7 bit ASCII, has served the
protocol well through the early growth years of the Internet. However, as
the Internet becomes more global, there is a need to support character sets
beyond 7 bit ASCII.
This document addresses the internationalization (I18n) of FTP, which
includes supporting the multiple character sets found throughout the
Internet community. This is achieved by extending the FTP specification
and giving recommendations for proper internationalization support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ftpext-intl-ftp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ftpext-intl-ftp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ftpext-intl-ftp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310120930.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ftpext-intl-ftp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ftpext-intl-ftp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310120930.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26846; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26444; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-dnsrr-03.txt
Date: Wed, 12 Mar 1997 09:26:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26444 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Roaming Relationship (REL) Resource Record
in the DNS
Author(s) : B. Aboba
Filename : draft-ietf-roamops-dnsrr-03.txt
Pages : 13
Date : 03/10/1997
This document describes the use of the Roaming Relationship (REL) record in
the DNS for the description of roaming relationships. REL resource records
may be used for determining the existence of a roaming relationship path
between the local ISP and the user's home domain, as well as the location
of an appropriate accounting agent. However, unless the roaming
relationship path is authenticated by some method (such as via tokens or
certificates returned by the home authentication server), hierarchical
authentication routing must be used in order to validate the path.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-dnsrr-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-dnsrr-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-dnsrr-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310103820.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-dnsrr-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-dnsrr-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310103820.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa26854; 12 Mar 97 9:30 EST
Received: from ietf.ietf.org by ietf.org id aa26428; 12 Mar 97 9:26 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-radius at livingston.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-radius-tunnel-imp-01.txt
Date: Wed, 12 Mar 1997 09:26:42 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703120926.aa26428 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : Implementation of Mandatory Tunneling via RADIUS
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-radius-tunnel-imp-01.txt
Pages : 17
Date : 03/10/1997
This document discusses implementation issues arising in the provisioning
of mandatory tunneling in dial-up networks using the PPTP and L2TP
protocols. This provisioning may be accomplished via the integration of
RADIUS and tunneling protocols.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-tunnel-imp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-imp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-tunnel-imp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970310103222.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-tunnel-imp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-tunnel-imp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970310103222.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05089; 12 Mar 97 11:50 EST
Received: from box.nl by ietf.org id aa04695; 12 Mar 97 11:41 EST
Received: from cs-gj3-a8.hro.nl (cs-gj3-a8.hro.nl [145.24.129.140]) by box.nl (8.7.5/8.6.9) with SMTP id RAA19886 for <ietf at ietf.org>; Wed, 12 Mar 1997 17:38:52 +0100
Date: Wed, 12 Mar 1997 17:38:52 +0100
Message-Id: <199703121638.RAA19886 at box.nl>
X-Sender: unit at box.nl
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: My Apologies
Source-Info: From (or Sender) name not authenticated.
To IETF list subscribers,
Please accept my sincere apologies for sending my unsubscribe message to the
wrong address; just a typo when I was in a hurry...
Now I'll leave everyone to discussion more important ideas, like the Memphis
hotel arrangements...
sincerely,
Michael Roetto
::::::::::::::::::::::::::::::::::::::::::
: Internet Design Unit :
: http://www.box.nl/~unit/idu :
: :
: Personal Page: :
: http://www.box.nl/~unit/mike :
::::::::::::::::::::::::::::::::::::::::::
Received: from ietf.org by ietf.org id aa05330; 12 Mar 97 11:51 EST
Received: from box.nl by ietf.org id aa05149; 12 Mar 97 11:50 EST
Received: from cs-gj3-a8.hro.nl (cs-gj3-a8.hro.nl [145.24.129.140]) by box.nl (8.7.5/8.6.9) with SMTP id RAA19995 for <ietf at ietf.org>; Wed, 12 Mar 1997 17:48:06 +0100
Date: Wed, 12 Mar 1997 17:48:06 +0100
Message-Id: <199703121648.RAA19995 at box.nl>
X-Sender: unit at box.nl (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: michael_roetto <mike at box.nl>
Subject: appending my apologies
Source-Info: From (or Sender) name not authenticated.
Dear Members,
I just spend a good 15 minutes deleting about 50 different messages
'correcting' my oversight in sending my unsubscribe message to the wrong
address.
Having been on this list for the last six months or so, I have received many
remove messages. Were these people 'mail-bombed' like myself? Or am I just
being made an example of?
I think the response I received for a simple mistake is really out of line.
-michael_roetto
Received: from ietf.org by ietf.org id aa06916; 12 Mar 97 12:16 EST
Received: from jekyll.piermont.com by ietf.org id aa06855; 12 Mar 97 12:15 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id MAA03618; Wed, 12 Mar 1997 12:11:30 -0500 (EST)
Message-Id: <199703121711.MAA03618 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: michael_roetto <mike at box.nl>
cc: ietf at ietf.org
Subject: Re: appending my apologies
In-reply-to: Your message of "Wed, 12 Mar 1997 17:48:06 +0100."
<199703121648.RAA19995 at box.nl>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 12 Mar 1997 12:11:25 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
michael_roetto writes:
> Having been on this list for the last six months or so, I have received many
> remove messages. Were these people 'mail-bombed' like myself? Or am I just
> being made an example of?
1) I, for one, almost always complain about such things, so no, don't
feel that you are special.
2) Being told that your behavior is unacceptable by fifty different
people isn't being "mail bombed". Mail bombing would mean one
person sending you a message fifty times.
> I think the response I received for a simple mistake is really out of line.
It isn't a simple mistake. Its a very annoying mistake that is made
way too often by people who should know better. It is on the order of
public urination -- something that causes no real harm but which is
thought of as being offensive and out of societal norms.
Received: from ietf.org by ietf.org id aa06992; 12 Mar 97 12:16 EST
Received: from noc.msc.edu by ietf.org id aa06953; 12 Mar 97 12:16 EST
Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324))
id AA19773; Wed, 12 Mar 97 11:13:19 -0600
Sender:ietf-request at ietf.org
From: Tim Salo <salo at msc.edu>
Received: (salo at localhost) by uh.msc.edu (8.7.1/8.6.6) id LAA01832; Wed, 12 Mar 1997 11:13:23 -0600 (CST)
Date: Wed, 12 Mar 1997 11:13:23 -0600 (CST)
Message-Id: <199703121713.LAA01832 at uh.msc.edu>
To: ietf at ietf.org, mike at box.nl
Subject: Re: appending my apologies
Source-Info: From (or Sender) name not authenticated.
> I just spend a good 15 minutes deleting about 50 different messages
> 'correcting' my oversight in sending my unsubscribe message to the wrong
> address.
I used to work for a VP of software development who, when he was having
a particularly bad day, would call in some poor salesman [1] and beat him
up (verbally). I think his reasoning was that if he beat up his
subordinates, then his already late deliveries would be even later.
On the other hand, the salesman needed him more than he needed the salesman,
and so made a good target on which to vent.
I always thought that the VP's evil twins reside on many of the mail lists
I read, and when they have a bad day, they go hunting for some unfortunate
soul who sends an "unsubscribe" message to the list. These poor souls make
ideal targets since they want to get off of the list anyway, so they
probably won't stick around to try to explain that there are at least
nineteen "standard" ways of getting removed from mail lists.
Unfortunately, these evil twins, at least when they are having a particularly
bad day, often feel compelled to sent their mail to whole list. As a result,
I have to see the "unsubscribe" message followed by a sometimes long
discussion about "unsubscribe" messages.
And finally, I know that somewhere out there, yet another evil twin of
my ex-VP will be having a bad day, and will send me mail about how I
was wasting his or her time. And, unfortunately, she, he, or it [shit] will
probably copy the whole list, so you too, will know that she/he/it
is having a bad day. Which may only make your day worse. And the
cycle continues.
-tjs
[1] Lest I be skewered for being gender specific, it should be noted that
the VP was a rather traditional guy, and only seemed inclined to beat up on
male salespersons. I don't think the female salespersons liked dealing with
him. Actually, I don't think that salespersons of any gender liked dealing
with him.
Received: from ietf.org by ietf.org id aa13386; 12 Mar 97 14:39 EST
Received: from [202.41.99.2] by ietf.org id aa13187; 12 Mar 97 14:33 EST
Received: from iisc.ernet.in by milan.doe.ernet.in (4.1/SMI-4.1)
id AA13667; Thu, 13 Mar 97 00:40:57+050
Received: from csa.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1)
id AAA25420; Thu, 13 Mar 1997 00:59:59 +0530
Received: from Kohinoor.csa.iisc.ernet.in (kohinoor.csa.iisc.ernet.in [144.16.67.10]) by csa.iisc.ernet.in (8.6.11/8.6.9) with SMTP id BAA24352 for <ietf at ietf.org>; Thu, 13 Mar 1997 01:36:04 +0530
Received: by Kohinoor.csa.iisc.ernet.in (5.x/SMI-SVR4)
id AA20989; Thu, 13 Mar 1997 00:58:27 +0530
Message-Id: <9703121928.AA20989 at Kohinoor.csa.iisc.ernet.in>
Subject: ietf: mailing lists on ip traffic measurements ?
To: ietf at ietf.org
Date: Thu, 13 Mar 1997 00:58:26 +0530 (IST)
Cc: Dinesh <dinesh at kohinoor.csa.iisc.ernet.in>
Sender:ietf-request at ietf.org
From: Dinesh <dinesh at csa.iisc.ernet.in>
Reply-To: dinesh at csa.iisc.ernet.in
Return-Receipt-To: dinesh at csa.iisc.ernet.in
Request-Delivery-Notification: TRUE
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
sirs/madams,
A. is there a list of the ietf which discusses issues on
a. reducing bandwidth consumption
b. internet traffic measurement and studies
if not, are there any other mailing lists ?
the ippm list ( ip perforance and measurement ) is very quiet.
B. is there a moderated list of the ietf ?
in all probability, the questions are very basic.
if so, please do send me the answers by email to
dinesh at csa.iisc.ernet.in
sorry to disturb the current discussion.
-dt
dinesh thirumurthy
research scholar, computer science and automation
indian institute of science, bangalore, india
Received: from cnri by ietf.org id aa14861; 12 Mar 97 15:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18701;
12 Mar 97 15:03 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA00677 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 17:42:46 GMT
To: marc at cygnus.com
Cc: cat-ietf at mit.edu
Subject: kerb-chg-password
References: <9703120927.aa26530 at ietf.org>
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Johan Danielsson <joda at pdc.kth.se>
Date: 12 Mar 1997 18:42:13 +0100
In-Reply-To: Internet-Drafts at ietf.org's message of Wed, 12 Mar 1997 09:26:59 -0500
Message-Id: <xofybbtuhvu.fsf at blubb.pdc.kth.se>
Lines: 15
X-Mailer: Gnus v5.4.24/Emacs 19.34
Precedence: bulk
Hello.
I appreciate the effort to specify a protocol for password changing. A
few questions arise though.
What is the reason behind specifying UDP as the primary protocol?
Using "unsafe" protocols will, as mentioned in the draft, require a
lot of extra sanity checks.
Also, what about the "message length" and "AP_REQ length" fields? As I
see it, these fields limits the whole message to 64k (not that I think
that's a major problem), and adds unnecessary information (since the
lengths of the AP-REQ and KRB-PRIV are implied by the ASN.1 strings).
/Johan
Received: from ietf.org by ietf.org id aa15989; 12 Mar 97 15:31 EST
Received: from skyweyr.com by ietf.org id aa15918; 12 Mar 97 15:29 EST
Received: from [128.2.98.8] (SEUSS.RES.CMU.EDU [128.2.98.8])
by skyweyr.com (8.8.4/8.8.4) with ESMTP
id MAA14856 for <ietf at ietf.org>; Wed, 12 Mar 1997 12:26:13 -0800 (PST)
X-Sender: josh at grinch.res.cmu.edu
Message-Id: <v0302090faf4cc0de605b at [128.2.98.8]>
In-Reply-To: <3.0.1.32.19970311201302.00e88668 at mailhost.oc.com>
References: <199703112315.RAA23372 at uh.msc.edu>
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
X-URL: http://thelorax.skyweyr.com/josh.html
X-Planation: My mountain is waiting...
Date: Wed, 12 Mar 1997 15:25:13 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Joshua D. Baer" <josh at skyweyr.com>
Subject: Re: remove
Source-Info: From (or Sender) name not authenticated.
At 9:13 PM -0500 3/11/97, Cleve Graves wrote:
<excerpt>
So why don't we put a "remove/unsubscribe" filter in, monitor what it
takes out and doesn't take out, correct problems, and make out
listserver a model for what to expect a listserver to do now that we
have Internet toaster and "toaster USERS". And let us not forget that
USER always has been and always will be a four letter word.... Thank
god, for what would we be doing without them?
</excerpt>
This is the approach I took with the latest release of ListSTAR for the
Macintosh. I've NEVER seen someone post a message to the list with
subject "remove" who really wanted to post something. So we trap for
it, and unsubscribe the person. Our server has it's own simple syntax,
but we also accept all other listserver syntaxes, because we know
people are going to send them anyway. Very few messages like this ever
get posted to the list. Other list managers have done this to a lesser
degree, such as LetterRip and Lyris.
Again, if you'r interested in helping stop this, check out the List
Headers proposal.
<<URL:mailto:list-header at arpp.carleton.ca?subject=subscribe>
~Josh
-- ----------------------------------
Joshua D. Baer
SkyList Mailing List Hosting Service
http://cgi.skyweyr.com/Guest.Login
Received: from cnri by ietf.org id aa20711; 12 Mar 97 18:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23094;
12 Mar 97 18:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA11120 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 21:34:16 GMT
Message-Id: <3327210C.3FBA at trsvr.tr.unisys.com>
Date: Wed, 12 Mar 1997 16:33:00 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
Subject: GSS-API and SSL - their coexistence, and related issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Judging by the traffic level, it seems to me that there's a lot of
apathy on the question of the merits and feasibility of putting GSS-API
over SSL. Which leads me to think that perhaps this is the wrong
question. I want to try to summarize what I think are the requirements,
and what the options and issues are.
(in what follows, I'm using "mechanism" in its jargon sense, to indicate
a GSS mechanism (for example, Kerberos))
Requirements
1) Mechanism-independent API for applications and middleware to use.
2) Transport-independent mechanisms
3) CryptoAlgorithm-independent mechanisms.
Possible Options
1) GSS-API as the mechanism-independent API.
Issues:
(a) Application writers seem not to like GSS-API. It seems very
cumbersome to program.
(b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
to require much effort and some compromise.
(c) Popular support for GSS-API seems weak. It's now the native
interface to Kerberos, but the only other mechanism so far using it is
Entrust's SPKM (an X.509-based public key mechanism). No other
developer, to the best of my knowledge, has embraced SPKM. (Can anyone
from Entrust comment on the uptake of GSS-API in the Entrust user base?)
(d) Microsoft has publicly stated a commitment to SSPI (Windows-style
GSS-API) as its native interface to Kerberos and SSL, yet has been
silent since the beginning of this discussion questioning the
feasibility of GSS/SSL coexistence. (Hello Microsoft. Can you comment?)
2) Winsock (or similar) as the mechanism-independent API.
Issues:
(a) A Winsock-style interface may be ideal for applications that want a
minimum of aggravation in invoking security functions, but a management
API will be needed to configure behavior that the application writer
likely doesn't care about (or doesn't know enough to decide, or should
by policy be decided at a more global level) (e.g. ciphersuites)
(b) We just moved the responsibility for organizing the transport
independence. With GSS-API, the caller is responsible for managing the
transport. With Winsock (or similar) we're making the SSL layer
responsible for the transport. This seems to be an advantage. Firstly,
the application is freed from a lot a tedious state maintenance, and
sees a much simpler interface. Secondly, in systems that only care about
TCP/IP, that's the only transport we need to implement. Thirdly, in
systems that do need to deal with other transports, we make the
selection and handling of that transport the responsibility of the
system (not the application) and control its selection through the
(putative) management interface.
(c) We can apparently embrace Kerberos migration within the SSL
mechanism, as defined in
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
This implies that SSL (or TLS or whatever it becomes) becomes the
unifying framework within which all future session-oriented security
mechanisms will live. It appears to set the stage for GSS-API and
SSL/TLS to compete for the role of unifying orchestrator of
session-oriented security. The very existence of this draft seems to me
to be a tacit admission that current SSL techniques are more
developer-friendly than GSS-API. Perhaps the authors could comment.
3) No standard API. Each mechanism does its own thing.
Issues:
(a) Ugh!
Summary - Issues - Musings
Option 2 looks, in some respects, very attractive. Yet it seems to give
SSL/TLS the crown jewels as the central nucleus of session-oriented
security. Is that what we want?
As a security middleware developer, I want to apply my efforts to the
APIs that application developers want to see and will find most
effective to use. So to all the application developers out there I ask,
What are your preferences on these issues? Do you have Kerberos
migration and expansion (to public key) issues? Or are you jumping
straight into SSL and embedding it in your applications? Is each
application going to have its own embedded SSL? What API do you want to
see? Do you care about transports other than TCP/IP?
If you're subscribed to these lists, and you don't care about these
issues, I'd be really interested to know *why* you don't care.
And if you got this far, thanks.
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from cnri by ietf.org id aa21668; 12 Mar 97 19:06 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24220;
12 Mar 97 19:06 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA12540 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 22:08:50 GMT
Message-Id: <61CDD2C9A961CF11B6A000805FD40AA9030F91E3 at RED-84-MSG.dns.microsoft.com>
From: Glen Zorn <glennz at microsoft.com>
To: bjb at trsvr.tr.unisys.com, cat-ietf at mit.edu, CryptoAPI at listserv.msn.com,
ssl-talk at netscape.com
Subject: RE: SSL underneath GSS-API/SSPI (again)
Date: Wed, 12 Mar 1997 13:59:42 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
Bill Buffam [bjb at trsvr.tr.unisys.com] writes:
There has been some interesting discussion over the last few
days, on
both ssl-talk and cat-ietf, on the subject of putting SSL
underneath
GSS-API. Opinions were all over the map: yes, you could do
that, but
why would you want to? - we tried it, but we had to make a
lot of
assumptions in SSL and it wasn't useful - we really want to
decouple
our applications from the underlying mechanism.
In Microsoft's Security Design review (Sept 96), they presented
an
architectural picture with SSL sitting alongside Kerberos (and
NTLM and
other mechanisms) underneath GSS-API (or rather, Microsoft's
SSPI
equivalent).
Insofar as I know, SSPI and GGS-API are _not_ equivalent,
although SSPI syntactically resembles older versions of GSS. SSPI is a
"pure" API - it has no wire-protocol assumptions. GSS is _not_ a pure
API, in that the GSS does not merely offer access to underlying
protocols in a uniform manner, but actually modifies the protocols
themselves. To illustrate, a V5 Kerberos client that is RFC
1510-compliant will not be able to interoperate with a server written
using the GSS-API Kerb V5 mechanism.
Yet Eric Murray tells us he's already tried that and it was
essentially a failure.
I'd be very interested in hearing Microsoft comment on Eric's
experience, and for them to tell us how things are going with
the
SSL-under-SSPI development.
Meanwhile, my own view is that it makes little sense to impose
mechanism-specific APIs on applications. There is a lot of
benefit to
having an API that runs over multiple mechanisms. (And yes, I'm
aware of
the idealized view that applications should call DCOM or RPC,
and the
mechanism interface is below that - but there are many
situations
(probably mostly legacy c/s interactions) where that model won't
work.)
It seems to me that there are, in general, two interfaces needed
for the
average GSS mechanism - one for applications, one for
management. The
management API is used to set policy, and therefore must be
mechanism-specific (for example, such policy issues would be, in
SSL,
cipher-suite/QoS mappings, key exchange mechanism, and any other
mechanism-specific aspect of behavior that most applications
would not
want to have to bother with).
I'm somewhat surprised by how little traffic this topic has
generated.
To me, it looks like a real disaster if GSS apps currently using
Kerberos have to be rewritten to some ad hoc interface on top of
SSL,
(or whatever the next mechanism is) rather than have the new
mechanisms
sit underneath the old interface.
BTW, if anyone wants a summary of messages on this thread to
date, I
collected most of them at
http://www.chesco.com/~buffam/Security/Articles/gss-ssl.txt
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from cnri by ietf.org id aa21704; 12 Mar 97 19:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24242;
12 Mar 97 19:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA11400 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 21:42:46 GMT
Message-Id: <A1A89B76BC87CF11925C00805FD4224C01E8F2C9 at RED-102-MSG.dns.microsoft.com>
From: "Richard B. Ward" <richardw at microsoft.com>
To: "'bjb at trsvr.tr.unisys.com'" <bjb at trsvr.tr.unisys.com>
Cc: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com
Subject: RE: SSL underneath GSS-API/SSPI (again) [long]
Date: Wed, 12 Mar 1997 13:42:16 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
Well, with an invitation like that, we have to chime in.
The short answer is, yes, Microsoft's SSL implementation is a security
provider (analogous to mechanism) under the SSPI API boundary. Like all
short answers, there are a few caveats associated with it.
1) SSL the protocol does not map cleanly onto the GSS model of
authentication. GSS assumes that the calling application has reserved
room in its protocol and is at least nominally aware of security, if
only to the point of transmitting opaque security tokens. SSL the
protocol was designed to secure applications that are essentially
security intolerant, namely HTTP servers, by providing a virtual socket
out of which the application would obtain all of its data.
2) SSL the pk-based-authentication-scheme (*not* the wire protocol)
makes a great authentication protocol, mostly, and if you treat the
header/trailer stuff as the mechanism's token, you can get along pretty
well.
3) SSL(3), and presumably TLS, as well, has some interesting
semantics regarding client authentication which more or less make sense
in the web environment but again, do not map cleanly to GSS. The best
example is client authentication. Under SSL3, client authentication
takes place when the server demands it, arbitrarily somewhere in the
middle of an existing context. This makes sense from the web server
point of view (when someone clicks this link, make them authenticate
themselves), but from the GSS point of view, it is awkward (mutual
authentication up front?).
Now the CAT group is wondering, how are we fitting this under the SSPI
layer, since that is directly analogous to the GSS API. For those of
you not interested in GSS v. SSPI difference, you may want to skip
ahead.
We've always said that the SSPI layer is semantically equivalent to the
GSS-API, but there are differences. Well, those differences come into
play here.
1) Security providers under SSPI understand three different "modes"
of being called, namely Connection, Datagram, and Stream. Connection is
the most similar to GSS, where the application has reserved space for
authentication tokens and MICs. Datagram was introduced to support
DCE-style RPC. There, the client initializes a security context, then
immediately sends the first packet to the server (optionally with MIC,
etc, according to the RPC binding options). The server then sends back
a message demanding authentication, to which the client replies with the
token from initialize security context. Stream is the most complicated,
and is used when the security provider is responsible for all the
message blocking. The SSL security provider parses its own data out of
the stream that the HTTP server passes it, and returns pointers to the
application portion (or distinguished errors indicating not enough data,
too much, etc.).
2) The message APIs (get_mic, verify_mic, etc.) can return a
distinguished error indicating that the application needs to call
init_sec_context again, because the server has demanded a REDO or
RENEGOTIATE.
3) Stream mode is accomplished by associating a type field with
each buffer, and allowing a list of buffers to be sent in to all the
interesting calls. Having a list of buffers also allows us to get
parsing information back out of the security provider, such as extra
data that the application needs to buffer, etc.
4) Current applications using the Microsoft SSL implementation
(Internet Explorer, IIS) are aware of SSL's requirements for streamed
connections, and know how to adjust mechanism specific features, such as
QoS and public key credentials. For the next release of NT, we are
working on improving the mechanism to not only have better defaults, but
make those defaults configurable through an external mechanism.
So, what does this boil down to? Pure, wire-compatible SSL will most
likely not be available under the GSS, due to the streaming nature of
SSL and the message nature of GSS. Taking the SSL authentication scheme
and making a message, rather than stream, based security mechanism is
entirely possible. If there is interest, we can post how we've done it.
-Rich
-----Original Message-----
From: Bill Buffam [SMTP:bjb at trsvr.tr.unisys.com]
Sent: Tuesday, March 11, 1997 1:33 PM
To: cat-ietf at MIT.EDU; CryptoAPI at LISTSERV.MSN.COM;
ssl-talk at netscape.com
Subject: SSL underneath GSS-API/SSPI (again)
There has been some interesting discussion over the last few
days, on
both ssl-talk and cat-ietf, on the subject of putting SSL
underneath
GSS-API. Opinions were all over the map: yes, you could do
that, but
why would you want to? - we tried it, but we had to make a
lot of
assumptions in SSL and it wasn't useful - we really want to
decouple
our applications from the underlying mechanism.
In Microsoft's Security Design review (Sept 96), they presented
an
architectural picture with SSL sitting alongside Kerberos (and
NTLM and
other mechanisms) underneath GSS-API (or rather, Microsoft's
SSPI
equivalent). Yet Eric Murray tells us he's already tried that
and it was
essentially a failure.
I'd be very interested in hearing Microsoft comment on Eric's
experience, and for them to tell us how things are going with
the
SSL-under-SSPI development.
Meanwhile, my own view is that it makes little sense to impose
mechanism-specific APIs on applications. There is a lot of
benefit to
having an API that runs over multiple mechanisms. (And yes, I'm
aware of
the idealized view that applications should call DCOM or RPC,
and the
mechanism interface is below that - but there are many
situations
(probably mostly legacy c/s interactions) where that model won't
work.)
It seems to me that there are, in general, two interfaces needed
for the
average GSS mechanism - one for applications, one for
management. The
management API is used to set policy, and therefore must be
mechanism-specific (for example, such policy issues would be, in
SSL,
cipher-suite/QoS mappings, key exchange mechanism, and any other
mechanism-specific aspect of behavior that most applications
would not
want to have to bother with).
I'm somewhat surprised by how little traffic this topic has
generated.
To me, it looks like a real disaster if GSS apps currently using
Kerberos have to be rewritten to some ad hoc interface on top of
SSL,
(or whatever the next mechanism is) rather than have the new
mechanisms
sit underneath the old interface.
BTW, if anyone wants a summary of messages on this thread to
date, I
collected most of them at
http://www.chesco.com/~buffam/Security/Articles/gss-ssl.txt
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa22835; 12 Mar 97 20:06 EST
Received: from servo.qualcomm.com by ietf.org id aa22374; 12 Mar 97 19:55 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id QAA17929; Wed, 12 Mar 1997 16:49:04 -0800 (PST)
Date: Wed, 12 Mar 1997 16:49:04 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199703130049.QAA17929 at servo.qualcomm.com>
To: MRC at panda.com
CC: ietf at ietf.org
In-reply-to: <MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM> (message from Mark Crispin on Mon, 10 Mar 1997 11:23:02 -0800 (PST))
Subject: Re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
Any sender-oriented anti-spam mechanism (sender pays, legal sanctions,
etc) will never work. In particular, legal sanctions would have the
same fundamental Constitutional and practical problems as the infamous
Communications Decency Act. (It amazes me just how many vociferous
opponents of the CDA can so easily call for laws against spamming.)
The only place where there's any hope of stopping *any* unwanted or
offensive Internet content, whether it be "indecency" or spam, is at
the receiver. I hold this truth to be self-evident.
The ideal anti-spam system would require all incoming email to be
signed (e.g., with PGP). Unsigned messages would automatically
bounce. An individual receiver could blacklist anyone who sends
unwanted material, and the signature mechanism would make this hard to
evade. In effect, this is a "reputation system" as it has long been
discussed by the Cypherpunks.
But the vast majority of email is not yet signed, and there are many
people without PGP from whom I would still like to receive mail. So
this calls for a more heuristic approach.
I have noticed that almost all of the spam I get is immediately
preceded or followed by a bounce message from a system I haven't used
in over 5 years. At first I thought this old system was forwarding the
spam and sending me a separate forwarding notification. Not so. I get
these pairs of messages because both my old and new email addresses
are on the spammers' mailing lists. Obviously they are after sheer
quantity, not quality; they can't possibly afford to verify that every
address on their list works before they use it.
This suggests an effective countermeasure. Deliberately "salt" the
spammers' lists. Create a bogus email address and use it to post items
to obscure Usenet groups that are unlikely to be answered. Register
it with any web sites known to cull spam lists in this way. Register
it with the online email directories. Use a fictional real name so
it's unlikely to be used by anyone who is legitimately trying to
contact you.
Now when the spammers build their lists and start spraying you with
spam, you have your mail agent and/or server look for any messages
common to your "salt" and regular email accounts and automatically
delete them from the latter. If you keep your salt account's identity
a secret, it will be nearly impossible for the spammers to avoid. And
as long as their list remains salted, they'll be unable to send you
spam.
This could be done either on an individual basis or by a subscription
service that would conduct salting efforts and make lists of spam
(either the actual texts or their MD5 hashes) available to a
subscriber's mail agent or server over the net.
The basic idea here is not at all new; essentially the same thing has
been done for years to protect proprietary mailing lists against
unauthorized use.
The only countermeasure I can think of is for the spammers to make
each of their spam messages unique somehow, and I'm not sure how to
deal with this. Any suggestions would be welcome.
Phil
Received: from cnri by ietf.org id aa22939; 12 Mar 97 20:10 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25450;
12 Mar 97 20:10 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA15963 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 23:34:05 GMT
Message-Id: <33273CE2.36D1 at dascom.com>
Date: Wed, 12 Mar 1997 15:31:46 -0800
From: John Nunneley <johnn at dascom.com>
Reply-To: johnn at dascom.com
Organization: Dascom
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: bjb at trsvr.tr.unisys.com
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <3327210C.3FBA at trsvr.tr.unisys.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Yes. Let's get over the specifics of the original question.
I did some more poking around on the MS site and apparently they
understand the merits of this issue quite well. The SSPI sure looks a
lot like GSSAPI on the surface, but apparently and according to some,
doesn't impose any implementation or protocol on the mechanism as some
have asserted that GSSAPI does. In fact, the lovely slides I saw show
MS fully embracing Kerberos as the replacement for NTLM authentication
and simultaneously/seamlessly supporting SSL and a smorgasborg of crypto
routines. This is what I want to write my app to. Unfortunately, I
doubt I will ever have such a thing that runs on the (other) platforms I
care about :-{
I would assert that:
Applications should not embed security policy or mechanisms. Rather
policy should be set and mechanisms selected by the administrators of
the site/system/domain that meet there needs.
Is there at least general agreement on this point? If so, the need for
such an API should be apparent. Bill Buffman made some very excellent
points. We are in a situation where none of the solutions meet all
three of the requirements. Plus, I'd add a fourth which is Platform
independence.
Is it possible to "fix" GSSAPI. Or has MS already done this for us ;)
--
------------------------------------------------------------------------
John Nunneley Phone: +1 408 457 4510
DASCOM Inc. Fax: +1 408 457 0710
1509 Seabright Avenue Email: johnn at dascom.com
Santa Cruz CA 95062 WWW: http://www.dascom.com/
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa23262; 12 Mar 97 20:17 EST
Received: from zephyr.isi.edu by ietf.org id aa23066; 12 Mar 97 20:15 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA01740>; Wed, 12 Mar 1997 17:13:10 -0800
Message-Id: <199703130113.AA01740 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2110 on MHTML
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Mar 97 17:13:10 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2110
Title: MIME E-mail Encapsulation of Aggregate
Documents, such as HTML (MHTML)
Author: J. Palme, A. Hopmann
Date: March 1997
Mailbox: jpalme at dsv.su.se, alexhop at microsoft.com
Pages: 19
Characters: 41961
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2110.txt
Although HTML [RFC 1866] was designed within the context of MIME, more
than the specification of HTML as defined in RFC 1866 is needed for
two electronic mail user agents to be able to interoperate using HTML
as a document format. This document describes a set of guidelines that
will allow conforming mail user agents to be able to send, deliver and
display these objects, such as HTML objects, that can contain links
represented by URIs. In order to be able to handle inter-linked
objects, the document uses the MIME type multipart/related and
specifies the MIME content-headers "Content-Location" and
"Content-Base". This document is a product of the MIME Encapsulation
of Aggregate HTML Documents Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970312170618.RFC at ISI.EDU>
SEND /rfc/rfc2110.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2110.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970312170618.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23586; 12 Mar 97 20:22 EST
Received: from zephyr.isi.edu by ietf.org id aa23550; 12 Mar 97 20:21 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA02029>; Wed, 12 Mar 1997 17:19:06 -0800
Message-Id: <199703130119.AA02029 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2111 on CID and MID URL
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Mar 97 17:19:05 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2111
Title: Content-ID and Message-ID Uniform Resource
Locators
Author: E. Levinson
Date: March 1997
Mailbox: XIson at cnj.digex.com
Pages: 5
Characters: 9113
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2111.txt
The Uniform Resource Locator (URL) schemes, "cid:"; and "mid:"; allow
references to messages and the body parts of messages. For example,
within a single multipart message, one HTML body part might include
embedded references to other parts of the same message. This document
is a product of the MIME Encapsulation of Aggregate HTML Documents
Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970312171338.RFC at ISI.EDU>
SEND /rfc/rfc2111.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2111.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970312171338.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24024; 12 Mar 97 20:28 EST
Received: from zephyr.isi.edu by ietf.org id aa23964; 12 Mar 97 20:28 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA02439>; Wed, 12 Mar 1997 17:25:26 -0800
Message-Id: <199703130125.AA02439 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2112 on MIME Multipart/Related Content-type
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 12 Mar 97 17:25:26 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2112
Title: The MIME Multipart/Related Content-type
Author: E. Levinson
Date: March 1997
Mailbox: XIson at cnj.digex.com
Pages: 9
Characters: 17052
Updates/Obsoletes: 1872
URL: ftp://ds.internic.net/rfc/rfc2112.txt
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
This document defines the Multipart/Related content-type and provides
examples of its use. This document is a product of the MIME
Encapsulation of Aggregate HTML Documents Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970312171942.RFC at ISI.EDU>
SEND /rfc/rfc2112.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2112.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970312171942.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24710; 12 Mar 97 20:42 EST
Received: from egoshin.genesyslab.com by ietf.org id aa24649;
12 Mar 97 20:41 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id RAA16734; Wed, 12 Mar 1997 17:39:22 -0800
Date: Wed, 12 Mar 1997 17:39:22 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703130139.RAA16734 at egoshin.genesyslab.com>
To: karn at qualcomm.com, MRC at panda.com
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Phil Karn <karn at qualcomm.com>
>
>The ideal anti-spam system would require all incoming email to be
>signed (e.g., with PGP). Unsigned messages would automatically
>bounce. An individual receiver could blacklist anyone who sends
>unwanted material, and the signature mechanism would make this hard to
>evade. In effect, this is a "reputation system" as it has long been
>discussed by the Cypherpunks.
>
As I understand this approach can give us the only two ways -
- accept all E-mails (as now) or accept the only "friendly" signed
E-mails. Please, don't forget that spammer can change his E-sign
as his address.
OK, it may be useful for business manager who want exchange
E-mail the only with partners, but certainly not for me and many others.
But we also suffer from spam !
I don't know any Internet entity which can't be changed fast
except IP [or net] address/domain name. The first requeries change
provider and second - InterNIC action ;-)
- Leonid Yegoshin, LY22
Received: from cnri by ietf.org id aa25880; 12 Mar 97 21:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26363;
12 Mar 97 21:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA18464 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 00:41:15 GMT
To: Johan Danielsson <joda at pdc.kth.se>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703120927.aa26530 at ietf.org> <xofybbtuhvu.fsf at blubb.pdc.kth.se>
From: Marc Horowitz <marc at cygnus.com>
Date: 12 Mar 1997 19:40:26 -0500
In-Reply-To: joda at pdc.kth.se's message of 12 Mar 1997 18:42:13 +0100
Message-Id: <t53rahksjyd.fsf at rover.cygnus.com>
Lines: 30
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
joda at pdc.kth.se (Johan Danielsson) writes:
>> What is the reason behind specifying UDP as the primary protocol?
>> Using "unsafe" protocols will, as mentioned in the draft, require a
>> lot of extra sanity checks.
For the same reason that the main kerberos protocol uses UDP: it
allows the server to be simple and stateless. If modern operating
systems had decent thread implementations, this would be less
important, but TCP multiplexing adds a fair bit of complexity.
>> Also, what about the "message length" and "AP_REQ length" fields? As I
>> see it, these fields limits the whole message to 64k (not that I think
>> that's a major problem), and adds unnecessary information (since the
>> lengths of the AP-REQ and KRB-PRIV are implied by the ASN.1 strings).
If there is consensus on this, I will increase the length fields to 32
bits (and increase the protocol version number, since I already have
an implementation). However, I agree that 64k seems big enough.
As for redundancy, while ASN.1 does encode the length, the
encode/decode functions which the kerberos library uses require that
the length be known ahead of time (at least I think it does; i'm
caught in a maze of cpp macros, all alike). As a general rule, I
prefer to think of ASN.1 encodings as black boxes, since ASN.1 is so
complex. Besides, redundancy is a good thing :-)
Thanks for the comments!
Marc
Received: from ietf.org by ietf.org id aa26121; 12 Mar 97 21:14 EST
Received: from cjc08238.slip.digex.net by ietf.org id aa26044;
12 Mar 97 21:11 EST
Received: from cja00010.slip.digex.net (localhost [127.0.0.1]) by cja00010.slip.digex.net (8.6.11/8.6.9) with ESMTP id VAA00359; Wed, 12 Mar 1997 21:07:41 -0500
Message-Id: <199703130207.VAA00359 at cja00010.slip.digex.net>
To: Tim Salo <salo at msc.edu>
cc: ietf at ietf.org, mike at box.nl
Subject: Re: appending my apologies
In-reply-to: Your message of "Wed, 12 Mar 1997 11:13:23 CST."
<199703121713.LAA01832 at uh.msc.edu>
Reply-to: Ed Levinson <XIson at cnj.digex.net>
X-Mailer: MH 6.8.3
Date: Wed, 12 Mar 1997 21:07:41 -0500
Sender:ietf-request at ietf.org
From: Ed Levinson <xison at cnj.digex.net>
Source-Info: From (or Sender) name not authenticated.
Tim, thanks for a good chuckle and a great wide smile :-> "... she,
he, or it [shit] ...". I rarely read "remove" messages or messages
in the threads they generate. I'm glad to have read yours.
Ed
On Wed, 12 Mar 1997 11:13:23 CST Tim Salo wrote:
> ...
> And finally, I know that somewhere out there, yet another evil twin of
> my ex-VP will be having a bad day, and will send me mail about how I
> was wasting his or her time. And, unfortunately, she, he, or it [shit] will
> probably copy the whole list, so you too, will know that she/he/it
> is having a bad day. Which may only make your day worse. And the
> cycle continues.
> ...
Received: from ietf.org by ietf.org id aa27386; 12 Mar 97 21:46 EST
Received: from callandor.cybercash.com by ietf.org id aa27325;
12 Mar 97 21:45 EST
Received: by callandor.cybercash.com; id VAA23310; Wed, 12 Mar 1997 21:35:56 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma023284; Wed, 12 Mar 97 21:35:19 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA28403; Wed, 12 Mar 97 21:38:24 EST
Date: Wed, 12 Mar 1997 21:38:23 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Export restrictions (Re: call for a new email infrastructure)
In-Reply-To: <3325D3ED.7007 at atr.net>
Message-Id: <Pine.SUN.3.91.970312203308.26881C-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 11 Mar 1997, Turner W Rentz III wrote:
> Date: Tue, 11 Mar 1997 16:51:41 -0500
> From: Turner W Rentz III <treyr at atr.net>
>
> Leonid Yegoshin wrote:
>
> > ...
> > More over that could you do with export restrictions on this (the) way
> ...
>
> Export restrictions will prohibit RSA keys greater than 40 bits.
> It is my understanding that key length will go up soon.
There are no special munitions type export retrictions from the US for
authentication only schemes, using RSA or other systems, with keys of any
length. There are such restrictions on confidentiality systems. (And there
are a few countries to which all exports from the US require special
permission.)
> T. Rentz, III "The Internet is the Garden of Eden."
> http://www.atr.net/people/treyr
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa27491; 12 Mar 97 21:48 EST
Received: from net1.unety.net by ietf.org id aa27445; 12 Mar 97 21:48 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by net1.unety.net (8.7.3/8.7.3) with SMTP id UAA04866; Thu, 13 Mar 1997 20:13:34 -0600 (CST)
Received: by webster.unety.net with Microsoft Mail
id <01BC2F25.E0320080 at webster.unety.net>; Wed, 12 Mar 1997 20:42:18 -0600
Message-ID: <01BC2F25.E0320080 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Phil Karn' <karn at qualcomm.com>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: call for a new email infrastructure
Date: Wed, 12 Mar 1997 20:42:16 -0600
Encoding: 53 TEXT
Source-Info: From (or Sender) name not authenticated.
On Wednesday, March 12, 1997 10:49 AM, Phil Karn[SMTP:karn at qualcomm.com] wrote:
@ Any sender-oriented anti-spam mechanism (sender pays, legal sanctions,
@ etc) will never work. In particular, legal sanctions would have the
@ same fundamental Constitutional and practical problems as the infamous
@ Communications Decency Act. (It amazes me just how many vociferous
@ opponents of the CDA can so easily call for laws against spamming.)
@
I agree....
I was sort of surprised that you did not look down
the road a bit more. The world of distributed object-oriented
technology with active agents and an emphasis on
platforms rather than protocols is closer than you may
think. It will be interesting to see how the IETF deals
with such a major paradigm shift.
In my opinion, this technology will help to solve many
of the problems of the uncivilized IPv4 "core". The core
will evolve to be a low-cost transport network with a
reasonable DNS and reliability and operational integrity
largely handled by major carriers.
Around the edge of this core will grow a new world
that is more immune from the social problems that
now plague the net. This will be similar to the way
suburbs developed around the core cities and for
many people, they can rely on the core but not
really go there.
In a year or two, I predict that people will not
find it to be desirable to plug themselves into
the core, just like people do not find it desirable to
wander around some major cities after dark.
Instead, the collaborative, seemless, environments
built on objects and classes with simple protocols
will offer people the "services" they want. Hopefully,
one of those "services" will be mail processing. If
that occurs then we may end up with a world where
software agents work out the details while people
spend their time on real issues facing the the
real world.
Thanks for your time...
--
Jim Fleming
Unir Corporation
e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)
Received: from cnri by ietf.org id aa28165; 12 Mar 97 22:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27197;
12 Mar 97 22:01 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA16347 at pad-thai.cam.ov.com>; Wed, 12 Mar 1997 23:42:59 GMT
Message-Id: <3.0.32.19970312154438.00946c20 at pop-srvr.cybersafe.com>
X-Sender: matth at pop-srvr.cybersafe.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Mar 1997 15:44:40 -0800
To: bjb at trsvr.tr.unisys.com, cat-ietf at mit.edu, CryptoAPI at listserv.msn.com,
ssl-talk at netscape.com
From: Matt Hur <matt.hur at cybersafe.com>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
At 04:33 PM 3/12/97 -0500, Bill Buffam wrote:
8<
>8
>(c) We can apparently embrace Kerberos migration within the SSL
>mechanism, as defined in
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
>This implies that SSL (or TLS or whatever it becomes) becomes the
>unifying framework within which all future session-oriented security
>mechanisms will live. It appears to set the stage for GSS-API and
>SSL/TLS to compete for the role of unifying orchestrator of
>session-oriented security. The very existence of this draft seems to me
>to be a tacit admission that current SSL techniques are more
>developer-friendly than GSS-API. Perhaps the authors could comment.
>
The Kerberos cipher suite draft does not imply a preference of SSL over
GSS-API. It simply acknowledges a general acceptance of SSL.
We view support for Kerberos cipher suites in SSL as simply a mechanism to
provide more coverage and interoperability for users who are registered
with Kerberos realms. This is especially apparent within the enterprise
environment.
SSL (or TLS) is currently a dominant public key based protocol. Since it
is so easy to add a Kerberos authentication method, it seemed like a
"no-brainer" to add support for Kerberos cipher suites (in that you can get
a big payoff in interoperability - it took about a week and a half to do
our reference implementation).
We are trying to be pragmatic about interoperability (espcially since our
company's primary customers are large enterprises). If an organization has
a Kerberos infrastructure in place, then they should be able to use
Kerberos for authentication to services that are secured via protocols that
have typically utilized public key cryptography for authentication.
Whether this solution leads to a migration to a public key infrastructure
or not is orthogonal to the issue of interoperability. Likewise, if an
organization has a public key infrastructure in place, then they should be
able to use public key credentials to authenticate to Kerberized services
(this is accomplished with PKINIT, another Internet draft with which we
have been intimately involved). Again, whether or not this is a migratory
solution is orthogonal to the issue of interoperability.
We would like to see support for Kerberos cipher suites in SSL/TLS. We
think that this is a pragmatic approach to interoperability in large scale,
real world deployments.
We talked with the folks over at Netscape about supporting Kerberos cipher
suites in their SSL implementation. If you are developing SSL/TLS
implementations, we would like to hear from you, and we would be interested
in providing support for this endeavor. We haven't talked with the folks
at Microsoft yet, but we would appreciate thier input, since they are
developing both Kerberos and SSL/TLS-based solutions as part of their
security infrastructure.
You can download a simple reference implementation from
ftp://nii.isi.edu/pub/ssl-krb.
Regards,
Matt Hur
8<
>8
>--
>
>Bill Buffam
>Unisys, Malvern PA
>bjb at trsvr.tr.unisys.com
>
>
----------------------------------------------------------------
Matt Hur CyberSafe
matt.hur at cybersafe.com 1605 NW Sammamish Road, Suite 310
(206) 391-6000 Issaquah, WA 98027-5378
http://www.cybersafe.com
Received: from cnri by ietf.org id aa28266; 12 Mar 97 22:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27235;
12 Mar 97 22:03 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA17119 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 00:05:07 GMT
Date: Wed, 12 Mar 1997 19:04:39 -0500
Message-Id: <9703130004.AA00386 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: bjb at trsvr.tr.unisys.com
Cc: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
In-Reply-To: Bill Buffam's message of Wed, 12 Mar 1997 16:33:00 -0500,
<3327210C.3FBA at trsvr.tr.unisys.com>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Well, here's my take on things.
GSSAPI is the ideal interface between an application and a security
mechanism such as Kerberos, or SPKM (if you want to use public key).
It defines enough of a token-framing protocol so that you can recognize
which GSSAPI mechanism produced a particular GSSAPI token, and we have
convenient meta-protocol definitions (such as SASL) to define how you
can layer GSSAPI on top of a stream-based application protocol.
GSSAPI can also be used as the binary interface into which you can "plug
and play" a security mechanism. So for example, SAP ships its
application without any security code (after all, they are in Germany,
and they don't want to deal with Germany's export control regulations).
Their application can dynamically link with a GSSAPI library which is
provided by MIT in the U.S., and the net result is a secure application
which uses strong cryptography! We're successfully interfacing with SAP
under Unix (OSF/1 and Solaris unix shared libraries), Windows 3.x, 95
and NT (DLL's), and Macintosh (using CFM's).
An application vendor can therefore support multiple security
mechanisms, and not even have to supply a specially linked application,
by using dynamically linked libraries using the GSSAPI as the interface
definition.
It is true that that the GSSAPI isn't necessarily the easist API to
write to. But we don't necessarily need to force application writers to
write to the GSSAPI! For example, if we have a simple library which
implements a meta-protocol such as SASL and makes GSSAPI calls, and
implements a a more familiar API based on STDIO for the application
programmer, we can just let the application programer use that.
Obviously, the simpler API will tradeoff a lot of functionality for
simplicity. However, many applications may not need all of the
functionality, and therefore the complexity, provided by the GSSAPI.
The simpler API can also be OS-dependent, and thus manage the transport
layer for the application as well. It might look a lot like WINSOCK
(ala SSL), although my personal bias is that the STDIO interface might
be easier for programmers.
The issue about OS issues is important --- some operating systems, such
as the Macintosh, really assume that I/O should be done asyncronously,
and they have their own way of handling the asyncronous I/O. Under X11,
for example, you may use an EventLoop; under the Macintosh, you use
callback functions. An API which gets involved with transport issues
needs to make an allowance for how its going to handle async I/O.
This is why I believe the GSSAPI is the ideal, OS-independent interface
point between applications and security mechanisms. There may need to
be some OS-dependent shim code that handles the transport and which is
actually usable by applications protocol. The disconnect that we have
today is that GSSAPI handles the first problem well, and the second one
not at all, and SSL handles the second problem well, but not the first.
- Ted
Received: from cnri by ietf.org id aa05445; 12 Mar 97 23:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa28206;
12 Mar 97 23:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA16949 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 00:01:30 GMT
Message-Id: <199703130000.AA26256 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
To: bjb at trsvr.tr.unisys.com
Date: Wed, 12 Mar 1997 19:00:18 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <3327210C.3FBA at trsvr.tr.unisys.com> from "Bill Buffam" at Mar 12, 97 04:33:00 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Bill Buffam wrote:
>
> Requirements
> 1) Mechanism-independent API for applications and middleware to use.
>
> 2) Transport-independent mechanisms
>
> 3) CryptoAlgorithm-independent mechanisms.
>
>
> Possible Options
>
> 1) GSS-API as the mechanism-independent API.
> Issues:
> (a) Application writers seem not to like GSS-API. It seems very
> cumbersome to program.
Once you get used to it, you'll appreciate it simplicity.
I like it.
> (b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
> to require much effort and some compromise.
I haven't read anything about SSL, so I'm mere guessing:
- SSL usually comes with a transport mechanism, GSS-API is without
- SSL is synchronus&blocking, GSS-API is whatever you want
- SSL is stream, GSS-API is message-oriented.
- GSS-API v2 defines security context transfer to other processes,
I don't know if that is defined for SSL
> (c) Popular support for GSS-API seems weak. It's now the native
> interface to Kerberos, but the only other mechanism so far using it is
> Entrust's SPKM (an X.509-based public key mechanism). No other
> developer, to the best of my knowledge, has embraced SPKM. (Can anyone
> from Entrust comment on the uptake of GSS-API in the Entrust user base?)
- OSF DCE 1.1 offers GSS-API,
- Sesame-based products use GSS-API as their (only) native interface.
A year ago our development partners did plan to support SPKM in their
commercial product. Currently they're using their own mechanism,
I don't know when or if they're going to complete their SPKM implementation.
(http://www.secude.com).
> (d) Microsoft has publicly stated a commitment to SSPI (Windows-style
> GSS-API) as its native interface to Kerberos and SSL, yet has been
> silent since the beginning of this discussion questioning the
> feasibility of GSS/SSL coexistence. (Hello Microsoft. Can you comment?)
If they're careful, it should be possible with some glue layer atop
SSPI to talk to native GSS-API v1 Kerberos implementations. I would
really appreciate if they added context transfer capabilities to SSPI,
so that GSS-API v2 becomes a possibility.
>
> 2) Winsock (or similar) as the mechanism-independent API.
> Issues:
> (a) A Winsock-style interface may be ideal for applications that want a
> minimum of aggravation in invoking security functions, but a management
> API will be needed to configure behavior that the application writer
> likely doesn't care about (or doesn't know enough to decide, or should
> by policy be decided at a more global level) (e.g. ciphersuites)
> (b) We just moved the responsibility for organizing the transport
> independence. With GSS-API, the caller is responsible for managing the
> transport. With Winsock (or similar) we're making the SSL layer
> responsible for the transport. This seems to be an advantage. Firstly,
> the application is freed from a lot a tedious state maintenance, and
> sees a much simpler interface. Secondly, in systems that only care about
> TCP/IP, that's the only transport we need to implement. Thirdly, in
> systems that do need to deal with other transports, we make the
> selection and handling of that transport the responsibility of the
> system (not the application) and control its selection through the
> (putative) management interface.
As far as I know, SSL is ALWAYS synchronous and blocking. This is a
serious limitation, because it impacts scalability and reliability.
> (c) We can apparently embrace Kerberos migration within the SSL
> mechanism, as defined in
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
> This implies that SSL (or TLS or whatever it becomes) becomes the
> unifying framework within which all future session-oriented security
> mechanisms will live. It appears to set the stage for GSS-API and
> SSL/TLS to compete for the role of unifying orchestrator of
> session-oriented security. The very existence of this draft seems to me
> to be a tacit admission that current SSL techniques are more
> developer-friendly than GSS-API. Perhaps the authors could comment.
>
> 3) No standard API. Each mechanism does its own thing.
> Issues:
> (a) Ugh!
>
> Summary - Issues - Musings
> Option 2 looks, in some respects, very attractive. Yet it seems to give
> SSL/TLS the crown jewels as the central nucleus of session-oriented
> security. Is that what we want?
It is probably the most easy and fast way to go for many small and medium
size applications in spite of a some performance, scalability and
reliability issues.
A large application that pushes every available hardware to it's
limits might not be able to accept any one of these problems...
-Martin
Received: from ietf.org by ietf.org id aa06863; 12 Mar 97 23:59 EST
Received: from mail.proper.com by ietf.org id aa06778; 12 Mar 97 23:55 EST
Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA16455; Wed, 12 Mar 1997 20:49:11 -0800 (PST)
X-Sender: paulh at mail.proper.com
Message-Id: <v03101f1aaf4d38c4328d at [165.227.249.100]>
In-Reply-To: <199703130049.QAA17929 at servo.qualcomm.com>
References: <MailManager.858021782.366.mrc at Ikkoku-Kan.Panda.COM> (message
from Mark Crispin on Mon, 10 Mar 1997 11:23:02 -0800 (PST))
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 Mar 1997 20:54:50 -0800
To: Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 4:49 PM -0800 3/12/97, Phil Karn wrote:
>Any sender-oriented anti-spam mechanism (sender pays, legal sanctions,
>etc) will never work. In particular, legal sanctions would have the
>same fundamental Constitutional and practical problems as the infamous
>Communications Decency Act. (It amazes me just how many vociferous
>opponents of the CDA can so easily call for laws against spamming.)
I disagree with you about the constitutionality of (US) laws that will help
control spam (more properly called unsolicitied commercial mail or UCE).
Specficially, I believe that laws that require both labelling and honesty
in return addresses can help control UCE by making filtering at the user
and ISP level more effective. Please see <http://www.imc.org/imc-spam/> for
a reference to a very complete legal review article about what has been and
can be done about UCE. IMC is also starting a mailing list to discuss these
legal issues.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from cnri by ietf.org id aa07307; 13 Mar 97 0:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01347;
13 Mar 97 0:04 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA24638 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 03:29:56 GMT
Date: Wed, 12 Mar 1997 22:29:11 -0500
Message-Id: <9703130329.AA00527 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: johnn at dascom.com
Cc: bjb at trsvr.tr.unisys.com, cat-ietf at mit.edu, ssl-talk at netscape.com
In-Reply-To: John Nunneley's message of Wed, 12 Mar 1997 15:31:46 -0800,
<33273CE2.36D1 at dascom.com>
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 12 Mar 1997 15:31:46 -0800
From: John Nunneley <johnn at dascom.com>
I did some more poking around on the MS site and apparently they
understand the merits of this issue quite well. The SSPI sure looks a
lot like GSSAPI on the surface, but apparently and according to some,
doesn't impose any implementation or protocol on the mechanism as some
have asserted that GSSAPI does.
The problem is that you *have* to impose some sort of protocol framing
on *top* of the the mechanism if you want to ensure interoperability.
For example, the way SSL is set up, you have to always run SSL/POP or
SSL/NNTP on a separate port. The original Kerberos KPOP protocol has to
run on a separate port from POP or SSL/POP for the same reason.
To the extent that the application server has to run on different ports,
and clients need to run on different ports (and fail mysteriously if you
try to connect a SSL/POP client to a Kerberos/POP port), you'll begin to
appreciate why GSSAPI imposes a token framing *above* the mechanism.
That is, the Kerberos GSSAPI mechanism specification describes how
Kerberos is used by a Kerberos GSSAPI mechanism. I don't see this as
GSSAPI *imposing* anything on mechanism; rather GSSAPI is *wrapping* a
token encapsulation over a mechanism, and this encapsulation provides
significant value.
With GSSAPI and a properly coded application server and client which
uses the GSSAPI interface properly, the application server and client
can use the standard POP port (or IMAP port, or whatever your
standard application port is). You don't need to allocate new magic
ports for each application. In addition, as I've mentioned before, with
the magic of dynamic libraries, the application writer doesn't
necessarily need to know which GSSAPI mechanism will be used when she
develops her application.
Applications should not embed security policy or mechanisms. Rather
policy should be set and mechanisms selected by the administrators of
the site/system/domain that meet there needs.
That's precisely the design goals of GSSAPI.
Is there at least general agreement on this point? If so, the need for
such an API should be apparent. Bill Buffman made some very excellent
points. We are in a situation where none of the solutions meet all
three of the requirements. Plus, I'd add a fourth which is Platform
independence.
Well, if you want Platform independence, I wouldn't suggest using SSPI,
as that's a Microsoft proprietary standard.
You'd be much better off writing to the GSSAPI, and in the case of
Microsoft, if they don't provide a GSSAPI interface, it should be
possible to write a shim layer which calls out to a SSPI provider and
implements a GSSAPI mechanism.
It's clear that we also need some OS-dependent shim layers that handle
the transport layer issues, since application programmers as a rule
appear not to be able to handle anything more complicated than a simple
stream oriented interface --- this appears to be why SSL has proven to
be so popular. Once we have this, though, I think GSSAPI has the
potential for fulling the requirements that you've outlined.
- Ted
Received: from ietf.org by ietf.org id aa08547; 13 Mar 97 1:08 EST
Received: from servo.qualcomm.com by ietf.org id aa08412; 13 Mar 97 1:04 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id WAA18661; Wed, 12 Mar 1997 22:00:56 -0800 (PST)
Date: Wed, 12 Mar 1997 22:00:56 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199703130600.WAA18661 at servo.qualcomm.com>
To: paulh at imc.org
CC: ietf at ietf.org
In-reply-to: <v03101f1aaf4d38c4328d at [165.227.249.100]> (message from Paul Hoffman on Wed, 12 Mar 1997 20:54:50 -0800)
Subject: Re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
>I disagree with you about the constitutionality of (US) laws that will help
>control spam (more properly called unsolicitied commercial mail or UCE).
You may be right, but there is at least an issue here that will
probably be litigated for years by the spammers. Receiver filtering,
on the other hand, is unquestionably constitutional. And it can be
implemented much more quickly than any law.
>Specficially, I believe that laws that require both labelling and honesty
>in return addresses can help control UCE by making filtering at the user
I understand your intent is benign, but even the best intentioned laws
have a way of being wielded by overzealous prosecutors against those
who were not the original subject of the law. Plus, laws don't enforce
themselves. Do we really want to invite federal prosecutors further
into our lives, especially when we have yet to exhaust all the
technical alternatives?
And what about anonymous email? There are many perfectly legitimate
uses for anonymous email, but a sloppily written law could easily ban
them all. Perhaps a requirement that anonymous email be clearly marked
as such (so it could be filtered at the receiver) would be tolerable.
Don't forget there are already laws against wire fraud that could be
used against those who forge email addresses -- if the case were truly
serious. Do we even need new laws to do what you want?
Phil
Received: from cnri by ietf.org id aa08780; 13 Mar 97 1:11 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02583;
13 Mar 97 1:11 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <EAA26796 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 04:32:37 GMT
To: Marc Horowitz <marc at cygnus.com>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703120927.aa26530 at ietf.org> <xofybbtuhvu.fsf at blubb.pdc.kth.se> <t53rahksjyd.fsf at rover.cygnus.com>
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Johan Danielsson <joda at pdc.kth.se>
Date: 13 Mar 1997 05:32:21 +0100
In-Reply-To: Marc Horowitz's message of 12 Mar 1997 19:40:26 -0500
Message-Id: <xofu3mgv2cq.fsf at blubb.pdc.kth.se>
Lines: 50
X-Mailer: Gnus v5.4.24/Emacs 19.34
Precedence: bulk
Marc Horowitz <marc at cygnus.com> writes:
> For the same reason that the main kerberos protocol uses UDP: it
> allows the server to be simple and stateless.
Hmm, but the server isn't stateless if you have to handle resent
messages and such-like.
Database updates must be atomic. Suppose I have a KDC implementation
that doesn't have the notion of a master server - you can talk to
anyone of the database machines to update information. I must then
implement some kind of locking mechanism, so that it isn't possible to
change one entry at two different places at the same time. With TCP
you only have to lock the entry until you have successfully closed the
connection. With UDP you can never know that the client has gotten
your reply. It could go about talking to some other server (since it
didn't get a reply from the first server).
There is also the matter of fire-walls that doesn't let through UDP.
Another thing (from the Overview): "this service must be implemented
on at least one host for each Kerberos realm". Isn't this the same as
saying that if you want to support this protocol you must implement
it?
Also, the draft doesn't mention what mechanisms can be used to find
this service.
> As for redundancy, while ASN.1 does encode the length, the
> encode/decode functions which the kerberos library uses require that
> the length be known ahead of time
If the MIT code bails out if the message is too short, then that's a
good enough reason to include the lengths, even if there are other
libraries that doesn't have this limitation.
> Besides, redundancy is a good thing :-)
If you like redundany, why not using ASN.1? :-)
KDC-CHG-PWD ::= SEQUENCE {
pvno[1] INTEGER,
req[2] AP-REQ,
priv[3] KRB-PRIV
}
Or perhaps not.
/Johan
Received: from ietf.org by ietf.org id aa09130; 13 Mar 97 1:17 EST
Received: from songbird.com by ietf.org id aa08927; 13 Mar 97 1:15 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id GAA00729; Thu, 13 Mar 1997 06:12:10 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703131412.GAA00729 at songbird.com>
Subject: Re: appending my apologies
To: perry at piermont.com
Date: Thu, 13 Mar 1997 06:12:10 -0800 (PST)
Cc: mike at box.nl, ietf at ietf.org
In-Reply-To: <199703121711.MAA03618 at jekyll.piermont.com> from "Perry E. Metzger" at Mar 12, 97 12:11:25 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Perry E. Metzger allegedly said:
>
>
> michael_roetto writes:
> > Having been on this list for the last six months or so, I have received many
> > remove messages. Were these people 'mail-bombed' like myself? Or am I just
> > being made an example of?
>
> 1) I, for one, almost always complain about such things, so no, don't
> feel that you are special.
> 2) Being told that your behavior is unacceptable by fifty different
> people isn't being "mail bombed". Mail bombing would mean one
> person sending you a message fifty times.
>
> > I think the response I received for a simple mistake is really out of line.
>
> It isn't a simple mistake. Its a very annoying mistake that is made
> way too often by people who should know better. It is on the order of
> public urination -- something that causes no real harm but which is
> thought of as being offensive and out of societal norms.
Perry, you must have had a bad day. No other way to explain such a
small-minded and small-hearted sentiment.
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html
Received: from cnri by ietf.org id aa09148; 13 Mar 97 1:17 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02696;
13 Mar 97 1:17 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA25640 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 03:56:15 GMT
To: bjb at trsvr.tr.unisys.com
Cc: cat-ietf at mit.edu, CryptoAPI at listserv.msn.com, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <3327210C.3FBA at trsvr.tr.unisys.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 12 Mar 1997 22:55:25 -0500
Message-Id: <t53d8t4v42a.fsf at rover.cygnus.com>
Lines: 122
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Bill Buffam <bjb at trsvr.tr.unisys.com> writes:
>> Judging by the traffic level, it seems to me that there's a lot of
>> apathy on the question of the merits and feasibility of putting GSS-API
>> over SSL. Which leads me to think that perhaps this is the wrong
>> question. I want to try to summarize what I think are the requirements,
>> and what the options and issues are.
I think your analysis is reasonable. I caught a bit of this thread on
cat-ietf at mit.edu, and responded there, but seem to have missed the
members of the other two lists, so I'm going to repost the whole
thing. Apologies if you see it twice. I hate to say this, but if
people reply, keeping it on all the lists would be good, since not
everyone is subbed everywhere.
--cut--
Mike Eisler <Michael.Eisler at eng.sun.com> writes:
>> I've had similar thoughts. One could create a GSS-API mechanism
>> that mimiced SSL's CipherSuites as QOP values (using the same
>> numerical values). And one could also mimic SSL's CipherSuite
>> negotiation during the GSS_Init_sec_context/GSS_Accept_sec_context
>> handshake.
>>
>> The value in this would be in simplifying the deployment of
>> protocols that use GSS-API security into operating environments
>> that favor SSL (for example web browsers). While the result would
>> NOT be the SSL protocol, it would be security equivalent to what
>> SSL delivers. Presumably, if the operating environment has
>> modularized the SSL layer appropriately, the GSS-SSL mechanism
>> could share code with the SSL protocol's API:
>>
>>
>> internal SSL-api GSS-API
>> | |
>> ssl-protocol engine gss-ssl-mech
>> \ /
>> ssl-crypto-code
I've had similar thoughts to Mike's but I'd splice it in somewhat
differently. SSL has two advantages. From an application author's
point of view, you have a sockets-like api which implements a secure
channel. From a security point of view, you have a deployed key
infrastructure (which is somewhat fragmented and incomplete, but
between netscape, verisign, and RSA, it's getting somewhere):
internal ssl api
|
x.509 + sockets
I would add gssapi in there as a cryptosuite:
internal ssl (tls) api
|
(gssapi, x.509) + sockets
|
x.509-ssl, kerberos, spkm, whatever
This would let new and old ssl apps continue to work together. A pair
of new ssl apps could use any gssapi mechanism instead of x.509
certificates. Also, apps which didn't want to use ssl could still
take advantage of the key management infrastructure (mainly the
widely-known commercial CA's) growing up around SSL.
Adding gssapi here would be very similar to Ari's kerberos draft.
Marc
--cut--
My response basically fits in as a variant of option 2c in Bill's
analysis:
>> (c) We can apparently embrace Kerberos migration within the SSL
>> mechanism, as defined in
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
>> This implies that SSL (or TLS or whatever it becomes) becomes the
>> unifying framework within which all future session-oriented security
>> mechanisms will live. It appears to set the stage for GSS-API and
>> SSL/TLS to compete for the role of unifying orchestrator of
>> session-oriented security. The very existence of this draft seems to me
>> to be a tacit admission that current SSL techniques are more
>> developer-friendly than GSS-API. Perhaps the authors could comment.
My integration would seem to provide for a nice split between SSL/TLS
and GSSAPI. SSL/TLS provides a simple API for application developers
to implement to. Of course, for some applications, the simple
approach of protecting the transport layer will be inadequate, and
those developers can use the more complex but more powerful GSSAPI.
GSSAPI can be used as an SSPI, as Microsoft is doing, and as an API.
It would be very nice if MS would participate in this aspect of the
IETF, so that there are not two different but related standards for
this (MS and IETF). Other consumers of the GSSAPI could include ONC
RPC, IPsec, and proprietary applications such as Oracle.
GSSAPI, then, is used as an interface for providing different key
*management* systems. What is interesting about the differences
between SSL/X.509, Kerberos, PGP, etc. is not the difference in
cryptosystems (RC4 vs DES vs IDEA), but the difference in key
management approach (heirarchical public key infrastructure vs central
trusted third-party vs web of trust). SSL key management can remain
parallel to GSSAPI for backward compatibility, but future development
should continue under GSSAPI, so that users of other API's can
benefit.
At the bottom of the abstraction is the application of cryptosuites to
various key management infrastructures. There isn't a particular
standard I can think of right now for this, but it would seem to be
possible to define a standard to allow cryptographic algorithms (in
particular, cryptosystems, hashes, MAC's, and combinations) to be
portably and safely consumed by a wide range of security technologies.
This layering does not allow one to make GSSAPI calls and get a series
of tokens which are wire-compatible with SSL, but I don't think that's
important, either. What GSSAPI does need is an extension to better
support stream-oriented I/O.
Richard Ward: are there any documents which describe the SSPI, and
does it make sense on non-windows os's? (I know, you don't care :-)
Marc
Received: from ietf.org by ietf.org id aa10365; 13 Mar 97 1:40 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa10320; 13 Mar 97 1:39 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id BAA13080; Thu, 13 Mar 1997 01:35:00 -0500 (EST)
Message-Id: <199703130635.BAA13080 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: Export restrictions (Re: call for a new email infrastructure)
In-reply-to: Your message of "Wed, 12 Mar 1997 21:38:23 EST."
<Pine.SUN.3.91.970312203308.26881C-100000 at cybercash.com>
Date: Thu, 13 Mar 1997 01:35:00 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> There are no special munitions type export retrictions from the US for
> authentication only schemes, using RSA or other systems, with keys of any
> length. There are such restrictions on confidentiality systems. (And there
> are a few countries to which all exports from the US require special
> permission.)
You mean I can export source code to the RSA algorithm as long as
the code is only used to do authentication? Great!
Keith
Received: from ietf.org by ietf.org id aa11880; 13 Mar 97 2:41 EST
Received: from nic.scruz.net by ietf.org id aa11794; 13 Mar 97 2:38 EST
Received: from dperkins4.sj.scruznet.com ([205.179.102.28])
by scruz.net (8.7.3/1.34) with SMTP id XAA14419
for <ietf at ietf.org>; Wed, 12 Mar 1997 23:35:59 -0800 (PST)
Date: Wed, 12 Mar 97 23:21:19 pst
Sender:ietf-request at ietf.org
From: David Perkins <dperkins at scruznet.com>
Subject: New IETF WEB page
To: ietf at ietf.org
X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc.
Message-ID: <Chameleon.970312234030.dperkins at dperkins4.sj.scruznet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
HI
Thank you for the new IETF WEB page design. It is much easier to find
stuff. Also, thanks for changing references of the "Operational Requirements"
Area to the "Operations and Management" Area. (There is still a reference in
the agenda file, ftp://ftp.ietf.org/ietf/0mgt-agenda.txt).
Regards,
/dperkins at scruznet.com, David T. Perkins
Date: 03/12/97, Time: 23:21:19
Received: from cnri by ietf.org id aa12822; 13 Mar 97 3:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04487;
13 Mar 97 3:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <GAA29831 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 06:29:47 GMT
To: Johan Danielsson <joda at pdc.kth.se>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703120927.aa26530 at ietf.org> <xofybbtuhvu.fsf at blubb.pdc.kth.se>
<t53rahksjyd.fsf at rover.cygnus.com> <xofu3mgv2cq.fsf at blubb.pdc.kth.se>
From: Marc Horowitz <marc at cygnus.com>
Date: 13 Mar 1997 01:28:56 -0500
In-Reply-To: joda at pdc.kth.se's message of 13 Mar 1997 05:32:21 +0100
Message-Id: <t534teguwyf.fsf at rover.cygnus.com>
Lines: 53
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
joda at pdc.kth.se (Johan Danielsson) writes:
>>
>> Marc Horowitz <marc at cygnus.com> writes:
>>
>> > For the same reason that the main kerberos protocol uses UDP: it
>> > allows the server to be simple and stateless.
>>
>> Hmm, but the server isn't stateless if you have to handle resent
>> messages and such-like.
You don't have to do this. I was careful to write the protocol so
that updates are idempotent.
>> Database updates must be atomic. Suppose I have a KDC implementation
>> that doesn't have the notion of a master server - you can talk to
>> anyone of the database machines to update information. I must then
>> implement some kind of locking mechanism, so that it isn't possible to
>> change one entry at two different places at the same time. With TCP
>> you only have to lock the entry until you have successfully closed the
>> connection. With UDP you can never know that the client has gotten
>> your reply. It could go about talking to some other server (since it
>> didn't get a reply from the first server).
Again, since updates are idempotent, this is not an issue. Once you
receive the request, create a transaction/update/commit, then reply.
If the client doesn't receive the ack, no harm is done, because the
retry will not change any state. In any case, TCP just makes the
problem more subtle. You can have the same problem if the host falls
off the net while the connection is closing, and therefore cannot
exchange the final FIN-FIN/ACK-ACK. TCP is itself not
transaction-safe.
>> There is also the matter of fire-walls that doesn't let through UDP.
So you implement TCP, too. In any case, the krb5 protocol is UDP, so
you have to deal with the firewall issues, anyway.
>> Another thing (from the Overview): "this service must be implemented
>> on at least one host for each Kerberos realm". Isn't this the same as
>> saying that if you want to support this protocol you must implement
>> it?
What it says is that if you implement Kerberos, you must implement
this protocol, too. At least that's what I intended.
>> Also, the draft doesn't mention what mechanisms can be used to find
>> this service.
rfc1510 dosn't mention what mechanisms can be used to find a kdc. If
it does, I'll update this draft to use a similar mechanism.
Marc
Received: from ietf.org by ietf.org id aa18047; 13 Mar 97 9:42 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa17873;
13 Mar 97 9:36 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199703131430.XAA11838 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id XAA11838; Thu, 13 Mar 1997 23:30:21 +0900
Subject: Re: Memphis hotel situation
To: Dave Morton <Dave.Morton at ecrc.de>
Date: Thu, 13 Mar 97 23:30:19 JST
Cc: karn at qualcomm.com, randy at psg.com, ietf at ietf.org
In-Reply-To: <199703070900.KAA01293 at acrab25.ecrc.de>; from "Dave Morton" at Mar 7, 97 10:00 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
Dear IETF divers;
> >> The recurring IETF hotel situation is becoming completely
> >> untenable. Aside from moving the IETF permanently to Las Vegas (if any
> >> US city can handle a group our size, Vegas is it), does anyone have
> >> any ideas to solve this problem?
> >
> >Vladavostok, Cape Town, Santiago, Havana, ... All beautiful cities, and we
> >would solve two problems with one hack.
> >
> >randy
>
> Randy - next IETF is Munich - I think we have the hotel situation
> under control for the Aug. meeting.
But, why the December meeting is moved from Hawaii to Washington D.C?
Masataka Ohta
Received: from ietf.org by ietf.org id aa19122; 13 Mar 97 10:08 EST
Received: from mail.cno.com.br by ietf.org id aa19011; 13 Mar 97 10:06 EST
Received: by mail.cno.com.br (AIX 3.2/UCB 5.64/4.03)
id AA09265; Thu, 13 Mar 1997 12:04:19 -0400
Received: from unknown(10.1.0.25) by mail.cno.com.br via smap (V1.3)
id sma006445; Thu Mar 13 12:03:47 1997
Received: from canario.dpabr.cno.com.br by dsbr01.dpabr.cno.com.br (AIX 3.2/UCB 5.64/4.03)
id AA20770; Thu, 13 Mar 1997 12:03:47 -0400
Message-Id: <9703131603.AA20770 at dsbr01.dpabr.cno.com.br>
X-Mapi-Messageclass: IPM
Read-Receipt-To: Luiz Sergio Canario <canario at cno.com.br>
Return-Receipt-To: canario at cno.com.br
Priority: Normal
To: paulh at imc.org
Cc: ietf at ietf.org
X-Mailer: FTP Software Internet Mail 2.0
Mime-Version: 1.0
Sender:ietf-request at ietf.org
From: Luiz Sergio Canario <canario at cno.com.br>
X-Orig-Sender: Luiz Sergio Canario <canario at cno.com.br>
Subject: RE: call for a new email infrastructure
Date: Thu, 13 Mar 1997 12:08:07 -0300
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
I wiuld like to remember all of you that any law,=20
constitutional or not, in the USA, have any efects outside=20
USA. So it should not be discussed in terms of laws.
Regards
Luiz Sergio Canario
Received: from ietf.org by ietf.org id aa20833; 13 Mar 97 10:39 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa20707; 13 Mar 97 10:36 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id KAA26122;
Thu, 13 Mar 1997 10:30:56 -0500
Message-Id: <199703131530.KAA26122 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Phil Karn <karn at qualcomm.com>
Cc: MRC at panda.com, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Wed, 12 Mar 1997 16:49:04 PST."
<199703130049.QAA17929 at servo.qualcomm.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199703130049.QAA17929 at servo.qualcomm.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1602998420P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 13 Mar 1997 10:30:55 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1602998420P
Content-Type: text/plain; charset=us-ascii
On Wed, 12 Mar 1997 16:49:04 PST, Phil Karn said:
> The only countermeasure I can think of is for the spammers to make
> each of their spam messages unique somehow, and I'm not sure how to
> deal with this. Any suggestions would be welcome.
The solution here is for use of a "comparison function" to indicate
that a given piece of e-mail is "similar" to another one. A prototype
designed for use with MH to determine which folder to place a given
piece of e-mail can be found at:
----
ifile - intelligent mail filter
This uses a text-based learning algorithm to learn user preferences
for which messages should go in which folders. More information,
including a README and the ifile package for the current version, is
available at "ftp://syrinx.res.cmu.edu/pub/ifile/";.
----
I'm not sure how "steep" the program's learning curve is - I seem to
remember seeing a quote by the author that it takes "about a week" of
you refiling mail (and it watching and learning) before it gets good
at it. However, that was in reference to normal mailing list
operation, where often nothing will be the same except the "To:"
address in the headers. I suspect given 2 pieces of e-mail that are
even 80% identical, that it would work with a high level of
reliability....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1602998420P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMygdrdQBOOoptg9JAQHlIgP+IikcjqRCPap1INbk+k78DA9xDxJZnMcB
QdynAhU/+hAFOPz5jOljs254ZnG4YHasB+9sRaFBphiVwQjGqTM7FEJ2H3V2z/mI
9rG1SXoiMvXeJHXBbevKikTdkmnQs64QDflXZK2LoGANWaTo3SKVxzyPKSpL5fdD
wqh2DHo2NAo=
=o7ff
-----END PGP MESSAGE-----
--==_Exmh_-1602998420P--
Received: from ietf.org by ietf.org id aa22281; 13 Mar 97 11:05 EST
Received: from ns.jck.com by ietf.org id aa21992; 13 Mar 97 10:59 EST
Received: from tp7.Jck.com ("port 1342"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-7 #21705) with SMTP id <0E6ZO9JC000FW6 at a4.jck.com>
for ietf at ietf.org; Thu, 13 Mar 1997 10:56:08 -0500 (EST)
Date: Thu, 13 Mar 1997 10:55:46 -0500 (EST)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: RE: call for a new email infrastructure
In-reply-to: <9703131603.AA20770 at dsbr01.dpabr.cno.com.br>
To: Luiz Sergio Canario <canario at cno.com.br>
Cc: ietf at ietf.org, paulh at imc.org
Message-id: <SIMEON.9703131046.I at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1b1 Build (5)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Thu, 13 Mar 1997 12:08:07 -0300 Luiz Sergio Canario
<canario at cno.com.br> wrote:
> I wiuld like to remember all of you that any law,
> constitutional or not, in the USA, have any efects outside
> USA. So it should not be discussed in terms of laws.
Luiz,
I think there are two issues here that are not "US law"...
(i) There are efforts in progress in several countries to
make Internet providers responsible for the traffic they
carry. Complying with such regulations would require
solving almost insurmountable technical problems. However,
if it is possible for a country to ban pornography crossing
into its country on the Internet and for it to enforce that
ban, then it is probably about equally possible to ban spam
(or unsolicited email more generally).
(ii) Organizations like the ITU can, and have, created
"recommendations" that are treated by most countries as
having treaty status, i.e., the force of law. And other
sorts of international agreements among countries (and,
modulo regulations in some countries that constrain
agreements among competitors at least without government
approval, among ISPs) are, of course, possible.
That said, at least to this point, a large fraction of the
"spam"-type email that actually involves trying to sell
things or to get people to send money originate from the US
or are sponsored or promoted by US-based individuals or
organizations. If we could stop them, or make their
businesses appreciably more troublesome or costly to carry
on, by domestic action in the US, we would make a huge dent
in the problem.
That is not the case with bulk unsolicited email used to
annoy, to show off capabilities, or to deny service -- like
all other acts of vandalism, these are extremely hard to
detect, isolate, and either prevent or punish in effective
ways.
john
Received: from ietf.org by ietf.org id aa24402; 13 Mar 97 12:01 EST
Received: from mail.proper.com by ietf.org id aa24249; 13 Mar 97 11:57 EST
Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA24388; Thu, 13 Mar 1997 08:50:44 -0800 (PST)
X-Sender: paulh at mail.proper.com (Unverified)
Message-Id: <v03101f00af4dde06451b at [165.227.249.100]>
In-Reply-To: <199703130600.WAA18661 at servo.qualcomm.com>
References: <v03101f1aaf4d38c4328d at [165.227.249.100]> (message from Paul
Hoffman on Wed, 12 Mar 1997 20:54:50 -0800)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Mar 1997 08:53:30 -0800
To: Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 10:00 PM -0800 3/12/97, Phil Karn wrote:
>>I disagree with you about the constitutionality of (US) laws that will help
>>control spam (more properly called unsolicitied commercial mail or UCE).
>
>You may be right, but there is at least an issue here that will
>probably be litigated for years by the spammers. Receiver filtering,
>on the other hand, is unquestionably constitutional. And it can be
>implemented much more quickly than any law.
Receiver filtering today is only available to skilled people with the time
to implement it for themselves. I'd like to see methods (technical and/or
legal) be put into place to make receiver filtering easier for everyone.
Other folks are working on the technical end; IMC is going to work on the
legal end. The two efforts will support each other.
>I understand your intent is benign, but even the best intentioned laws
>have a way of being wielded by overzealous prosecutors against those
>who were not the original subject of the law.
That's not a good reason to not create laws. To put it another way, even
the best intentioned non-laws (that is, customs, morals, and agreements)
have a way of being wielded by overzealous individuals against those who
were not the original subject of the non-laws. The fact that it is a law
doesn't cause the overzealousness; it's the fact that we're all people.
>Plus, laws don't enforce
>themselves. Do we really want to invite federal prosecutors further
>into our lives, especially when we have yet to exhaust all the
>technical alternatives?
In the case of UCE, yes. The laws I'm proposing are not draconian: they
simply state that today's laws requiring honesty must extend into the world
of email, and that UCE be honestly labelled as UCE in a standard fashion.
As you point out, the first should already be the case, but without a law
behind it, no one has been prosecuted for it. The latter is an extension of
the current law aimed at helping software identify UCE.
>And what about anonymous email? There are many perfectly legitimate
>uses for anonymous email, but a sloppily written law could easily ban
>them all.
Thank you for assuming that I am advocating a sloppily written law. :-)
Anonymous UCE is useless, because no one could reply to the commercial part
of it. Anonymous mail that has no commercial content wouldn't be prohibited
by a law about UCE.
>Perhaps a requirement that anonymous email be clearly marked
>as such (so it could be filtered at the receiver) would be tolerable.
Maybe, but I explicitly want to focus on UCE, not anonymous mail.
>Don't forget there are already laws against wire fraud that could be
>used against those who forge email addresses -- if the case were truly
>serious. Do we even need new laws to do what you want?
Yes. There is, as far as I know, no legal definition of "forged email
address" or even "email address" in the US, and I haven't heard of any from
any other part of the world, either. If worded correctly by people in the
technical community, a law that describes what an email address is could
help prosecute people who forge them, and *only* people who forge them (as
compared to someone whose address gets frobbled by their ISP's broken SMTP
server and somehow ends up in court).
In summary, I'm advocating that we create a short, focused law that will
help people do incoming filtering. IMC is willing to do the work, including
getting the legislation going. This will *not* replace the technical work
going on; in fact, we'll need additional technical work in order to
convince the legislature of the need for it.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from ietf.org by ietf.org id aa24401; 13 Mar 97 12:01 EST
Received: from mail.proper.com by ietf.org id aa24282; 13 Mar 97 11:58 EST
Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA24392; Thu, 13 Mar 1997 08:50:44 -0800 (PST)
X-Sender: paulh at mail.proper.com (Unverified)
Message-Id: <v03101f01af4de18c18f7 at [165.227.249.100]>
In-Reply-To: <9703131603.AA20770 at dsbr01.dpabr.cno.com.br>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Mar 1997 08:56:55 -0800
To: Luiz Sergio Canario <canario at cno.com.br>
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: RE: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 7:08 AM -0800 3/13/97, Luiz Sergio Canario wrote:
>I wiuld like to remember all of you that any law,
>constitutional or not, in the USA, have any efects outside
>USA. So it should not be discussed in terms of laws.
I strongly disagree. Every jurisdiction can decide which laws it wants.
Further, many countries copy laws created in the US (for better or worse).
And, further yet, countries can have bilateral agreements to prosecute
people who violate similar laws in the two countries.
Do you *really* want US spammers who are prevented from sending UCE here to
flood mailboxes of people around the world? Good laws and good technical
work can help prevent that.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from ietf.org by ietf.org id aa25423; 13 Mar 97 12:16 EST
Received: from zephyr.isi.edu by ietf.org id aa24966; 13 Mar 97 12:12 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA29386>; Thu, 13 Mar 1997 09:09:42 -0800
Message-Id: <199703131709.AA29386 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2099 on Summary of RFCs 2000-2099
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 13 Mar 97 09:11:45 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2099
Title: Request for Comments Summary
RFC Numbers 2000-2099
Author: J. Elliott
Date: March 1997
Mailbox: elliott at isi.edu
Pages: 21
Characters: 40763
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2099.txt
This RFC is a slightly annotated list of the 100 RFCs from RFC 2000
through RFCs 2099. This is a status report on these RFCs.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970313090800.RFC at ISI.EDU>
SEND /rfc/rfc2099.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2099.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970313090800.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25431; 13 Mar 97 12:16 EST
Received: from rumpleteazer.UCSC.EDU by ietf.org id aa25323; 13 Mar 97 12:14 EST
Received: from krazy.ucsc.edu (krazy.UCSC.EDU [128.114.129.44])
by cats.ucsc.edu (8.8.5/8.8.4.cats-athena) with SMTP
id JAA07031; Thu, 13 Mar 1997 09:11:43 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Boolootian <booloo at cats.ucsc.edu>
Received: by krazy.ucsc.edu (8.6.13/4.7) id JAA16462; Thu, 13 Mar 1997 09:11:38 -0800
Message-Id: <199703131711.JAA16462 at krazy.ucsc.edu>
Subject: Re: appending my apologies
To: XIson at cnj.digex.net
Date: Thu, 13 Mar 1997 09:11:38 -0800 (PST)
Cc: salo at msc.edu, ietf at ietf.org, mike at box.nl
In-Reply-To: <199703130207.VAA00359 at cja00010.slip.digex.net> from "Ed Levinson" at Mar 12, 97 09:07:41 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Not that the list needs such foolishness, but I note:
>Tim, thanks for a good chuckle and a great wide smile :-> "... she,
>he, or it [shit] ...". I rarely read "remove" messages or messages
>in the threads they generate. I'm glad to have read yours.
Many years ago on this very list, Vint Cerf produced what I consider
the pinnacle of gender neutral pronouns: s/he/it. Pronounciation, of
course, is left to the reader. I've used it frequently.
mb
Received: from ietf.org by ietf.org id aa28062; 13 Mar 97 13:19 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa27862;
13 Mar 97 13:12 EST
Received: from Ikkoku-Kan.Panda.COM (rich at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id KAA09333; Thu, 13 Mar 1997 10:09:23 -0800 (PST)
Received: from localhost (resp at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id KAA16650; Thu, 13 Mar 1997 10:09:18 -0800 (PST)
Date: Thu, 13 Mar 1997 09:33:05 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: call for a new email infrastructure
To: ietf at ietf.org
In-Reply-To: <199703131530.KAA26122 at black-ice.cc.vt.edu>
Message-ID: <MailManager.858274385.14809.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
There are ways in which legislation can stop UCE. Here's one that I like.
The recipient of UCE is permitted to collect $5 from his ISP for each UCE
message received. The ISP, in turn, is permitted to collect treble damages
from the entity that transmitted the UCE to the ISP. This continues up the
chain to the originator.
Yes, there would be quite a few collateral consequences. It would drive the
flakier ISPs out of business (my heart bleeds). It would create a market for
UCE liability insurance and bonding. It would establish valid cause to
disconnect rogue sites. It would make Internet access be a valuable commodity
that is not lightly discarded as a "throwaway account".
I'm not terribly worried about UCE moving overseas. No US ISP would be
willing to route networks from UCE-haven nations into the US. It's very
likely that responsible foreign countries would pass similar anti-UCE
legislation to defend themselves.
We have to stop thinking of the Internet as a right. It's a privilege,
granted by a collective of cooperating organizations. Those who abuse the
privilege must be shut out of the collective.
Received: from ietf.org by ietf.org id aa28364; 13 Mar 97 13:24 EST
Received: from relay.hq.tis.com by ietf.org id aa28325; 13 Mar 97 13:23 EST
Received: by relay.hq.tis.com; id NAA03314; Thu, 13 Mar 1997 13:19:05 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2)
id xma003287; Thu, 13 Mar 97 13:18:36 -0500
Received: from [10.33.112.20] (flapdoodle.hq.tis.com [10.33.112.20]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id NAA03246 for <ietf at ietf.org>; Thu, 13 Mar 1997 13:16:59 -0500 (EST)
X-Sender: lewis at pop.hq.tis.com
Message-Id: <v03007807af4df2c82684 at [10.33.112.20]>
In-Reply-To: <9703131603.AA20770 at dsbr01.dpabr.cno.com.br>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Mar 1997 13:13:39 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Edward Lewis <lewis at tis.com>
Subject: RE: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
At 10:08 AM -0500 3/13/97, Luiz Sergio Canario wrote:
>USA. So it should not be discussed in terms of laws.
General comment in 10 words or less:
Internet *Engineering* Task Force.
Not Internet *Legal* Task Force.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis Trusted Information Systems
Phone: +1 301-854-5794 Email: lewis at tis.com
Opinions expressed are property of my evil twin, not my employer.
Received: from ietf.org by ietf.org id aa29329; 13 Mar 97 13:42 EST
Received: from socks2.raleigh.ibm.com by ietf.org id aa29277;
13 Mar 97 13:41 EST
Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0)
id AA42424; Thu, 13 Mar 1997 13:38:46 -0500
Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id NAA89250; Thu, 13 Mar 1997 13:38:44 -0500
Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
id AA29558; Thu, 13 Mar 1997 13:38:43 -0500
Message-Id: <9703131838.AA29558 at vision.raleigh.ibm.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Paul Hoffman <paulh at imc.org>
Cc: ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-Reply-To: Your message of "Thu, 13 Mar 1997 08:53:30 EST."
<v03101f00af4dde06451b at [165.227.249.100]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 13 Mar 1997 13:38:41 EST
Sender:ietf-request at ietf.org
From: Steven L Blake <slblake at vision.raleigh.ibm.com>
Source-Info: From (or Sender) name not authenticated.
Paul Hoffman <paulh at imc.org> wrote:
> That's not a good reason to not create laws. To put it another way, even
> the best intentioned non-laws (that is, customs, morals, and agreements)
> have a way of being wielded by overzealous individuals against those who
> were not the original subject of the non-laws. The fact that it is a law
> doesn't cause the overzealousness; it's the fact that we're all people.
Overzealous individuals who are wielding "customs, morals, and agreements"
usually don't have the power to put someone in prison.
> In summary, I'm advocating that we create a short, focused law that will
> help people do incoming filtering. IMC is willing to do the work, including
> getting the legislation going. This will *not* replace the technical work
> going on; in fact, we'll need additional technical work in order to
> convince the legislature of the need for it.
I used to advocate good government until I realized that government,
by its nature, is not good. The content of a law goes to the highest
bidder, and in the US at least, politicians are cheap. You are welcome
to advocate all of the well-intentioned laws you like, but that has
nothing to do with what we will ultimately get.
Introducing regulation of e-mail content will, if we are all lucky,
*only* increase the cost of using e-mail. If we are unlucky, it
will lead to prohibitions against encryption (bureaucrats have to
be able to read the material they are regulating, right?).
Work to make sure that there are no legal impediments to ISPs negotiating
and enforcing multi-lateral appropriate use agreements, and work to make
sure that Internet access does not become a universal service requirement
under FCC regulations. This will give ISPs a market incentive to both
regulate their user's behavior and to control the ISPs that they inter-
network with.
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven L. Blake slblake at vnet.ibm.com |
| Internetworking Technology (919)254-2030 (work) |
| IBM Networking Division (919)254-5483 (fax) |
| "You like the 'Net? You ain't seen nothin' yet!" |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
Received: from cnri by ietf.org id aa01971; 13 Mar 97 14:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18178;
13 Mar 97 14:39 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA16477 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 15:37:13 GMT
Message-Id: <9703131537.AA03397 at dns.sprintcorp.com>
From: "Ashraf Madoukh - (913) 534-3137" <ashraf at dns.sprintcorp.com>
To: CAT-IETF Group <cat-ietf at mit.edu>
Subject: GSS-API V2
Date: Thu, 13 Mar 1997 09:36:17 -0600
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1160
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: bulk
Is there any company who fully implemented GSS-API V2.0 or are we still in
discussion phase only?
What's the latest draft on GSS-API v2.0?
Thanx,
Ashraf
Received: from ietf.org by ietf.org id aa02164; 13 Mar 97 14:43 EST
Received: from cnri by ietf.org id aa02068; 13 Mar 97 14:41 EST
Received: from trix01.genie.uottawa.ca by CNRI.Reston.VA.US id aa18259;
13 Mar 97 14:40 EST
Received: by trix01.genie.uottawa.ca (5.65/DEC-Ultrix/4.3)
id AA18643; Thu, 13 Mar 1997 14:29:00 -0500
Received: by trix.genie.uottawa.ca (5.57/Ultrix3.0-C)
id AA04570; Thu, 13 Mar 97 14:31:02 -0500
Date: Thu, 13 Mar 97 14:31:02 -0500
X-Sender: georgana at trix02.genie.uottawa.ca
Message-Id: <v01550100630c2cb3c273 at [137.122.107.105]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: tccc at cs.umass.edu, osimcast at bbn.com, sc6wg4 at ntd.comsat.com,
xtp-relay at cs.concordia.ca, hipparch at sophia.inria.fr, reres at laas.fr,
prs at masi.ibp.fr, ieeetcpc at ccvm.sunysb.edu, comswtc at gmu.edu,
multicomm at cc.bellcore.com, giga at tele.pitt.edu, isadsoc at fokus.gmd.de,
ctc-members at redbank.tinac.com, ieee_rtc_list at cs.tamu.edu,
enternet at bbn.com, cnom at maestro.bellcore.com,
gcomlist1 at manjaro.ece.iit.edu, comsoc.bog at tab.ieee.org,
sigmedia at bellcore.com, comsoc.tac at tab.ieee.org, comsoc-gicb at ieee.org,
commsoft at cc.bellcore.com, BM-List1 at cs.ucdavis.edu,
modern-heuristics at uk.ac.mailbase.ucdavis.edu,
cellular at dfv.rwth-aachen.edu, cost237-transport at comp.lancs.ac.uk,
testnet at canarie.ca, enternet at bbn.com, ietf at CNRI.Reston.VA.US,
itc at fokus.gmd.de, multicomm at cc.bellcore.com, tccc at cs.umass.edu,
comsoc-tcii at ieee.com, dbworld at cs.wisc.edu, ieeetcpc at ccvm.sunysb.edu,
cnom at maestro.bellcore.com, commsoft at cc.bellcore.com
Sender:ietf-request at ietf.org
From: "Nicolas D. Georganas" <georgana at mcrlab.uottawa.ca>
Subject: ADVANCE PROGRAM, IEEE MULTIMEDIA SYSTEMS'97
Cc: bstarn at canarie.ca, AAitken at ocrinet.ca, PLeach at trio.ca, JYUAN at ocrinet.ca,
drynan at bnr.ca
Source-Info: From (or Sender) name not authenticated.
>>>>ADVANCE PROGRAM<<<<<<
IEEE MULTIMEDIA SYSTEMS'97
(4TH INTERNATIONAL CONFERENCE ON MULTIMEDIA COMPUTING AND SYSTEMS)
Sponsored by : IEEE Computer Society, Nortel , Newbridge, Honeywell, Telesat
June 3-6, 19=
97
Ottawa, Ontario, Can=
ada
http://www.mcrlab.uottawa.ca/ICMCS97.html
TUESDAY, JUNE 3, 1997
----------------------------------
TUTORIALS (9:00-17:30)
=46ULL-DAY Tutorials
1. MULTIMEDIA NETWORKING: QOS PRINCIPLES AND PROTOCOLS
Dr. Yoram OFEK, IBM Thomas Watson, New York.
2. BUILDING AND APPLYING DIGITAL LIBRARIES
Prof. Edward A. Fox, Virginia Tech, VA
3. MULTIMEDIA: TECHNOLOGY FOR BRINGING NEW APPLICATIONS TO
THE INTERNETWORKS
Ms. Lynne THOMPSON and Mr. Nick SMILONICH, UNISYS Corp., San
Jose.
4. IMPLEMENTATION TECHNIQUES FOR A LAN BASED VIDEO SERVER
Prof. Tzi-cker CHIUEH, SUNY Stony Brook, New York
HALF-DAY Tutorials
5. ISO MPEG-4 - A CODING STANDARD FOR MULTIMEDIA APPLICATIONS
Dr. Raj TALLURI, Texas Instruments, Dallas
6. THE GLOBAL INFORMATION INFRASTRUCTURE: EVOLUTION AND
EXPECTATIONS
Dr. Salah AIDAROUS, NORTEL, Ottawa
7. MULTIMEDIA MOBILE AUDIOVISUAL COMMUNICATION SERVICES
Prof. K.R. Rao, Univ. of Texas at Arlington, Texas
8. MULTIMEDIA DATA MANAGEMENT
Prof. Tamer OZSU, Univ. of Alberta
9. MULTIMEDIA INFORMATION SYSTEMS - PART I - IMAGE
Prof. Ramesh JAIN and Dr. A. GUPTA, Univ. of California, San D=
iego
10.MULTIMEDIA INFORMATION SYSTEMS - PART II - VIDEO
Prof. Ramesh JAIN and Dr. A. GUPTA, Univ. of California, San
Diego
11. DISTRIBUTED SEMANTIC MULTIMEDIA INFORMATION RETRIEVAL
Prof. William GROSKY, Wayne State and Prof. Venkat GUDIVADA,
U. Missouri
12. FORMAL METHODS FOR BROADBAND AND MULTIMEDIA SYSTEMS
Dr. Stefan FISCHER, U. Of Montreal, and Prof. LEUE, U. of Wate=
rloo
----------------------------------------------------------------------------
------------------------------------
TUESDAY, JUNE 3, 1997: 6:30 pm:
WELCOME RECEPTION AT THE NATIONAL MUSEUM OF CIVILIZATION AND
"ATM INTERACTIVE DANSE DEMO FROM GERMANY TO OTTAWA"
----------------------------------------------------------------------------
------------------------------------
TECHNICAL PROGRAM
WEDNESDAY, JUNE 4, 1997
OPENING REMARKS
Nicolas D. Georganas, General Chair
KEYNOTE ADDRESS (9:00-10:30)
"Hyper-Communication: Toward the Creation of New Media for the Information
Network"
Dr Ryohei Nakatsu
President
ATR Media Integration & Communications Research Laboratories
Kyoto, Japan
Session 1: Communication Protocols I (11:00-12:30)
-----------------------------------------------
Traffic Characteristics and Smoothness Criteria in VBR Video Traffic Smoothi=
ng
Junbiao Zhang, Joseph Hui; Rutgers Univ., USA
Renegotiated CBR Transmission Based on Queue Length of STB in IVOD System
Noriaki Kamiyama , Victor Li ; Univ. of Southern California, USA
A Rate Allocation Policy with MCR/PCR Support and Distributed ABR
Implementation Using Explicit Rate Feedback
Shivendra S. Panwar,Yiwei Thomas Hou, Henry H.-Y. Tzeng;
Polytechnica Univ., AT&T Bell Labs, USA
Session 2: Video Servers I (11:00-12:30)
--------------------------------
An Effective Video Block Placement Strategy on Multi-Zone Recording Disks
Jeong-Won Kim, Young-Uhg Lho, Ki-Dong Chung; Pusan National Univ., K=
OREA
A Novel Video Layout Strategy for Near-Video-on-Demand Servers,
Shenze Chen, Manu Thapar, Hewlett-Pachard, USA
On the Efficient Retrieval of VBR Video in a Multimedia Server
Sambit Sahu, Zhi-Li Zhang, Jim Kurose, Don Towsley; Univ. of
Massachusetts, USA
Session 3: Music and Distributed Cinema (11:00-12:30)
--------------------------------------------------
MusiKalscope: A Graphical Musical Instrument
Sidney Fels, Kazushi Nishimoto, Kenji Mase; ATR, JAPAN
Musical Design Patterns: An Example of a Human-Centered Model of
Interactive Multimedia
Max Muehlhaeuser, Jan Borchers; Linz Univ. , AUSTRIA
Toward the Realization of Interactive Movies "Inter Communication Theater:
Concept and System"
Ryohei Nakatsu, Naoko Tosa; ATR, JAPAN
Session 4: Communication Protocols II (14:00-15:30)
------------------------------------------------
An Optimal Dynamic Multicast Routing Algorithm for Multimedia Applications
Moonsik Kang, Magda El Zarki; Univ. of Pennsylvania, USA
Traffic Control Mechanism to Support Video Multicast over IP Networks
Ranga Ramanujan, Atiq Ahamad, Ken Thurber; Architecture Techn.
Corp., USA
An Adaptive Finding Algorithm For Introducing IP Traffic into ATM
Tulin Atmaca, B. Aygun, H. Korezlioglu; Inst. National des
Telecommunciations, Middle East Technical Univ., Ecole Nationale
Superieure de Telecom., TURKEY/FRANCE
Session 5: Video Servers II (14:00-15:30)
---------------------------------
Weighted Striping in Multimedia Servers
Yuewei Wang, David Du; Univ. of Minnesota, USA
Chaining: A Generalized Batching Technique for Video-On-Demand
Simon Sheu, Kien Hua, Wallapak Tavanapong; Univ. of Central Florida,=
USA
Evaluation of Caching Strategies for a Multimedia Storage Server
Narasimha Reddy; Texas A&M Univ., USA
Session 6: Video Content Processing (14:00-15:30)
--------------------------------------------
Video Shot Analysis Using Multiple Object Tracking
V.V. Vinod, H. Murase; NTT, JAPAN
On the Detection and Recognition of Television Commercials
Rainer Lienhart, Christoph Kuhm=FCnch, Wolfgang Effelsberg; Univ. of
Mannheim, GERMANY
A Visual Search System for Video and Image Databases
Hong-heather Yu, Wayne Wolf; Princeton Univ., USA
Session 7: Communication Protocols III (16:00-17:30)
-------------------------------------------------
Adaptive Continuous Media Applications in Mobile Computing Environment
Tatsuo Nakajima, Akihiro Hokimoto; Japan Advanced Inst. of Science
& Tech., JAPAN
Access Network Target Architecture
Zoran Petrovic, Milan Jankovic; Yugoslav PTT, Univ. of Belgrade,
JUGOSLAVIA
A Framework for Supporting Quality-Based Presentation of Continuous
Multimedia Streams
Aidong Zhang, Thomas Johnson; State Univ. of NY at Buffalo, USA
Session 8: Video Servers III (16:00-17:30)
-----------------------------------
Scheduling for Interactive Operations in Parallel Video Servers
Wei Shu, Min-You Wu, State Univ. of NY at Buffalo, USA
QuIVeR : A Quasi-static Interactive Video Retrieval Protocol for disk
array based servers
Senthil Sengodan, Victor Li, Univ. Southern California, USA
The Effect of Disk Scheduling Schemes on a Video Server for Supporting
Quality MPEG Video Accesses
Horng-Juing Lee, David Du, Univ. of Minnesota, USA
Session 9: Video and Audio Content Analysis (16:00-17:30)
--------------------------------------------------------
Adaptive Transform Domain Video Scene Analysis
Donald Adjeroh, M.C. Lee, Chinese Univ. of Hong Kong, HONG KONG
Transform-Based Indexing of Audio Data for MMDBs
S.R. Subramanya, Bhagirath Narahari, Rahuk Simha, Abdou Youssef;
George Washington Univ., USA
Enhanced Video Handling Based on Audio Analysis
Kenichi Minami, A. Akutsu, H. Hamada, Y. Tonomura; NTT, JAPAN
THURSDAY, JUNE 5, 1997
Session 10: Models for Multimedia Presentations (9:00-10:30)
------------------------------------------------------------
Toward a Generic Spatial/Temporal Computation Model for Multimedia Presentat=
ions
Timothy Shih, Anthony Chang; Tamkang Univ., TAIWAN
A New MM synchronization Specification Method for Temporal and Spatial Event=
s
Jongho Nang, Sujin Kang; Sogang Univ., KOREA
Events in Interactive MM Applications: Modeling & Implementation Design
Michael Vazirgiannis, Susanne Boll; National U niv. of Athens,
Univ. of Ulm, GREECE/GERMANY
Session 11: Video Servers IV (9:00-10:30)
------------------------------------
Improving Reliability of Distributed VoD Servers
Manuel Billot, Isabelle Puaut, Valerie Issarny, Michel Banatre,
IRISA, INSA, INRIA, Thomson MM, FRANCE
A Bandwidth Management Technique for Hierarchical Storage in Large-Scale
Multimedia Servers
Kien A. Hua, James Wang; Univ. of Central Florida, USA
Performance Evaluation of the Stony Brook Video Server
T. Niranjan, Tzi-cker Chiueh, Gerhard Schloss; SUNY at Stony Brook, =
USA
Session 12: Editing MPEG Streams (9:00-10:30)
---------------------------------------------
Editing Techniques for MPEG Multiplexed Streams
Venkat Rangan, Kamlesh Talreja; Univ. of California at San Diego,
Tata Consultancy Services, USA
Closed-Loop MPEG Video Editing
Bo Shen, Ishwar Sethi, Vasudev Bhaskaran; Wayne Univ., HP Labs, USA
Session 13: Quality of Service (11:00-12:30)
------------------------------------
Stefan Fischer, Cooperative QoS Management for Multimedia Applications
Abdelhakim Hafid, Gregor Bochmann, Hermann de Meer; Univ. de
Montreal, Univ. of Hamburg, CANADA / GERMANY
Specifying QoS and Synchronisation Using an Extended Estelle
Richard Lai, T. Tsang; La Trobe Univ., AUSTRALIA
QoS Negotiation and Resource Reservation for Distributed Multimedia Applicat=
ions
Walter Fiederer, Kurt Rothermel, Gabriel Dermler, Univ. of
Stuttgart, GERMANY
Session 14: Multimedia Database Systems (11:00-12:30)
----------------------------------------------------
Optimization of Adaptive Data-Flows for Competing Multimedia
Presentational Database Sessions
Heiko Thimm, W. Klas, C. Cowan, J. Walpole, C. Pu; T.U. Darmstadt,
Univ.Ulm, Oregon Grad. Inst. of Science & Technology, GERMANY/ USA
Modeling of Moving Objects in a Video Database
John Li, Tamer Ozsu, Duane Szafron, Univ. of Alberta, CANADA
VideoText Database Systems
Haitao Jiang, Danilo Montesi, Ahmed Elmagarmid; Purdue Univ., Univ.
of East Anglia, Univ. de Milano, USA/ ITALY
Session 15: Still Image Content Processing I (11:00-12:30)
-----------------------------------------------------
IFQ: A Visual Query Interface and Query Generator for Object-based Media
Retrieval
Wen-Syan Li, K. Selcuk Candan, Kyoji Hirata, Yoshi Hara; NEC USA
=46ast Signature-based Color-Spatial Image Retrieval
Kian-Lee Tan, Tat-Seng Chua, Beng-Chin Ooi; National Univ. of
Singapore, SINGAPORE
Shape Indexing by Structural Properties
Alberto Del Bimbo, P. Pala; Universita di Firenze, ITALY
Session 16: Multimedia Synchronization I (14:00-15:30)
--------------------------------------------------
A Pre-scheduling Mechanism for Multimedia Presentation Synchronization
Tae Il Jeong, Jae Wook Ham, Sung Jo Kim; Chung-Ang Univ., KOREA
Client Based Synchronization Control of Coded Data Streams
Mourad Daami, Nicolas Georganas; Univ. of Ottawa, CANADA
Synchronization of Multimedia Streams in Distributed Environments
Hussein Abdel-Wahab, Emilia Stoica, Kurt Maly; Old Dominion Univ., U=
SA
Session 17: Operating System Support for Multimedia I (14:00-15:30)
-------------------------------------------------------------------
SMART UNIX SVR4 Support for Multimedia Applications
Jason Nieh, Monica Lam; Stanford University, Sun Labs, USA
Virtual Memory Management for Interactive Continuous Media Applications
Tatsuo Nakajima, Hiroshi Tezuka; Japan Advanced Inst. of Science &
Tech., JAPAN
GRMS: A Global Resource Management System for Distributed QoS and
Criticality Support
Jiandong Huang, Y. Wang, N.R. Vaidyanathan, F. Cao; Honeywell , USA
Session 18: Still Image Content Processing II (14:00-15:30)
------------------------------------------------------
A Line String Image Representation for Image Storage and Retrieval
Wen-Chen Hu, Gerhard Ritter; Univ. of Florida, USA
Color Clustering Techniques for Color-Content-Based Image Retrieval from
Image Databases
Jia Wang, Wen-jann Yang, Raj. Acharya, State Univ. of NY at Buffalo,=
USA
Session 19: Multimedia Synchronization II (16:00-17:30)
---------------------------------------------------
Designing a Distributed Multimedia Synchronization Scheduler
Jerzy Jarmasz, Nicolas Georganas; Univ. of Ottawa, CANADA
Playback Restart in Interactive Streaming Video Applications
Jayanta K. Dey, Subhabrata Sen, James F. Kurose, Don Towsley, James
D. Salehi; Univ.Massachusetts, USA
Shared Media Space Coordination: Mixed Mode Synchrony in Collaborative
Multimedia Environments
Wayne Robbins, Nicolas Georganas; Univ. of Ottawa, CANADA
Session 20: Operating System Support for Multimedia II (16:00-17:30)
---------------------------------------------------------------------
Schedulatility Analysis for Desktop Multimedia Applications: Simple Ways to
Handle General-Purpose Operating Systems and Open Environments
Erik Cota-Robles, James P. Held, Thomas J. Barnes; Intel, USA
A Proportional-Share Scheduler for Multimedia Applications
Hyogun Lee, Manhee Kim, Joonwon Lee; Korean Advanced Inst. of
Science & Technology, KOREA
A Multimedia Document Filing System,
Xien Fan, Qianhong Liu, Peter Ng; New Jersey Inst. of Technology, US=
A
Session 21: Coding and Compression (16:00-17:30)
---------------------------------------------
Progressive Compression of 3D Graphic Models
Jiankun Li, C.-C. Jay Kua, Jin Li; USC, Sharp Labs, USA
A Quadtree-based Image Encoding Scheme for Real-Time Communication
Hussein Abdel-Wahab, Samah Senbel ; Old Dominion Univ., USA
A Realtime Video-image Mapping Using Polygon Rendering Techniques
Tsuneo Ikedo; Univ. of Aizu, JAPAN
=46RIDAY, JUNE 6, 1997
Session 22: Multimedia Applications (9:00-10:30)
--------------------------------------------
A System for Customized News Delivery from Video Archives
Gulrukh Ahanger, T.D.C. Little, Boston Univ., USA
ATM RendezView: Multipoint Conferencing on ATM
Keith Smith, Russell Pretty, Peter Ashton, Nicolas Georganas;
Nortel, Univ, of Ottawa, CANADA
JETS: A Java-Enabled Telecollaboration System
Shervin Shirmohammadi, Nicolas Georganas; Univ. of Ottawa, CANADA
Session 23: Hypermedia Systems (9:00-10:30)
----------------------------------------
Link Management Framework for Hyper-Media Documents
Dragos-Anton Manolescu, Klara Nahrstedt; Beckman Inst., Univ. of
Illinois at Urbana- Champaign, USA
Evaluation of Multimedia Components
Francisco Ficarra; IUA Pompeu Fabra Univ., Polytechnical Univ. of
Catalonia, SPAIN
A Scalable and Distributed WWW Proxy System
Eddie Law, B. Nandy, A. Chapman, Nortel, CANADA
Session 24: Virtual Reality (9:00-10:30)
-------------------------------
Virgilio: A Non-Immersive VR System to Browse Multimedia Databases
Antonio Massari, Lorenzo Saladini, Matthias Hemmje, Fabio Sisinni;
Univ. of Rome, GMD, ITALY/GERMANY
Toward Next Generation Virtual Reality Systems
Jurgen Landauer, Roland Blach, Matthias Bues, Angela Rosch, Andreas
Simon, VISLab Fraunhofer IAO, GERMANY
MARTI: Man-machine Animation Real-Time Interface
Christian Martyn Jones, Satnam Singh Dlay; Univ. of Newcastle upon
Tyne, UK
POSTER SESSION (WEDNESDAY , JUNE 4 and THURSDAY, JUNE 5, 1997)
---------------------------
MAESTRO: A CORBA-Based Multimedia System for Video/Audio Conferencing
James W. Hong , Tae-Hyoung Yun, Ji-Young Kong; Pohang Univ. of
Science & Technology, KOREA
ICute: Interactive Scheduling Supports for Real-time Multimedia Execution
Wynne Hsu, Teik Guan Tan; National Univ. of Singapore, SINGAPORE
Agent-based Communication System Built on Telescript Platform - The
Application to Paseo Service and Experiments
Eikazu Niwano, K. Okamoto, K. Sakanoue, H. Otaka, M. Katsumata, K.
Maeda; NTT, JAPAN
Novel Scene Generation, Merging and Stitching Views Using the 2D Affine Spac=
e
Jun Ohya, Kuntal Sengupta; ATR, JAPAN
A Scheduling Algorithm for Retrieval and Replay of Interactive Multimedia
Objects
Neena Pahuja, Bijendra Jain, Gautam Shroff; IIT , INDIA
Introducing multi-user hypertextual glossaries in a hypermedia-based
learning environment Marco Costantino, Luigi Colazzo; Univ. of
Durham, Univ. of Trento, UK /ITALY
Call Admission Optimization and Dynamic QoS Management of Networked
Multimedi Flows through Multilevel QoS and Traffic Contract Models
Ali Marefat; Univ. of Versailles, FRANCE
Instant Authoring with Application Output Recording:Taxonomy and usage in DI=
ANE
Rolf Mecklenburg, Hartmut Benz, Steffan Fischer; Univ. of
Stuttgart, GERMANY
The AudioWeb
Daniel Barbara, Shamim Naqvi; Bellcore, USA
Tracking Deformable Objects with the Active Contour Model
Yuh-Lin Chang, Yun-Ting Lin; Panasonic, JAPAN
Metrics for Scene Change Detection in Digital Video Sequences
Ralph Ford, Craig Robson, Daniel Temple, Michael Gerlach; The
Pennsylvania State Univ.; IBM; Intel, USA
Performance Comparison of Video Transport over ATM and ServerNet Interconnec=
ts
Ashfaq Hossain, Sung-Mo Kang, Bob Horst; Univ. of Illinois at
Urbana-Champaign; Tandem Computers Inc., USA
Experiments In Simple One-Dimensional Lossy Image Compression Schemes
Xiaobo Li, Joseph Modayi, Howard Cheng; Univ. of Alberta;
Motorola, CANADA
IMcast: An Object-Oriented Tool for Image Multicasting
Philip McKinley, Eric Kass; Michigan State Univ., USA
VBR MPEG over ATM : An integrated QoS control approach
Ahmed Mehaoua, Raouf Boutaba, Guy Pujolle; CRIM; Univ. de
Versailles, CANADA/FRANCE
Software Channels: A Distributed Object-Communication Mechanism
Toshimi Minoura, Chukiat Worasucheep; Oregon State Univ., USA
Aggressive Admission Control Algorithms for Multimedia Servers
Prasant Mohapatra, Xiaoye Jiang; Iowa State Univ., USA
Design and Evaluation of a Distributed Multimedia Synchronization Algorithm
using Media Scaling and Variable Service Rates
Mukesh Singhal, Ihn- Han Bae; Ohio State Univ.; Catholic Univ. of
Taegu-Hyosung, USA/KOREA
An Objective Approach to Assessing Relative Perceptual Quality of
MPEG-Encoded Video Sequences
Lee Wang, Ranga Ramanujan, James Newhouse; Maher Kaddoura, Atiq
Ahamad, Kenneth Thurber, Howard Siegel; Purdue Univ.; Architecture
Technology Corp.,USA
Speech Recognition on MPEG/Audio Encoded Files
Lawrence Yapp, Gregory Zick; Univ. of Washington, USA
Metadatabase and Search Agent for Multimedia Database Access over Internet
Aidong Zhang1, Wendy Chang; Deepak Murthy; Yousong Mei; State Univ.
of NY at Buffalo, USA
Implementation and Performance Issues in an Object-Oriented Orchestration
Architecture
Wayne Robbins; Univ. of Ottawa, CANADA
An Architecture for Multimedia over ATM Real-Time Environments
Voicu Groza, Dan Ionescu, Nicolas Georganas, Univ. of Ottawa, CANADA
Cooperative Use of HyTime and MHEG in Hypermedia Environments
Lloyd Rutledge, Jacco van Ossenbruggen, Lynda Hardman, Dick
Bulterman; CWI, De Boelelaan, NETHERLANDS
Generic and Fully Automatic Content-Based Image Retrieval Architecture,
Vijay V. Raghavan, Suresh K Choubey; University of Southwestern
Louisiana, USA
Supporting Content-based Queries over Images in MARS
Sharad Mehrotra, Yong Rui, Michael Ortega-Binderberger, Thomas
Huang; Univ. of Illinois at Urbana-Chanpaign, USA
Modelling Statis and Dynamic Aspects of Hypermedia Systems
Fivos Panetsos, Paloma Diaz, Ignacio Aedo; Univ. Carlos III de
Madrid, Univ. Nacional de Educacion a Distancia, SPAIN
Browsing and Placement of Multiresolution Images on Secondary Storage
Sunil Prabhakar, D. Agrawal, A. El-Abbadi, A. Singh, T. Smith;
Univ. of California at Santa Barbara, USA
Cadmus: An Exercise on Sclable and Deterministic Video Servers
Feng Shi; Cambridge Univ., UK
MR BRAQue: a Multimedia Medical Report Managent System
Paolo Merialdo, G. Sindoni; Univ. degli Studi di Roma Tre, ITALY
Supporting Continuous Media: Is Serial Storage Architecture (SSA) Better
Than SCSI?
Sangyup Simon Shim, Taisheng Chang, Yuewei Wang, Jenwei Hsieh,
David H.C. DU; Univ. of Minnesota, USA
Creating a Virtual Network Laboratory
Yen-Jen Lee, Wei-hsiu Ma, David Du, James Schnepf; Univ. of
Minnesota, St. John's Univ., USA
MADEUS: an Authoring Environment for Interactive Multimedia Documents
Muriel Jourdan, Nabil Layaida, Loay Sabry-Ismail; INRIA, FRANCE
PCR-Assist CBR for Delivering Pre-Recorded MPEG-2 Transport Streams
Jenwei Hsieh, D. Du, HJ Lee, T. Chang; Univ. of Minnesota, USA
A CORBA-based Real-Time Stream Service for ATM Networks
H K Pu ng, Bhawani Sapkota, Lek Heng Ngoh, Lawrence Wong; National
Univ. of Singapore, SINGAPORE
Multimedia Presentation Techniques for Interactive Plots
N.M. Sgouros, P. Tsanakas and G. Papakonstantinou; National Tech.
Univ. of Athens, GREECE
PENGUIN - Enabling and Combining DAVIC and the WWW
Petra Hoepner, Reinhard Baier, Christian Gran, Klaus Hofrichter,
Angela Scheller; GMD, GERMANY
Multimedia Information Systems Applications - A taxonomy and three case stud=
ies
Schahram Dustdar; University of Art and Industrial Design, AUSTRIA
Dynamic QoS Management For Real-time Communication In ATM Networks
Chye-Lin Chee; National Univ. of Singapore, SINGAPORE
----------------------------------------------------------------------------
--------------------------------------
Conference Registration Form
IEEE Multimedia Systems'97
June 3-6, 1997
Your Web browser should have a command to dump this file as text to a local
file. Please PRINT this form, fill it out,
and mail or fax this form with your payment to:
IEEE MULTIMEDIA SYSTEMS'97- Registration
Ottawa Carleton Research Institute (OCRI)
340 March Road, Suite 400
Kanata, Ont. , Canada K2K 2E4
fax: +1-613-592-8163
for information on registration, contact Amy Riordon-Jarette
+1-613-592-8160 Ext 224
Last Name _____________________________________
=46irst Name _____________________________________
Middle Initial _____________________________________
=46irm _____________________________________
Department ____________________________________
Address _____________________________________
City _____________________________________
State/Province ____________ ZIP ______________ Country ___________
Phone _________________
=46ax _________________
Email _________________
IEEE/CS membership number _________________
Do you have any special needs? ___________________________________________
Conference (all prices in Can$; 1USD=3D 1.35 CAD approximately):
Advance Registration Late Registration
(Until May 1st, 1997) (After May 2nd, 1997)
[ ] IEEE Member: $500 [ ] IEEE Member: $600
[ ] Nonmember: $625 [ ] Nonmember: $750
[ ] Full-Time Student: $400 [ ] Full-Time Student: $450
Tutorials (Full Day):
[ ] IEEE Member: $400 [ ] IEEE Member: $480
[ ] Nonmember: $500 [ ] Nonmember: $600
Tutorials (Half Day):
[ ] IEEE Member: $200 [ ] IEEE Member: $240
[ ] Nonmember: $250 [ ] Nonmember: $300
Select the tutorial you would like to attend:
=46ULL-DAY Tutorials Monday, June 3rd, 1997.
[ ] 1. MULTIMEDIA NETWORKING: QOS PRINCIPLES AND PROTOCOLS
[ ] 2. BUILDING AND APPLYING DIGITAL LIBRARIES
[ ] 3. MULTIMEDIA: TECHNOLOGY FOR BRINGING NEW APPLICATIONS TO THE
INTERNETWORKS
[ ] 4. IMPLEMENTATION TECHNIQUES FOR A LAN BASED VIDEO SERVER
HALF-DAY Tutorials Monday, June 3rd, 1997.
[ ] 5. ISO MPEG-4 - A CODING STANDARD FOR MULTIMEDIA APPLICATIONS
[ ] 6. THE GOLBAL INFORMATION INFRASTRUCTURE: EVOLUTION AND EXPECTATIONS
[ ] 7. MULTIMEDIA MOBILE AUDIOVISUAL COMMUNICATION SERVICES
[ ] 8. MULTIMEDIA DATA MANAGEMENT
[ ] 9. MULTIMEDIA INFORMATION SYSTEMS - PART I - IMAGE
[ ] 10. MULTIMEDIA INFORMATION SYSTEMS - PART II - VIDEO
[ ] 11. DISTRIBUTED SEMANTIC MULTIMEDIA INFORMATION RETRIEVAL
[ ] 12. FORMAL METHODS FOR BROADBAND MULTIMEDIA SYSTEMS
Total enclosed: _____________________
Method of Payment:
1. Personal cheque - (payable to OCRI - Multimedia Systems '97)
2. Company cheque - (payable to OCRI - Multimedia Systems '97)
3. American Express
4. Visa
5. MasterCard
Cardholder Name ____________________________
Card Number ____________________________
Expiration Date ____________________________
Signature ____________________________
Payment must accompany registration form. Forms received without payment
will NOT be processed.
All persons attending IEEE MMS'97 will be required to register. PRESENTING
AUTHORS MUST REGISTER BY APRIL 15, 1997. Full conference registration
includes conference attendance, refreshment at
breaks, two luncheons, the conference reception, the conference banquet,
and one copy of the conference proceedings.
Written requests for refunds must be received in the OCRI office no later
than May 15, 1997. Refunds are subject to a $50 processing fee. All
no-show registrations will be billed in full. Full-time students are
required to show current picture ID cards at the time of registration.
Registrations after June 1, 1997 will be accepted on site only. On-site
registration will be available through the conference.
----------------------------------------------------------------------------
---------------------------------------
CONFERENCE HOTEL
The conference will be held in Ottawa at the Chateau Laurier Hotel. The
Chateau Laurier Hotel has been an Ottawa Landmark serving guests in
elegant,
heritage surroundings since 1912.
Being conveniently located within walking distance of Parliament Hill, the
main downtown business district, the Byward Market area for dining and
entertainment and major museums and attractions such as the National Arts
Centre, The National Art Gallery, and the Rideau Shopping Centre.
The Chateau Laurier can meet the business or pleasure needs of its' guests.
In addition to the elegant dining in Wilfrid's Restaurant or the relaxed
entertainment of Zoe's Lounge, the Chateau Laurier offers recreational
facilities including a large indoor pool, sauna, steam rooms and exercise
room.
Hotel Reservations
Chateau Laurier Hotel
1 Rideau Street
Ottawa, Ontario K1N 8S7
Canada
Tel: 1-613-241-1414 or 1-800-441-1414 (toll free)
=46ax: 1-613-562-7031
Room Rate $140.00 CAD (approximately $100 USD) single or double. Taxes extra=
.
Room reservations should be made under the name IEEE Multimedia Systems'97
in order to secure the
group rate given above. Room Release Date: April 30, 1997. Any rooms not
reserved at that time will be
released for general sale to the public. Additional rooms for IEEE
Multimedia Systems'97 will be accepted
on a space and rate availability basis.
Received: from ietf.org by ietf.org id aa02792; 13 Mar 97 14:54 EST
Received: from callandor.cybercash.com by ietf.org id aa02718;
13 Mar 97 14:52 EST
Received: by callandor.cybercash.com; id OAA05630; Thu, 13 Mar 1997 14:43:17 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma005584; Thu, 13 Mar 97 14:42:48 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA15638; Thu, 13 Mar 97 14:45:56 EST
Date: Thu, 13 Mar 1997 14:45:55 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Export restrictions (Re: call for a new email infrastructure)
In-Reply-To: <199703130635.BAA13080 at ig.cs.utk.edu>
Message-Id: <Pine.SUN.3.91.970313085423.5979B-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Keith,
Note that I said schemes, not code. In particular, very recent experience
indicates that for authentication only you can export binary *and* you can
export source complete with all the crypto calls (see
<http://www.tis.com/docs/research/network/dns.html> for what may be the only
example), you just can't export the crypto source itself. This is usually a
non-issue since you can get crypto source almost anywhere in the world.
Since all of this is at the aribtrary discretion of the authorities, your
mileage may vary.
I don't know that the IETF list is an appropriate place for the discussion of
US government export regulation details but I felt that the message I was
responding to (which you have excised completely) was so totally wrong and
confused that some reponse was called for. My response, not being a
multi-page treatise because I was trying to provide a very brief correction,
did not attempt to fully explain all the details.
On Thu, 13 Mar 1997, Keith Moore wrote:
> Date: Thu, 13 Mar 1997 01:35:00 -0500
> From: Keith Moore <moore at cs.utk.edu>
> To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
> Cc: ietf at ietf.org, moore at cs.utk.edu
> Subject: Re: Export restrictions (Re: call for a new email infrastructure)
>
> > There are no special munitions type export retrictions from the US for
> > authentication only schemes, using RSA or other systems, with keys of any
> > length. There are such restrictions on confidentiality systems. (And there
> > are a few countries to which all exports from the US require special
> > permission.)
>
> You mean I can export source code to the RSA algorithm as long as
> the code is only used to do authentication? Great!
No, but since the RSA source code is available almost everywere, why is
that important? Being able to export all the rest of the authentication
source, including the crypto calls, seems adequate.
> Keith
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from cnri by ietf.org id aa02915; 13 Mar 97 14:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18722;
13 Mar 97 14:59 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA19733 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 16:47:48 GMT
Message-Id: <199703131647.LAA11723 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: SNEGO Last-Call proposed [Was Re: Comments solicited...]
In-Reply-To: Your message of "Thu, 06 Mar 1997 09:31:38 EST."
<199703061431.JAA02485 at gza-client1.cam.ov.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 13 Mar 1997 11:47:43 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Reviewing current status per the attached message and subsequent responses:
Carlisle Adams and Derrell Piper stated their recollections that the
previously-agreed consensus was to proceed with Last-Call on snego-02
unless an alternate proposal for protected negotiation was offered by a
specific, and now past, deadline.
Dennis Glatting suggested that snego should proceed to informational
or experimental status.
On 11 March, Peter Brundrett offered an "optimistic snego" extension
option proposal, building on the basic snego proposal.
I believe that Carlisle's/Derrell's assessment is accurate, and that
the document was being considered in the context of a prospective
standards-track specification, and therefore believe that the consistent
action at this time is to initiate WG Last-Call on snego-02 for advancement
to Proposed Standard. I propose, therefore, that we initiate a WG Last-Call
period on this document, to extend through Friday, 28 March, with Peter
Brundrett's proposal to be considered within that Last-Call. Does
anyone disagree with this assessment or object to this approach?
--jl
> CAT/negotiated mechanism-interested people:
>
> When Simple Negotiation (draft-ietf-cat-snego-02.txt) was discussed at the
> San Jose meeting, controversy arose around interest in development of an
> alternate proposal which would apply protection to the negotiation process.
> The working plan of record, as cited in the San Jose minutes, was that
> an alternate proposal would be defined and circulated in January for
> group comparison with SNEGO in February, at which point the group would
> consider an advancement recommendation. I believe that there's group
> consensus on the value of advancing a negotiated mechanism, but the
> alternate proposal contemplated at San Jose has not yet emerged.
>
> Shall we proceed to WG Last-Call on advancement of draft-ietf-cat-snego-02.txt
> to Proposed Standard, is alternate proposal development active with a
> new target date, and/or does anyone have other suggestions or preferences
> to offer as to how the group should now proceed in this area? I'd appreciate
> any comments to the list by Friday, 14 March.
>
> Thanks,
>
> --jl
>
>
>
>
Received: from ietf.org by ietf.org id aa03392; 13 Mar 97 15:06 EST
Received: from mail.cno.com.br by ietf.org id aa03311; 13 Mar 97 15:05 EST
Received: by mail.cno.com.br (AIX 3.2/UCB 5.64/4.03)
id AA11079; Thu, 13 Mar 1997 17:04:19 -0400
Received: from unknown(10.1.0.25) by mail.cno.com.br via smap (V1.3)
id sma015148; Thu Mar 13 17:03:14 1997
Received: from canario.dpabr.cno.com.br by dsbr01.dpabr.cno.com.br (AIX 3.2/UCB 5.64/4.03)
id AA27005; Thu, 13 Mar 1997 17:03:42 -0400
Message-Id: <9703132103.AA27005 at dsbr01.dpabr.cno.com.br>
X-Mapi-Messageclass: IPM
Priority: Normal
To: klensin at mci.net
Cc: ietf at ietf.org
X-Mailer: FTP Software Internet Mail 2.0
Mime-Version: 1.0
Sender:ietf-request at ietf.org
From: Luiz Sergio Canario <canario at cno.com.br>
X-Orig-Sender: Luiz Sergio Canario <canario at cno.com.br>
Subject: RE: RE: call for a new email infrastructure
Date: Thu, 13 Mar 1997 17:08:00 -0300
Content-Type: text/plain; charset=ISO-8859-1; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
John
You are right. Thank you for change my point of view. I was=20
only seeing the fact of many US citizens think that=20
Internet exist only in and for the USA.
One more time, thank you!
Regards
>>
>>On Thu, 13 Mar 1997 12:08:07 -0300 Luiz Sergio Canario=20
>><canario at cno.com.br> wrote:
>>
>>> I wiuld like to remember all of you that any law,=20
>>> constitutional or not, in the USA, have any efects=20
outside=20
>>> USA. So it should not be discussed in terms of laws.
>>
>>Luiz,
>>
>>I think there are two issues here that are not "US=20
law"...
>>
>>(i) There are efforts in progress in several countries=20
to=20
>>make Internet providers responsible for the traffic they=20
>>carry. Complying with such regulations would require=20
>>solving almost insurmountable technical problems. =20
However,=20
>>if it is possible for a country to ban pornography=20
crossing=20
>>into its country on the Internet and for it to enforce=20
that=20
>>ban, then it is probably about equally possible to ban=20
spam=20
>>(or unsolicited email more generally).
>>
>>(ii) Organizations like the ITU can, and have, created=20
>>"recommendations" that are treated by most countries as=20
>>having treaty status, i.e., the force of law. And other=20
>>sorts of international agreements among countries (and,=20
>>modulo regulations in some countries that constrain=20
>>agreements among competitors at least without government=20
>>approval, among ISPs) are, of course, possible.
>>
>>That said, at least to this point, a large fraction of=20
the=20
>>"spam"-type email that actually involves trying to sell=20
>>things or to get people to send money originate from the=20
US=20
>>or are sponsored or promoted by US-based individuals or=20
>>organizations. If we could stop them, or make their=20
>>businesses appreciably more troublesome or costly to=20
carry=20
>>on, by domestic action in the US, we would make a huge=20
dent=20
>>in the problem.=20
>>
>>That is not the case with bulk unsolicited email used to=20
>>annoy, to show off capabilities, or to deny service --=20
like=20
>>all other acts of vandalism, these are extremely hard to=20
>>detect, isolate, and either prevent or punish in=20
effective=20
>>ways.
>>
>> john
>>
>>
>>
>>End of message
Luiz Sergio P. Can=E1rio
Construtora Norberto Odebrecht SA
Tel. 55 21 536 3875
Fax. 55 21 536 3495
e-mail: canario at cno.com.br
Received: from cnri by ietf.org id aa04117; 13 Mar 97 15:11 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19083;
13 Mar 97 15:11 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA17798 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 16:06:56 GMT
Date: Thu, 13 Mar 1997 11:06:44 -0500 (EST)
From: Rich Salz <rsalz at osf.org>
Message-Id: <199703131606.LAA10596 at sulphur.osf.org>
To: johnn at dascom.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Cc: cat-ietf at mit.edu
Precedence: bulk
> I would assert that:
> Applications should not embed security policy or mechanisms. Rather
> policy should be set and mechanisms selected by the administrators of
> the site/system/domain that meet there needs.
>
> Is there at least general agreement on this point?
No. There are applications that will need to embed their own policy
and mechanism. For example, login programs that must be able to "trust"
the network before granting local acess. The analogy I'd draw is that
some programs need mechanism to set their own dynamic library load path...
/r$
Received: from cnri by ietf.org id aa06926; 13 Mar 97 16:43 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21123;
13 Mar 97 16:43 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA27468 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 19:47:57 GMT
Date: Thu, 13 Mar 1997 14:47:52 -0500
Message-Id: <9703131947.AA04612 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Marc Horowitz <marc at cygnus.com>
Cc: cat-ietf at mit.edu
In-Reply-To: Marc Horowitz's message of 13 Mar 1997 01:28:56 -0500,
<t534teguwyf.fsf at rover.cygnus.com>
Subject: Re: kerb-chg-password
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Marc Horowitz <marc at cygnus.com>
Date: 13 Mar 1997 01:28:56 -0500
Again, since updates are idempotent, this is not an issue. Once you
receive the request, create a transaction/update/commit, then reply.
If the client doesn't receive the ack, no harm is done, because the
retry will not change any state.
Does this imply that the server has to keep a cache of responses so it
can resend the ack? Or does the server send a "wrong password" error,
which the client then has to try to decipher?
- Ted
Received: from cnri by ietf.org id aa07541; 13 Mar 97 17:18 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21979;
13 Mar 97 17:18 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA29920 at pad-thai.cam.ov.com>; Thu, 13 Mar 1997 20:47:20 GMT
To: Marc Horowitz <marc at cygnus.com>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703120927.aa26530 at ietf.org> <xofybbtuhvu.fsf at blubb.pdc.kth.se> <t53rahksjyd.fsf at rover.cygnus.com> <xofu3mgv2cq.fsf at blubb.pdc.kth.se> <t534teguwyf.fsf at rover.cygnus.com>
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Johan Danielsson <joda at pdc.kth.se>
Date: 13 Mar 1997 21:46:54 +0100
In-Reply-To: Marc Horowitz's message of 13 Mar 1997 01:28:56 -0500
Message-Id: <xofrahjv7sx.fsf at blubb.pdc.kth.se>
Lines: 8
X-Mailer: Gnus v5.4.24/Emacs 19.34
Precedence: bulk
Marc Horowitz <marc at cygnus.com> writes:
> What it says is that if you implement Kerberos, you must implement
> this protocol, too. At least that's what I intended.
This makes this an update of, rather than a complement to, 1510?
/Johan
Received: from ietf.org by ietf.org id aa20035; 14 Mar 97 0:39 EST
Received: from servo.qualcomm.com by ietf.org id aa19673; 14 Mar 97 0:28 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.8.5/1.4/8.7.2/1.9) id VAA22666; Thu, 13 Mar 1997 21:24:52 -0800 (PST)
Date: Thu, 13 Mar 1997 21:24:52 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199703140524.VAA22666 at servo.qualcomm.com>
To: paulh at imc.org
CC: ietf at ietf.org
In-reply-to: <v03101f00af4dde06451b at [165.227.249.100]> (message from Paul Hoffman on Thu, 13 Mar 1997 08:53:30 -0800)
Subject: Re: call for a new email infrastructure
Source-Info: From (or Sender) name not authenticated.
>Receiver filtering today is only available to skilled people with the time
>to implement it for themselves. I'd like to see methods (technical and/or
>legal) be put into place to make receiver filtering easier for everyone.
Sounds like a business opportunity for someone! Maybe it could be
supported by advertising (just kidding).
I hold to my position that the legal approach to spam is, at best,
useless. The Internet is international in scope, it is already very
easy for people to hide, and the whole legal justice system is
notoriously slow, expensive and overworked -- and often heavy-handed
and unfair when it does function.
In particular, the law is much like a powerful antibiotic that has
been so overused for minor ailments that significant resistance has
now developed. And now it no longer works reliably even in those rare
cases where its use is clearly justified. Like football celebrities
committing premeditated double murders...
Let's give the technical approaches a serious go before we give up.
And if we can't completely solve the spam problem, that'll be
something I'll just have to accept in exchange for access to one of
the most powerful communication mediums ever made. Sure, spam is
annoying, but junk snail mail is even more so. It certainly takes more
effort to throw away.
Phil
Received: from ietf.org by ietf.org id aa21130; 14 Mar 97 1:31 EST
Received: from netcom16.netcom.com by ietf.org id aa21049; 14 Mar 97 1:29 EST
Received: (from rjames at localhost) by netcom16.netcom.com (8.6.13/Netcom)
id WAA27931; Thu, 13 Mar 1997 22:26:20 -0800
Date: Thu, 13 Mar 1997 22:26:19 -0800 (PST)
Sender:ietf-request at ietf.org
From: Richard James <rjames at netcom.com>
Subject: Re[cycle]: call for a new email infrastructure
To: Phil Karn <karn at qualcomm.com>
cc: ietf at ietf.org
In-Reply-To: <199703140524.VAA22666 at servo.qualcomm.com>
Message-ID: <Pine.3.89.9703132228.A26618-0100000 at netcom16>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 13 Mar 1997, Phil Karn wrote:
[snip]
> annoying, but junk snail mail is even more so. It certainly takes
more > effort to throw away.
Phil,
you are right about the effort required, but remember the impact of
throwing away all of that paper.
Recycle!
Better yet, get off of those mailing lists you wish to not be on.
Send a letter or post card to:
Mail Preference Service
Direct Marketing Association
P.O. Box 9008
Farmingdale, NY, 11735-9008.
Ask to have your name and address removed from the mailing lists of their
members.
...and now back to the regularly scheduled discussion on meeting planning.
:-)
rj
Received: from ietf.org by ietf.org id aa23796; 14 Mar 97 3:44 EST
Received: from duke.usask.ca by ietf.org id aa23632; 14 Mar 97 3:41 EST
Return-Path: <andrew at duke.usask.ca>
Received: from localhost (andrew at localhost)
by duke.usask.ca (8.8.5/8.8.5) with SMTP id CAA25002
for <ietf at ietf.org>; Fri, 14 Mar 1997 02:38:45 -0600 (CST)
Date: Fri, 14 Mar 1997 02:38:45 -0600 (CST)
Sender:ietf-request at ietf.org
From: Derek Andrew <andrew at duke.usask.ca>
To: ietf at ietf.org
Subject: Authenticated Mail
Message-ID: <Pine.OSF.3.95.970314023613.2149A-100000 at duke.usask.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Are there any plans in the future of the Internet for Authenticated Mail?
I am really getting tired of "spammers" sending me email, and hiding the
address of the sender.
This means I should be able to refuse all email in which the sender could
not be verified.
Thanks for your comments.
derek.andrew at usask.ca
Received: from ietf.org by ietf.org id aa25378; 14 Mar 97 4:38 EST
Received: from proxy1.ba.best.com by ietf.org id aa25240; 14 Mar 97 4:36 EST
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.8.5/8.8.3) with SMTP id BAA15864 for <ietf at ietf.org>; Fri, 14 Mar 1997 01:28:40 -0800 (PST)
Date: Fri, 14 Mar 1997 01:28:39 -0800 (PST)
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
X-Sender: boo at shellx.best.com
To: ietf at ietf.org
Subject: Re: Authenticated Mail
In-Reply-To: <Pine.OSF.3.95.970314023613.2149A-100000 at duke.usask.ca>
Message-ID: <Pine.SGI.3.95.970314011806.841A-100000 at shellx.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 14 Mar 1997, Derek Andrew wrote:
> Are there any plans in the future of the Internet for Authenticated Mail?
> I am really getting tired of "spammers" sending me email, and hiding the
> address of the sender.
>
> This means I should be able to refuse all email in which the sender could
> not be verified.
It would also be a great help if mail arriving bcc'd would indicate which
email address it came in under. When I receive spam, I have no way of knowing
whether it came via my ISP account/domain or via one of my custom domain name
addresses. Thus, I don't even know what name to ask to have removed!
-Walter
Eudora Pro 3.0 user, but procmail-challenged
__________________________________________________________________________
Walter Ian Kaye <boo at best.com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
Received: from cnri by ietf.org id aa28686; 14 Mar 97 7:22 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08142;
14 Mar 97 7:22 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <KAA25157 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 10:28:23 GMT
Message-Id: <3329A6D8.67C9 at frcl.bull.fr>
Date: Fri, 14 Mar 1997 11:28:24 -0800
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: John Linn <linn at cam.ov.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SNEGO Last-Call proposed
References: <199703131647.LAA11723 at gza-client1.cam.ov.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
John Linn wrote:
>
> Reviewing current status per the attached message and subsequent responses:
>
> Carlisle Adams and Derrell Piper stated their recollections that the
> previously-agreed consensus was to proceed with Last-Call on snego-02
> unless an alternate proposal for protected negotiation was offered by a
> specific, and now past, deadline.
>
> Dennis Glatting suggested that snego should proceed to informational
> or experimental status.
>
> On 11 March, Peter Brundrett offered an "optimistic snego" extension
> option proposal, building on the basic snego proposal.
>
> I believe that Carlisle's/Derrell's assessment is accurate, and that
> the document was being considered in the context of a prospective
> standards-track specification, and therefore believe that the consistent
> action at this time is to initiate WG Last-Call on snego-02 for advancement
> to Proposed Standard. I propose, therefore, that we initiate a WG Last-Call
> period on this document, to extend through Friday, 28 March, with Peter
> Brundrett's proposal to be considered within that Last-Call. Does
> anyone disagree with this assessment or object to this approach?
>
> --jl
I agree. Unfortunately I have had no time available yet to look at
Peter Brundrett's proposal.
It might help if Peter could elaborate a little bit more on the spirit
of his proposal before being forced to dive into the details.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa29839; 14 Mar 97 8:22 EST
Received: from ietf.ietf.org by ietf.org id aa29748; 14 Mar 97 8:20 EST
To: IETF-Announce: ;
cc: if-mib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: The Interfaces Group MIB to Draft Standard
Reply-to: iesg at ietf.org
Date: Fri, 14 Mar 1997 08:20:18 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703140820.aa29748 at ietf.org>
The IESG has received a request from the Interfaces MIB Working Group
to consider "The Interfaces Group MIB" <draft-ietf-ifmib-mib-05.txt>
for the status of Draft Standard. This updates RFC15734 (Evolution of
the Interfaces Group of MIB-II) currently a Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 26, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa01918; 14 Mar 97 9:18 EST
Received: from ietf.ietf.org by ietf.org id aa01813; 14 Mar 97 9:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rtfm at auckland.ac.nz
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rtfm-meter-mib-00.txt
Date: Fri, 14 Mar 1997 09:17:34 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140917.aa01813 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Realtime Traffic Flow
Measurement Working Group of the IETF.
Title : Traffic Flow Measurement: Meter MIB
Author(s) : N. Brownlee
Filename : draft-ietf-rtfm-meter-mib-00.txt
Pages : 43
Date : 03/12/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, this memo defines managed objects used for obtaining traffic
flow information from network traffic meters.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rtfm-meter-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rtfm-meter-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rtfm-meter-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312115109.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rtfm-meter-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rtfm-meter-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312115109.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa01919; 14 Mar 97 9:18 EST
Received: from ietf.ietf.org by ietf.org id aa01856; 14 Mar 97 9:18 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-fujikawa-plasma-00.txt
Date: Fri, 14 Mar 1997 09:18:02 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140918.aa01856 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Point-to-point Link Assembly for
Simple Multiple Access (PLASMA)
Author(s) : K. Fujikawa
Filename : draft-fujikawa-plasma-00.txt
Pages : 14
Date : 03/12/1997
This document describes PLASMA, which enables a simple multicast mechanism
and autoconfiguration in an IP subnet consisting of point-to-point links,
such as ATM, Frame Relay, SONET/SDH, etc. PLASMA utilizes an L2 label
switching mechanism and creates data flow paths in a subnet using the
PLASMA protocol. The PLASMA protocol is very simply defined and works
effectively within a single IP subnet. PLASMA applications to ATM and PPP
are also described.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-fujikawa-plasma-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-fujikawa-plasma-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-fujikawa-plasma-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312115631.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-fujikawa-plasma-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fujikawa-plasma-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312115631.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02009; 14 Mar 97 9:19 EST
Received: from ietf.ietf.org by ietf.org id aa01968; 14 Mar 97 9:19 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-tunnels-interop-00.txt
Date: Fri, 14 Mar 1997 09:19:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140919.aa01968 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Designing Tunnels for Interoperability with RSVP
Author(s) : J. Krawczyk
Filename : draft-ietf-rsvp-tunnels-interop-00.txt
Pages : 4
Date : 03/12/1997
This memo provides information for designers of tunneling protocols that
use IP-in-IP encapsulation. It describes how to design a tunnel header so
that RSVP [RSVPv1] can be used to signal the Quality of Service
requirements for individual flows within an IP-in-IP tunnel.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-tunnels-interop-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-tunnels-interop-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-tunnels-interop-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312120018.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-tunnels-interop-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-tunnels-interop-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312120018.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02091; 14 Mar 97 9:20 EST
Received: from ietf.ietf.org by ietf.org id aa02048; 14 Mar 97 9:20 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mboned at ns.uoregon.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mboned-imrp-some-issues-01.txt
Date: Fri, 14 Mar 1997 09:20:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140920.aa02048 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MBONE Deployment Working
Group of the IETF.
Title : Some Issues for an Inter-domain
Multicast Routing Protocol
Author(s) : D. Meyer
Filename : draft-ietf-mboned-imrp-some-issues-01.txt
Pages : 12
Date : 03/12/1997
The IETF's Inter-Domain Multicast Routing (IDMR) working group has produced
several multicast routing protocols, including Core Based Trees [CBT] and
Protocol Independent Multicasting [PIMARCH]. In addition, the IDMR WG has
formalized the specification of the Distance Vector Multicast Routing
Protocol [DVMRP]. Various specifications for protocol inter-operation have
also been produced (see, for example, [THALER96] and [PIMMBR]). However,
none of these protocols seems ideally suited to the inter-domain routing
case; that is, while these protocols are appropriate for the intra-domain
routing environment, they break down in various ways when applied in to the
multi-provider inter-domain case.
This document considers some of the scaling, stability and
policy issues that are of primary importance in a inter-domain,
multi-provider multicast environment.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-imrp-some-issues-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-imrp-some-issues-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-imrp-some-issues-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312122434.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-imrp-some-issues-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-imrp-some-issues-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312122434.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02183; 14 Mar 97 9:21 EST
Received: from ietf.ietf.org by ietf.org id aa02128; 14 Mar 97 9:20 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: find at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-find-cip-soif-00.txt
Date: Fri, 14 Mar 1997 09:20:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140920.aa02128 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Indexing Protocol
Working Group of the IETF.
Title : CIP Index Object Format for SOIF Objects
Author(s) : T. Hardie, M. Bowman, D. Hardy,
M. Schwartz, D. Wessels
Filename : draft-ietf-find-cip-soif-00.txt
Pages : 11
Date : 03/12/1997
The Common Indexing Protocol (CIP) allows servers to form a referral mesh
for query handling by defining a mechanism by which cooperating servers
exchange hints about the searchable indices they maintain. The structure
and transport of CIP are described in (Ref. 1), as are general rules for
the definition of index object types. This document describes SOIF, the
Summary Object Interchange Format, as an index object type in the context
of the CIP framework. SOIF is a machine-readable syntax for transmitting
structured summary objects, currently used primarily in the context of the
World Wide Web.
Query referral has often been dismissed as an ineffective strategy for
handling searches of Web resources, and Web resources certainly present
challenges not present in structured directory services like Rwhois. In
situations where a keyword-based free text search is desired, query
referral is not likely to be effective because the query will probably be
routed to every server participating in the referral mesh. Where a search
can be limited by reference to a specific resource attribute, however,
query referral is an effective tool. SOIF can be used to
create such a known-attribute query mesh because it provides a method
for associating attributes with net-addressable resources.
Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each
contributed to the creation of the SOIF format and to the descriptions
from which this draft is drawn; errors in this description of their work
are the responsibility of Edward Hardie and corrections should be
directed accordingly.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-find-cip-soif-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-find-cip-soif-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-find-cip-soif-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312131715.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-find-cip-soif-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-find-cip-soif-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312131715.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02303; 14 Mar 97 9:21 EST
Received: from ietf.ietf.org by ietf.org id aa02206; 14 Mar 97 9:21 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-versions-01.txt
Date: Fri, 14 Mar 1997 09:21:16 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140921.aa02206 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Use and interpretation of HTTP version numbers
Author(s) : J. Mogul, R. Fielding, J. Gettys, H. Frystyk
Filename : draft-ietf-http-versions-01.txt
Pages : 7
Date : 03/12/1997
HTTP request and response messages include an HTTP protocol version number.
Some confusion exists concerning the proper use and interpretation of HTTP
version numbers, and concerning interoperability of HTTP implementations of
different protocol versions. This document is an attempt to clarify the
situation. It is not a modification of the intended meaning of the
existing HTTP/1.0 and HTTP/1.1 documents, but it does describe the
intention of the authors of those documents, and can be considered
definitive when there is any ambiguity in those documents concerning HTTP
version numbers, for all versions of HTTP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-versions-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-versions-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-versions-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312134012.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-versions-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-versions-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312134012.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02329; 14 Mar 97 9:22 EST
Received: from ietf.ietf.org by ietf.org id aa02250; 14 Mar 97 9:21 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-goldsmith-utf7-02.txt
Date: Fri, 14 Mar 1997 09:21:44 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140921.aa02250 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Mail-Safe Transformation Format of Unicode
Author(s) : D. Goldsmith, M. Davis
Filename : draft-goldsmith-utf7-02.txt
Pages : 12
Date : 03/12/1997
The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended)
jointly define a character set (hereafter referred to as Unicode) which
encompasses most of the world's writing systems. However, Internet mail
(STD 11, RFC 822) currently supports only 7-bit US ASCII as a character
set. MIME (RFC 2045 through 2049) extends Internet mail to support
different media types and character sets, and thus could support Unicode in
mail messages. MIME neither defines Unicode as a permitted character set
nor specifies how it would be encoded, although it does provide for the
registration of additional character sets over time.
This document describes a transformation format of Unicode that contains
only 7-bit ASCII octets and is intended to be readable by humans
in the limiting case that the document consists of characters
from the US-ASCII repertoire. It also specifies how this
transformation format is used in the context of MIME and
RFC 1641, "Using Unicode with MIME".
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-goldsmith-utf7-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-goldsmith-utf7-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-goldsmith-utf7-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312141622.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-goldsmith-utf7-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-goldsmith-utf7-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312141622.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02399; 14 Mar 97 9:22 EST
Received: from ietf.ietf.org by ietf.org id aa02354; 14 Mar 97 9:22 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-urn-syntax-04.txt
Date: Fri, 14 Mar 1997 09:22:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140922.aa02354 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Names
Working Group of the IETF.
Title : URN Syntax
Author(s) : R. Moats
Filename : draft-ietf-urn-syntax-04.txt
Pages : 7
Date : 03/12/1997
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This document sets forward the
canonical syntax for URNs. A discussion of both existing legacy and new
namespaces and requirements for URN presentation and transmission are
presented. Finally, there is a discussion of URN equivalence and how to
determine it.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-urn-syntax-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-urn-syntax-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312142256.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-urn-syntax-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-urn-syntax-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312142256.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02515; 14 Mar 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa02449; 14 Mar 97 9:22 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: applmib at emi-summit.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-applmib-sysapplmib-07.txt
Date: Fri, 14 Mar 1997 09:22:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140922.aa02449 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Application MIB Working
Group of the IETF.
Title : Definitions of System-Level Managed Objects for
Applications
Author(s) : C. Krupczak, J. Saperia
Filename : draft-ietf-applmib-sysapplmib-07.txt
Pages : 48
Date : 03/12/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it describes a basic set of managed objects for fault,
configuration and performance management of applications from a systems
perspective. More specifically, the managed objects are restricted to
information that can be determined from the system itself and which does
not require special instrumentation within the applications to make the
information available.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-applmib-sysapplmib-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-sysapplmib-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-applmib-sysapplmib-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312142941.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-applmib-sysapplmib-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-applmib-sysapplmib-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312142941.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02655; 14 Mar 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa02573; 14 Mar 97 9:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leiba-imap-idle-01.txt
Date: Fri, 14 Mar 1997 09:23:20 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140923.aa02573 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 IDLE command
Author(s) : B. Leiba
Filename : draft-leiba-imap-idle-01.txt
Pages : 4
Date : 03/12/1997
The Internet Message Access Protocol [IMAP4] requires a client to poll the
server for changes to the selected mailbox (new mail, deletions). It's
often more desirable to have the server transmit updates to the client in
real time. This allows a user to see new mail immediately. It also helps
some real-time applications based on IMAP, which might otherwise need to
poll extremely often (such as every few seconds). (While the spec actually
does allow a server to push EXISTS responses aysynchronously, a client
can't expect this behaviour and must poll.)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-leiba-imap-idle-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leiba-imap-idle-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leiba-imap-idle-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312151420.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leiba-imap-idle-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leiba-imap-idle-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312151420.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa02689; 14 Mar 97 9:23 EST
Received: from ietf.ietf.org by ietf.org id aa02613; 14 Mar 97 9:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: disman at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-disman-script-mib-01.txt
Date: Fri, 14 Mar 1997 09:23:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703140923.aa02613 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Distributed Management
Working Group of the IETF.
Title : Definitions of Managed Objects for the Delegation of
Management Scripts
Author(s) : D. Levi, J. Schoenwaelder
Filename : draft-ietf-disman-script-mib-01.txt
Pages : 41
Date : 03/12/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects that allows
the delegation of management scripts to mid-level managers.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-disman-script-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-disman-script-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-disman-script-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970312173124.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-disman-script-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-disman-script-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970312173124.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04863; 14 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa04815; 14 Mar 97 9:56 EST
To: IETF-Announce: ;
cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Mapping between X.400 and RFC-822 to Proposed Standard
Reply-to: iesg at ietf.org
Date: Fri, 14 Mar 1997 09:56:09 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703140956.aa04815 at ietf.org>
The IESG has received a request from the MIME - X.400 Gateway Working
Group to consider the following Internet-Drafts for the status of
Proposed Standard:
o Mapping between X.400 and RFC-822/MIME Message Bodies
draft-ietf-mixer-bodymap-06.txt>
o X.400 image body parts
draft-ietf-mixer-images-01.txt>
o A MIME body part for FAX
draft-ietf-mixer-fax-01.txt>
o MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400
and RFC 822/MIME
<draft-kille-mixer-rfc1327bis-04.txt>
o Carrying PostScript in X.400 and MIME
<draft-ietf-mixer-postscript-01.txt>
The IESG will also consider publication of:
o A MIME body part for ODA
<draft-ietf-mixer-oda-01.txt>
as an Experimental Protocol.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 28, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa05055; 14 Mar 97 9:59 EST
Received: from ietf.ietf.org by ietf.org id aa05016; 14 Mar 97 9:59 EST
To: IETF-Announce: ;
cc: urn-ietf at bunyip.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: URN Syntax to Proposed Standard
Reply-to: iesg at ietf.org
Date: Fri, 14 Mar 1997 09:59:09 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703140959.aa05016 at ietf.org>
The IESG has received a request from the Uniform Resource Names Working
Group to consider "URN Syntax" <draft-ietf-urn-syntax-04.txt> for the
status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 28, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa10770; 14 Mar 97 11:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13561;
14 Mar 97 11:38 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA01893 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 14:24:02 GMT
Message-Id: <9703141418.AA27457 at us1rmc.bb.dec.com>
Date: Fri, 14 Mar 97 09:18:01 EST
From: "John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
Precedence: bulk
We haven't yet reached resolution on this question (what happens to the context
provided to gss_export_sec_context in the case where the routine returns an
error). There seem to be advocates in favor of always deleting the context
regardless of the error (so that an effect of calling gss_export_sec_context is
that the specified context is always released upon return), and others who
favor keeping the context valid in the event of an error (so that the caller
can invoke gss_inquire_context() on the context to log a failure message).
Any suggestions on how to proceed? This item is the one unresolved issue that
I'd like to get sorted out before I send out the next revision of the
C-bindings.
Actually, there's probably a similar issue around
init-sec_context/accept_sec_context. If the first invocation of one of these
calls succeeds, and a subsequent call fails, we should specify whether or not
the "half-built" context has to be deleted by the application.
John
Received: from ietf.org by ietf.org id aa12381; 14 Mar 97 12:43 EST
Received: from mailrelay.tiac.net by ietf.org id aa12038; 14 Mar 97 12:31 EST
Received: from outcomes (charlie.tiac.net [206.105.157.58])
by mailrelay.tiac.net (8.8.5/) with SMTP id MAA02344
for <ietf at ietf.org>; Fri, 14 Mar 1997 12:29:24 -0500 (EST)
Date: Fri, 14 Mar 1997 12:29:24 -0500 (EST)
Message-Id: <199703141729.MAA02344 at mailrelay.tiac.net>
Sender:ietf-request at ietf.org
From: Charles W Morgan <charlie at outcomesinc.com>
To: ietf at ietf.org
Subject: Remove from mailing list
X-Mailer: POTP Secure Mail[version 1.0]
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Charles Morgan
OUTCOMES 2000, INC.
67 Middle Street
Lowell MA 01852
508 454 0969 fax 508 937 2540
Email: charlie at outcomesinc.com
Web: www.elementrix.com
"You can only compromise what you have"
Received: from ietf.org by ietf.org id aa13512; 14 Mar 97 13:02 EST
Received: from apprentice.qualcomm.com by ietf.org id aa13437;
14 Mar 97 13:00 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id JAA13019; Fri, 14 Mar 1997 09:57:07 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03102001af4f3f0fd058 at [129.46.166.223]>
In-Reply-To: <Pine.OSF.3.95.970314023613.2149A-100000 at duke.usask.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1fc32-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Fri, 14 Mar 1997 09:51:56 -0800
To: Derek Andrew <andrew at duke.usask.ca>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: Authenticated Mail
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 2:38 AM -0600 3/14/97, Derek Andrew wrote:
>Are there any plans in the future of the Internet for Authenticated Mail?
>I am really getting tired of "spammers" sending me email, and hiding the
>address of the sender.
>
>This means I should be able to refuse all email in which the sender could
>not be verified.
It is unlikely that senders of electronic mail would ever be compelled to
sign every message they send before they were sent. That is far more
restrictive that current practice of postal mail.
That doesn't mean you won't have software at your command that could refuse
acceptance of any message that wasn't digitally signed. All of the
technology necessary to support that facility now exist. Commercial
products to make this palatable for a wide range of user capabilities does
not. But it is only a matter of time before they do, imho.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from cnri by ietf.org id aa14743; 14 Mar 97 13:24 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16086;
14 Mar 97 13:24 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA06257 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 16:08:57 GMT
Message-Id: <33297770.2531 at trsvr.tr.unisys.com>
Date: Fri, 14 Mar 1997 11:06:08 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <Roam 0.9.4.858210079.24902.mre at jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mike Eisler wrote:
> [snip]
> > 3) No standard API. Each mechanism does its own thing.
> > Issues:
> > (a) Ugh!
>
> Why Ugh? People use BSD 4.[1234] sockets, X/Open sockets, win sockets, TLI,
> XTI, ONC RPC, DCE RPC, IIOP, etc. to program distributed apps.
>
> I don't think you can say there will no standard API. There will be multiple
> APIs, because some apps have different needs than others.
>
Yes, applications use ONC RPC, DCE RPC, IIOP, etc. to program
distributed apps. The choice, it seems to me, is governed by the
application architecture within which those apps are being developed. In
other words, it's a high level strategic decision, rather than a
tactical decision that's made by a developer at low-level design time.
Once the decision has been made, the communication mechanism becomes
rather deeply woven into the fabric of the application suite. It's a
decision that's likely to be very durable, without the need for rapid
migration to the next wave of technology. Trying to design a unifying
API for all these mechanisms would be much more trouble than it's worth.
Choice of security mechanism is entirely different. Security involves
ongoing administration, audits, and consequent activity long after the
application has been deployed. If you find security vulnerabilities in
your IT environment, you don't want to have to fix them by diving into
the code of every application. You want to change the policy so that
security mechanisms being used behave differently, or so that different
security mechanisms come into play (including the degenerate case of
changing the null mechanism to a non-null one), and all the while
minimizing the impact on application writers. It seems to me that choice
of security mechanism, for most business applications, should not be
determined by application developers, or even application architects.
It's a job for the security architect, working in conjunction with the
business managers and legal department, and it demands a different skill
set.
>
> Also, don't forget about IPSEC. It will be in the competition once there
> is an agreement on the socket and XTI extensions for using it.
>
IPSEC addresses a different problem. It's only of interest in an
intra-enterprise environment using the Internet as a wire, or with a
closed group of tightly coupled business partners. It's functionally
quite similar to proprietary solutions like NetLock and HannaH, that
provide transparent security for all aware transport endpoints, without
application involvement. You get bulk encryption and data integrity, but
without authentication of application endpoints.
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa15900; 14 Mar 97 13:59 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa15746; 14 Mar 97 13:55 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id NAA21381; Fri, 14 Mar 1997 13:51:25 -0500 (EST)
Message-Id: <199703141851.NAA21381 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
cc: ietf at ietf.org, moore at cs.utk.edu
Subject: Re: Export restrictions (Re: call for a new email infrastructure)
In-reply-to: Your message of "Thu, 13 Mar 1997 14:45:55 EST."
<Pine.SUN.3.91.970313085423.5979B-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 14 Mar 1997 13:51:25 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> My response, not being a multi-page treatise because I was trying to
> provide a very brief correction, did not attempt to fully explain all
> the details.
Yes, it's difficult to be terse and precise at the same time.
I'm glad that we can apparently export source code that makes calls to
authentication library routines. But IMHO the restrictions on export
of source code of authentication algorithms, that happen to be usable
for encryption, still impose a significant barrier to the deployment
of strong authentication in the Internet.
> > You mean I can export source code to the RSA algorithm as long as
> > the code is only used to do authentication? Great!
>
> No, but since the RSA source code is available almost everywere, why is
> that important? Being able to export all the rest of the authentication
> source, including the crypto calls, seems adequate.
I find it difficult to associate the word "adequate" with any aspect
of the Clinton administration's crypto export policy.
Keith
Received: from cnri by ietf.org id aa17102; 14 Mar 97 14:20 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17368;
14 Mar 97 14:20 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA09682 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 17:34:40 GMT
Message-Id: <640796DB4262D0118D3300805FD4EFCF93DC78 at RED-32-MSG.dns.microsoft.com>
From: Peter Brundrett <petebr at microsoft.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>
Subject: optimistic snego for performance
Date: Fri, 14 Mar 1997 09:33:55 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
Denis asked if I could provide some motivation for optimistic snego:
>It might help if Peter could elaborate a little bit more on the spirit
>of his proposal before being forced to dive into the details.
The main purpose for optimistic snego is the performance advantage of
eliminating extra network round trips. Network connection setup is a
critical performance characteristic of any network infrastructure and
extra roundtrips over WAN links, packet radio networks, etc. really make
a difference. One roundtrip for this, one roundtrip for that, and
server connection setup can really be slow.
The statement from the proposal is the following:
The primary advantage of including the initial security token of
the
preferred mechanism is that if the target preferred mechanism
matches
the initiators preferred mechanism, no additional roundtrips are
incurred by using the negotiation protocol.
The specific protocol change is to add one optional field to the
NegTokenReq, containing the initial security token for the desired
mechanism of the Initiator.
It seems to me that not all targets must be able to support the
optimistic desiredToken. The target could simply ignore the
desiredToken and complete the negotiation handshake as described in
snego-02. Implementations that can piggyback the initial token should
be rewarded by faster connection setup.
Peter Brundrett
Microsoft
Received: from ietf.org by ietf.org id aa17222; 14 Mar 97 14:24 EST
Received: from poptart.home.net by ietf.org id aa17159; 14 Mar 97 14:23 EST
Received: from borg.eos.home.net ([24.0.8.40]) by poptart.home.net
(Netscape Mail Server v1.1) with ESMTP id AAA13175;
Fri, 14 Mar 1997 11:20:30 -0700
Received: (from rja at localhost) by borg.eos.home.net (8.7.5/8.7.3) id LAA11928; Fri, 14 Mar 1997 11:20:28 -0800 (PST)
Sender:ietf-request at ietf.org
From: Ran Atkinson <rja at corp.home.net>
Message-Id: <970314112028.ZM11926 at borg.eos.home.net>
Date: Fri, 14 Mar 1997 11:20:27 -0800
In-Reply-To: Keith Moore <moore at cs.utk.edu>
"Re: Export restrictions (Re: call for a new email infrastructure)" (Mar 14, 13:51)
References: <199703141851.NAA21381 at ig.cs.utk.edu>
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: Keith Moore <moore at cs.utk.edu>
Subject: Re: Deployment of strong authentication technology
Cc: ietf at ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
On Mar 14 13:51, Keith Moore wrote:
% But IMHO the restrictions on export of source code of authentication
% algorithms, that happen to be usable for encryption, still impose
% a significant barrier to the deployment of strong authentication
% in the Internet.
I believe the work below constitutes an existence proof that
restrictions on export of authentication algorithms used primarily
for encryption (e.g. RSA) is not a significant barrier to
deployment of strong authentication in the Internet:
RIPv2 MD5 (available in many routers now)
OSPFv2 MD5 (available in many routers now)
TCP MD5 Authentication option for BGP4 (available in cisco
routers for over a year now)
In current practice, the above are widely used internationally by
many ISPs to protect their infrastructure. Those not yet using
them should be. Lack of deployed scalable key management technology
(e.g. ISAKMP/Oakley) has not proven to be a significant deployment
barrier to the above in actual practice.
Widespread deployment of AH with HMAC MD5 (exportable since not
useful for confidentiality) will depend in part on deployment
of ISAKMP/Oakley. AH with HMAC MD5 is a kind of strong authentication
technology that has broad utility.
However, an ISAKMP/Oakley implementation developed outside the US
(e.g. at DRA/Malvern) successfully interoperated with cisco's
implementation a year ago[1]. This leads me to believe that outside
the US, sites will simply use non-US-developed implementations of
ISAKMP/Oakley to provide scalable key management.
Yours,
Ran
rja at inet.org
[1] This was with a then-current revision of ISAKMP. Both the
DRA/Malvern and cisco code bases are being updated to the most
recent version of ISAKMP...
Received: from cnri by ietf.org id aa19518; 14 Mar 97 15:25 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18915;
14 Mar 97 15:25 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <SAA11051 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 18:04:30 GMT
Date: Fri, 14 Mar 1997 13:04:09 -0500
Message-Id: <9703141804.AA05214 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Ashraf Madoukh - 534-3137 <ashraf at dns.sprintcorp.com>
Cc: CAT-IETF Group <cat-ietf at mit.edu>
In-Reply-To: Ashraf Madoukh - (913) 534-3137's message of Thu, 13 Mar 1997
09:36:17 -0600, <9703131537.AA03397 at dns.sprintcorp.com>
Subject: Re: GSS-API V2
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: "Ashraf Madoukh - (913) 534-3137" <ashraf at dns.sprintcorp.com>
Date: Thu, 13 Mar 1997 09:36:17 -0600
Is there any company who fully implemented GSS-API V2.0 or are we still in
discussion phase only?
What's the latest draft on GSS-API v2.0?
It's hardly "just discussion"; the MIT Kerberos release has most (but
not quite all) of GSSAPI V2.0 implemented. I'm planning on implementing
the last two or three new calls in the near future.
The high-level GSSPAI specification has been released as RFC 2078. The
latest GSSAPI C bindings spec is draft-ietf-cat-gssv2-cbind-03.txt.
The MIT Kerberos Papers and Documentation page has links to the relevent
GSSAPI standards, and it's generally up-to-date. (If you notice
something that isn't up to date on the page, e-mail me and I'll fix it.)
http://web.mit.edu/kerberos/www/papers.html
- Ted
Received: from cnri by ietf.org id aa19648; 14 Mar 97 15:30 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19009;
14 Mar 97 15:30 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA08598 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 17:06:35 GMT
Message-Id: <199703141706.MAA13374 at gza-client1.cam.ov.com>
To: "John Wray, Digital DPE,\
508/486-5210 14-Mar-1997 0910" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: gss_export_sec_context()
In-Reply-To: Your message of "Fri, 14 Mar 1997 09:18:01 EST."
<9703141418.AA27457 at us1rmc.bb.dec.com>
Date: Fri, 14 Mar 1997 12:06:23 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Re:
>We haven't yet reached resolution on this question (what happens to
>the context provided to gss_export_sec_context in the case where the
>routine returns an error). There seem to be advocates in favor of
>always deleting the context regardless of the error (so that an effect
>of calling gss_export_sec_context is that the specified context is
>always released upon return), and others who favor keeping the context
>valid in the event of an error (so that the caller can invoke
>gss_inquire_context() on the context to log a failure message).
>
>Any suggestions on how to proceed? This item is the one unresolved
>issue that I'd like to get sorted out before I send out the next
>revision of the C-bindings.
I'd prefer preserving the context as it stands upon an export error,
but can accept either choice.
>Actually, there's probably a similar issue around
>init-sec_context/accept_sec_context. If the first invocation of one
>of these calls succeeds, and a subsequent call fails, we should
>specify whether or not the "half-built" context has to be deleted by
>the application.
Here, I assume that the partially established context should have to
be explicitly deleted; the initial call in this context establishment
sequence, which was the operation creating the context object,
succeeded.
>John
--jl
Received: from ietf.org by ietf.org id aa20033; 14 Mar 97 15:40 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa19610;
14 Mar 97 15:29 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA14605; Fri, 14 Mar 97 15:25:33 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA05289; Fri, 14 Mar 1997 15:25:32 -0500
Date: Fri, 14 Mar 1997 15:25:32 -0500
Message-Id: <9703142025.AA05289 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Ran Atkinson <rja at corp.home.net>
Cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
In-Reply-To: Ran Atkinson's message of Fri, 14 Mar 1997 11:20:27 -0800,
<970314112028.ZM11926 at borg.eos.home.net>
Subject: Re: Deployment of strong authentication technology
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
From: Ran Atkinson <rja at corp.home.net>
Date: Fri, 14 Mar 1997 11:20:27 -0800
% But IMHO the restrictions on export of source code of authentication
% algorithms, that happen to be usable for encryption, still impose
% a significant barrier to the deployment of strong authentication
% in the Internet.
I believe the work below constitutes an existence proof that
restrictions on export of authentication algorithms used primarily
for encryption (e.g. RSA) is not a significant barrier to
deployment of strong authentication in the Internet:
RIPv2 MD5 (available in many routers now)
OSPFv2 MD5 (available in many routers now)
TCP MD5 Authentication option for BGP4 (available in cisco
routers for over a year now)
In current practice, the above are widely used internationally by
many ISPs to protect their infrastructure. Those not yet using
them should be. Lack of deployed scalable key management technology
(e.g. ISAKMP/Oakley) has not proven to be a significant deployment
barrier to the above in actual practice.
Keith was speaking in general terms. It is true that for the specific
case of routers, the lack of scalable key management is surmountable,
especially since the peering relationships are prearranged, limited to
an enumerable set, and relatively slow to change.
However, for many other applications (i.e., for email, which was the
original starting point of this thread), the lack of scalable key
management technocal *would* be a significant deployment barrier.
- Ted
Received: from ietf.org by ietf.org id aa20709; 14 Mar 97 15:53 EST
Received: from mail5.microsoft.com by ietf.org id aa20491; 14 Mar 97 15:51 EST
Received: by INET-05-IMC with Internet Mail Service (5.0.1457.3)
id <G6F5RQ29>; Fri, 14 Mar 1997 12:51:00 -0800
Message-ID: <B0E879402932CF11B94700805F14E35C03E8773F at RED-71-MSG.dns.microsoft.com>
Sender:ietf-request at ietf.org
From: "Marcel Wingate (Excell Data)" <v-marcew at microsoft.com>
To: ietf at ietf.org
Subject: RE: Authenticated Mail
Date: Fri, 14 Mar 1997 12:48:57 -0800
X-Priority: 3
Return-Receipt-To: "Marcel Wingate (Excell Data)" <v-marcew at microsoft.com>
X-Mailer: Internet Mail Service (5.0.1457.3)
Source-Info: From (or Sender) name not authenticated.
> It would also be a great help if mail arriving bcc'd would indicate
> which
> email address it came in under. When I receive spam, I have no way of
> knowing
> whether it came via my ISP account/domain or via one of my custom
> domain name
> addresses. Thus, I don't even know what name to ask to have removed!
>
> -Walter
>
> Then it wouldn't be a "BCC," a blind copy. One caveat to
> "Authenticated" e-mail is that we have to make sure that everyone that
> we correspond with has an authenticated address. This is similar to
> our mail system here; we have MS Exchange security but it isn't much
> help since only a couple of my colleagues exert the effort to use it.
>
> Thank you,
> Marcel R. Wingate
>
> Sr. Technical Support Lead Ph: (206)
> 703-1875
> Microsoft Technical Support Group Fax: (206) 936-9158
>
> * Microsoft Certified Systems Engineer
> - Guitarist, Songwriter
Received: from ietf.org by ietf.org id aa21786; 14 Mar 97 16:02 EST
Received: from fxiod04.is.chrysler.com by ietf.org id aa21509;
14 Mar 97 16:01 EST
Received: by fxiod04.is.chrysler.com; id AA11828; Fri, 14 Mar 97 15:58:45 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod04.is.chrysler.com via smap (V3.1.1)
id xma011803; Fri, 14 Mar 97 15:58:34 -0500
Received: from odemxpr1-dgen0.oddc.chrysler.com (odemxpr1-dgen0.oddc.chrysler.com [129.9.196.20]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id PAA08014 for <ietf at ietf.org>; Fri, 14 Mar 1997 15:43:11 -0500 (EST)
Sender:ietf-request at ietf.org
From: emxadmin at chrysler.com
Received: by odemxpr1-dgen0.oddc.chrysler.com (5.4R3.00/200.2.1.5)
id AA17991; Fri, 14 Mar 1997 15:58:12 -0500
Date: Fri, 14 Mar 1997 15:58:12 -0500
Message-Id: <9703142058.AA17991 at odemxpr1-dgen0.oddc.chrysler.com>
To: Ran Atkinson <rja at corp.home.net>, "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: ietf at ietf.org, Keith Moore <moore at cs.utk.edu>
Subject: Re: Deployment of strong authentication technology
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
?
i
Received: from ietf.org by ietf.org id aa21791; 14 Mar 97 16:02 EST
Received: from fxiod01.is.chrysler.com by ietf.org id aa21613;
14 Mar 97 16:01 EST
Received: by fxiod01.is.chrysler.com; id AA01487; Fri, 14 Mar 97 15:59:09 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod01.is.chrysler.com via smap (V3.1.1)
id xma001442; Fri, 14 Mar 97 15:58:50 -0500
Received: from odemxpr1-dgen0.oddc.chrysler.com (odemxpr1-dgen0.oddc.chrysler.com [129.9.196.20]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id PAA08032 for <ietf at ietf.org>; Fri, 14 Mar 1997 15:43:27 -0500 (EST)
Sender:ietf-request at ietf.org
From: emxadmin at chrysler.com
Received: by odemxpr1-dgen0.oddc.chrysler.com (5.4R3.00/200.2.1.5)
id AA18011; Fri, 14 Mar 1997 15:58:27 -0500
Date: Fri, 14 Mar 1997 15:58:27 -0500
Message-Id: <9703142058.AA18011 at odemxpr1-dgen0.oddc.chrysler.com>
To: Ran Atkinson <rja at corp.home.net>, "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: ietf at ietf.org, Keith Moore <moore at cs.utk.edu>
Subject: Re: Deployment of strong authentication technology
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Received: from cnri by ietf.org id aa22584; 14 Mar 97 16:13 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20046;
14 Mar 97 16:13 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA14735 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 19:23:14 GMT
Message-Id: <199703141923.OAA13656 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Administrative info re Memphis meeting
Date: Fri, 14 Mar 1997 14:23:06 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
All:
Steve Coya at the IETF Secretariat asks me to forward the following
for the benefit of anyone intending to present material at the Memphis
meeting and wanting that material to be included in the proceedings:
>PLEASE - read/visit http://www.ietf.org/instructions/instructions.html
>for guidelines to be followed for presentation/overhead material to be
>submitted for inclusion in the hardcopy/electronic proceedings.
>
>DO NOT assume these are the same as before... you would be wrong :-)
>
>One example: if you intend to submit postscript files, you need not
>send both a one image/page AND a 6 image/page file. We have a tool that
>will permit us to reformat the postscript file, but it only works with
>1 image/page.
Two other points:
All Internet-Draft editors should be aware that the deadline for I-D
submission in advance of next month's meeting is Wednesday, 26 March.
Anyone wanting to request discussion slots for the CAT session (and
who hasn't already done so) should make this known ASAP; I'll plan to
circulate a draft agenda next week.
Regards, ...
--jl
Received: from ietf.org by ietf.org id aa23124; 14 Mar 97 16:18 EST
Received: from cnri by ietf.org id aa22930; 14 Mar 97 16:17 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa20134;
14 Mar 97 16:17 EST
Received: from stream.mcs.muohio.edu by venera.isi.edu (5.65c/5.61+local-26)
id <AA27791>; Fri, 14 Mar 1997 13:15:06 -0800
Received: from po.muohio.edu by po.muohio.edu (PMDF V5.1-5 #19148)
id <01IGHYTMDO4G8WWVCR at po.muohio.edu> for ietf at venera.isi.edu; Fri,
14 Mar 1997 16:15:03 EDT
Date: Fri, 14 Mar 1997 16:15:03 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "maz1 at miavx1.muohio.edu"@stream.mcs.muohio.edu
Subject: Re: appending my apologies
To: ietf at isi.edu
Message-Id: <01IGHYTMEAMA8WWVCR at po.muohio.edu>
X-Vms-To: in%"ietf%venera.isi.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Relay-Version: ANU News - V6.1B10 04/18/95 OpenVMS AXP; site nntp.muohio.edu
Path: news.muohio.edu!nntp
Newsgroups: info.ietf
Subject: Re: appending my apologies
Message-ID: <3329EA08.2282 at miavx1.muohio.edu>
From: Catherine <maz1 at miavx1.muohio.edu>
Date: Fri, 14 Mar 1997 16:15:04 -0800
References: <199703121648.RAA19995 at box.nl>
Nntp-Posting-Host: 134.53.29.198
X-Mailer: Mozilla 2.02 (Win95; I; 16bit)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 43
michael_roetto wrote:
>
> Dear Members,
>
> I just spend a good 15 minutes deleting about 50 different messages
> 'correcting' my oversight in sending my unsubscribe message to the wrong
> address.
>
> Having been on this list for the last six months or so, I have received many
> remove messages. Were these people 'mail-bombed' like myself? Or am I just
> being made an example of?
>
> I think the response I received for a simple mistake is really out of line.
>
> -michael_roettomichael_roetto wrote:
>
> Dear Members,
>
> I just spend a good 15 minutes deleting about 50 different messages
> 'correcting' my oversight in sending my unsubscribe message to the wrong
> address.
>
> Having been on this list for the last six months or so, I have received many
> remove messages. Were these people 'mail-bombed' like myself? Or am I just
> being made an example of?
>
> I think the response I received for a simple mistake is really out of line.
>
> -michael_roettomichael_roetto wrote:
>
> Dear Members,
>
> I just spend a good 15 minutes deleting about 50 different messages
> 'correcting' my oversight in sending my unsubscribe message to the wrong
> address.
>
> Having been on this list for the last six months or so, I have received many
> remove messages. Were these people 'mail-bombed' like myself? Or am I just
> being made an example of?
>
> I think the response I received for a simple mistake is really out of line.
>
> -michael_roetto
Received: from ietf.org by ietf.org id aa23371; 14 Mar 97 16:21 EST
Received: from ietf.ietf.org by ietf.org id aa22907; 14 Mar 97 16:17 EST
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: The resolution of ISAKMP with Oakley to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Fri, 14 Mar 1997 16:17:42 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703141617.aa22907 at ietf.org>
The IESG has received a request from the IP Security Protocol Working
Group to consider the following Internet-Drafts for the status of
Proposed Standard:
o The resolution of ISAKMP with Oakley
<draft-ietf-ipsec-isakmp-oakley-03.txt>
o Internet Security Association and Key Management Protocol (ISAKMP)
<draft-ietf-ipsec-isakmp-07.txt>
o The Internet IP Security Domain of Interpretation for ISAKMP
<draft-ietf-ipsec-ipsec-doi-02.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by March 28, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa25495; 14 Mar 97 16:57 EST
Received: from shell1.aimnet.com by ietf.org id aa25358; 14 Mar 97 16:53 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id NAA14715; Fri, 14 Mar 1997 13:50:20 -0800 (PST)
Date: Fri, 14 Mar 1997 13:50:20 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: "Marcel Wingate (Excell Data)" <v-marcew at microsoft.com>
cc: ietf at ietf.org
Subject: RE: Authenticated Mail
In-Reply-To: <B0E879402932CF11B94700805F14E35C03E8773F at RED-71-MSG.dns.microsoft.com>
Message-ID: <Pine.SOL.3.95.970314134607.13890A-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 14 Mar 1997, Marcel Wingate (Excell Data) wrote:
> > whether it came via my ISP account/domain or via one of my custom
> > domain name
> > addresses. Thus, I don't even know what name to ask to have removed!
> >
> Then it wouldn't be a "BCC," a blind copy. One caveat to
There is nothing fundamental in the notion of a blind copy which requires
removal of the blind addressee from the copy delivered to that copy.
I've been b'ccd many times on physical memos/mail and always have a
bcc cover sheet with my address on it. No other way to be sure it was
intended for me.
Dave Morris
Received: from ietf.org by ietf.org id aa25837; 14 Mar 97 17:01 EST
Received: from shell1.aimnet.com by ietf.org id aa25758; 14 Mar 97 17:00 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id NAA15091; Fri, 14 Mar 1997 13:57:38 -0800 (PST)
Date: Fri, 14 Mar 1997 13:57:38 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: Derek Andrew <andrew at duke.usask.ca>, ietf at ietf.org
Subject: Re: Authenticated Mail
In-Reply-To: <v03102001af4f3f0fd058 at [129.46.166.223]>
Message-ID: <Pine.SOL.3.95.970314135211.13890B-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 14 Mar 1997, John W. Noerenberg wrote:
> At 2:38 AM -0600 3/14/97, Derek Andrew wrote:
> >Are there any plans in the future of the Internet for Authenticated Mail?
> >I am really getting tired of "spammers" sending me email, and hiding the
> >address of the sender.
> >
> >This means I should be able to refuse all email in which the sender could
> >not be verified.
>
> It is unlikely that senders of electronic mail would ever be compelled to
> sign every message they send before they were sent. That is far more
Authentication does not require a signature. Only verification that the
'return address' is valid. And nothing I've seen requires all mail to be
authenticated. But if an authenticated infrastructure were created, then
it would be possible for me (or Derek) to choose to ignore mail which
wasn't authenticated or to ask our MTA to throw away mail which wasn't
authenticated.
> restrictive that current practice of postal mail.
True ... but then the economics of sending unauthenticated postal mail is
quite different. And I always throw away mail with bulk postage which
promises some vast reward inside.
Dave Morris
Received: from cnri by ietf.org id aa26929; 14 Mar 97 17:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21348;
14 Mar 97 17:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA15784 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 19:45:22 GMT
Message-Id: <3329AAC7.437D at trsvr.tr.unisys.com>
Date: Fri, 14 Mar 1997 14:45:11 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: Rich Salz <rsalz at osf.org>
Cc: cat-ietf at mit.edu
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <199703131606.LAA10596 at sulphur.osf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Rich Salz wrote:
>
> > I would assert that:
> > Applications should not embed security policy or mechanisms. Rather
> > policy should be set and mechanisms selected by the administrators of
> > the site/system/domain that meet there needs.
> >
> > Is there at least general agreement on this point?
>
> No. There are applications that will need to embed their own policy
> and mechanism. For example, login programs that must be able to "trust"
> the network before granting local acess. The analogy I'd draw is that
> some programs need mechanism to set their own dynamic library load path...
> /r$
In this context, I wouldn't regard a login program as being the same
genus as a business application. The login program is itself a security
enforcing mechanism, whereas the business application is a user of
security services. I believe the administrator-sets-the-policy principle
remains valid.
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa28845; 14 Mar 97 17:41 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa28758; 14 Mar 97 17:40 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id RAA29212;
Fri, 14 Mar 1997 17:36:59 -0500
Message-Id: <199703142236.RAA29212 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "David W. Morris" <dwm at xpasc.com>
Cc: "John W. Noerenberg" <jwn2 at qualcomm.com>,
Derek Andrew <andrew at duke.usask.ca>, ietf at ietf.org
Subject: Re: Authenticated Mail
In-Reply-To: Your message of "Fri, 14 Mar 1997 13:57:38 PST."
<Pine.SOL.3.95.970314135211.13890B-100000 at shell1.aimnet.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <Pine.SOL.3.95.970314135211.13890B-100000 at shell1.aimnet.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1582890558P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 14 Mar 1997 17:36:56 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1582890558P
Content-Type: text/plain; charset=us-ascii
On Fri, 14 Mar 1997 13:57:38 PST, "David W. Morris" said:
> Authentication does not require a signature. Only verification that the
> 'return address' is valid. And nothing I've seen requires all mail to be
Umm.. No.
Consider the authentication provided by a notary public. They are not
asserting that the signature at the bottom of the document is the name
of a live person. They are asserting that the signature was, in fact,
placed there by the owner of the name.
Consider that in both the paper-trail world and the E-mail world, a
"forged" item is one that was posted *as if it were done by the
purported signatory*, when in fact it was not.
I suppose if this missive showed up with a header that stated
'From: "David W. Morris" <dwm at xpasc.com>' the distinction would be much
clearer.. ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1582890558P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMynTBdQBOOoptg9JAQG1fAQAoY2KS1K1oA2/dy39eJvaw7BU6xZgSJQZ
EYq+NaGVfN9bN25wX7QTW4z3DI8t9LpKUI/NHrZQDpHIH/RAZk1M8sUl6ckmqtBC
oSHnXyj1BdxCKIL//SasB1E8plD+bD6UqLoN1ZIrsmtuqNxhGhT9XgTfkrwoKOTZ
PFzpRyvsqc8=
=+wOp
-----END PGP MESSAGE-----
--==_Exmh_-1582890558P--
Received: from cnri by ietf.org id aa29894; 14 Mar 97 18:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22191;
14 Mar 97 18:01 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA21293 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 21:52:43 GMT
Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970314214430Z-22742 at bwdldb.ott.bnr.ca>
From: Carlisle Adams <Cadams at entrust.com>
To: "'cat-ietf%mit.edu'" <cat-ietf at mit.edu>,
"'petebr at microsoft.com'" <petebr at microsoft.com>
Subject: RE: optimistic snego for performance
Date: Fri, 14 Mar 1997 16:44:30 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 12 TEXT
Precedence: bulk
Hi,
Peter's proposal seems entirely reasonable to me; I vote that it be
added to SNEGO.
--------------------------------------
Carlisle Adams
Entrust Technologies
cadams at entrust.com
---------------------------------------
>
Received: from cnri by ietf.org id aa01042; 14 Mar 97 18:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22539;
14 Mar 97 18:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA19142 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 20:58:48 GMT
Date: Fri, 14 Mar 1997 21:58:30 +0100
Message-Id: <199703142058.VAA16510 at p18509.wdf.sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Subject: optional or mandatory GSS-API features
Precedence: bulk
I have the impression that for some features of the GSS-API it is
not clearly specified if they're optional or mandatory for a
** GSS-API MECHANISM ** to implement, and their implications.
To me, it's unclear whether support of certain features is recommended
or actually required. I assume/hope that everywhere where it says
"for maximum portabibilty do this ..." that it acutally sets a
REQUIREMENT for conforming gssapi mechanism to support a feature.
What is the status of the following items; add one of:
required / recommended / optional / discouraged / unspecified / prohibited
(1) default credentials
(2) default name
(1a) default ACCEPT credentials
~= support GSS_C_NO_CREDENTIAL for gss_accept_sec_context()
(2a) ~= support GSS_C_NO_NAME & GSS_C_ACCEPT for gss_acquire_cred()
(1b) default INITIATE credentials
~= support GSS_C_NO_CREDENTIAL for gss_initiate_context()
(2b) ~= support GSS_C_NO_NAME & GSS_C_INITIATE for gss_acquire_cred()
(1c) default BOTH credentials
(2c) ~= support GSS_C_NO_NAME & GSS_C_BOTH for gss_acquire_cred()
(1d) may the principal/identity of the standalone default ACCEPT
credentials be different from the default INITIATE credential
(1e) may the principals/identities of the ACCEPT and INITIATE parts
of credentials be different within default BOTH credentials?
(1f) support GSS_C_NO_CREDENTIAL for gss_add_cred()
(2f) support GSS_C_NO_NAME for gss_add_cred()
(1g) support GSS_C_NO_CREDENTIAL for release_cred()
(1h) support GSS_C_NO_CREDENTIAL for inquire_cred_by_mech()
(3) default nametype
(3a) support GSS_C_NO_OID for import_name()
(4a) return GSS_C_NO_OID from display_name() for (3a)-names
(4) default mechanism(s)
(4a) support GSS_C_NO_OID_SET for acquire_cred()
(4b) support GSS_C_NO_OID for add_cred()
(4c) support GSS_C_NO_OID for init_sec_context()
for accept_sec_context()
(4d) support GSS_C_NO_OID for inquire_cred_by_mech()
(4e) support GSS_C_NO_OID for inquire_names_for_mech()
(5) "protected" zero length messages
(5a) support GSS_C_EMPTY_BUFFER for gss_wrap() and
return GSS_C_EMPTY_BUFFER & GSS_S_COMPLETE from gss_unwrap()
(5b) support GSS_C_EMPTY_BUFFER for gss_getmic() and gss_verifymic()
I'm especially interested in the status of 1a-e, 2a-c, 3 and 5
-Martin
Received: from ietf.org by ietf.org id aa01364; 14 Mar 97 18:21 EST
Received: from egoshin.genesyslab.com by ietf.org id aa01086;
14 Mar 97 18:17 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id PAA28410; Fri, 14 Mar 1997 15:15:08 -0800
Date: Fri, 14 Mar 1997 15:15:08 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703142315.PAA28410 at egoshin.genesyslab.com>
To: dwm at xpasc.com, Valdis.Kletnieks at vt.edu
Subject: Re: Authenticated Mail
Cc: andrew at duke.usask.ca, ietf at ietf.org, jwn2 at qualcomm.com
Source-Info: From (or Sender) name not authenticated.
>From: Valdis.Kletnieks at vt.edu
>On Fri, 14 Mar 1997 13:57:38 PST, "David W. Morris" said:
>> Authentication does not require a signature. Only verification that the
>> 'return address' is valid. And nothing I've seen requires all mail to be
>
>Umm.. No.
>
>Consider the authentication provided by a notary public. They are not
>asserting that the signature at the bottom of the document is the name
>of a live person. They are asserting that the signature was, in fact,
>placed there by the owner of the name.
>
Hm-m, but it is usefull if you _KNOW_ the notary (his E-signature).
And it is not obvious that notary _KNOW_ the sender. For notary it could be
the same problem.
If you insert notary in sender software - who can configure it and
what are the rules of such configuration ?
Comparison with paper-world is not very suitable here...
- Leonid Yegoshin, LY22
Received: from cnri by ietf.org id aa02569; 14 Mar 97 18:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23331;
14 Mar 97 18:54 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA21445 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 21:56:19 GMT
Date: Fri, 14 Mar 1997 16:53:39 -0500
Message-Id: <9703142153.AA05358 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: "John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910" <wray at tuxedo.enet.dec.com>,
cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Fri, 14 Mar 1997 12:06:23 -0500,
<199703141706.MAA13374 at gza-client1.cam.ov.com>
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Fri, 14 Mar 1997 12:06:23 -0500
From: John Linn <linn at cam.ov.com>
I'd prefer preserving the context as it stands upon an export error,
but can accept either choice.
Ditto. I think preserving the context is the cleaner thing to do, but
it won't be the end of the world if the wg decides differently --- as
long as its written down and documented!
Here, I assume that the partially established context should have to
be explicitly deleted; the initial call in this context establishment
sequence, which was the operation creating the context object,
succeeded.
For gss_init_sec_context(), if we do this, that implies that the
application has to do something different depending on whether the error
happens after the first call to gss_init_sec_context(), or after the
second.
However, a straight forward way to implement the context establishment
looks like this:
do {
maj_stat = gss_init_sec_context(...)
<send token if necessary, etc.>
} while (maj_stat == GSS_S_CONTINUE_NEEDED);
If the application has to do something different depending on whether it
has been the first or second time through the loop, it would be pretty
inconvenient. Perhaps we should make gss_init_sec_context implicitly
free the context, assuming this won't break with existing practice. It
will surely make things easier for the applications programmer.
Are there any applications programmers who can state whether they have
been adopting John Linn's interpretation, and therefore have been
freeing the context if gss_init_sec_context fails on the second (but not
the first) call?
- Ted
Received: from cnri by ietf.org id aa02650; 14 Mar 97 19:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23450;
14 Mar 97 19:01 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <WAA23672 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 22:56:00 GMT
Message-Id: <199703142255.OAA08039 at fluffy.cisco.com>
To: Carlisle Adams <Cadams at entrust.com>
Cc: "'cat-ietf%mit.edu'" <cat-ietf at mit.edu>,
"'petebr at microsoft.com'" <petebr at microsoft.com>
Subject: Re: optimistic snego for performance
In-Reply-To: Your message of "Fri, 14 Mar 1997 16:44:30 EST."
<c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970314214430Z-22742 at bwdldb.ott.bnr.ca>
Date: Fri, 14 Mar 1997 14:55:47 -0800
From: Derrell Piper <piper at cisco.com>
Precedence: bulk
I think this is a useful optimization as well and would like to see it move
forward.
(Hey Carlisle, are you paying me to agree with you all the time? :-)
Derrell
Received: from cnri by ietf.org id aa03219; 14 Mar 97 19:49 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24241;
14 Mar 97 19:49 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA21303 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 21:53:07 GMT
Message-Id: <3329C8A5.66AB at trsvr.tr.unisys.com>
Date: Fri, 14 Mar 1997 16:52:37 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <Roam 0.9.4.858358569.32629.mre at jurassic.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Mike Eisler wrote:
>
> [snip]
>
> SSL and GSS-API simply represent two ways to encapsulate the outputs of
> various security schemes. The core bits each produces are the same. Existing
> application protocols will find one approach more suitable than the other, and
> may find neither appropriate. New ones can design to the approach that makes
> sense, or use an RPC or remote object method system that already has the
> security built in.
>
I'm not sure whether we're agreeing or disagreeing here. I'll restate my
principal concerns, which have been echoed by others during this thread:
(1) business applications need a mechanism independent API through which
to invoke security functionality (if this API happens to be a
straightforward extension of what they're using for transport, that's
probably okay)
(2) the security mechanism underneath the API must be selectable, and
its detailed behavior controlled by, administrative functions distinct
from the business application functionality
(3) as a middleware developer, I need to pick an API to recommend to my
customers. I don't want them embedding toolkits in their apps, only to
realize they've created something they can't control or migrate. Neither
will they, if they look at the situation through a long enough lens.
I don't know how to map these concerns onto what you said above. Can you
help me out?
> > > Also, don't forget about IPSEC. It will be in the competition once there
> > > is an agreement on the socket and XTI extensions for using it.
>
> > IPSEC addresses a different problem. It's only of interest in an
> > intra-enterprise environment using the Internet as a wire, or with a
> > closed group of tightly coupled business partners. It's functionally
> > quite similar to proprietary solutions like NetLock and HannaH, that
> > provide transparent security for all aware transport endpoints, without
> > application involvement. You get bulk encryption and data integrity, but
> > without authentication of application endpoints.
>
> Unless there as been a recent shift in strategy at the IPSEC WG, I disagree.
> Based on section 4.4 of RFC 1825, I conclude that IPSEC has the capability to
> provide per-endpoint authentication. This capability requires application
> involvement, hence API extensions to sockets and XTI.
Okay, here's some real flame bait: <soapbox> I regard user level
authentication provided by IPSEC as a monumental kludge. It says to the
application layer "never mind this pretty layered structure, just assume
what's underneath and drive it." Application protocols should work over
any protocol stack - that's what the layered structure is all about.
This whole idea really pollutes the cleanliness of the layers. As
Abraham Maslow said, "When the only tool you have is a hammer,
everything looks like a nail." I could go on at length, but I won't.
</soapbox>
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from cnri by ietf.org id aa03317; 14 Mar 97 20:00 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24431;
14 Mar 97 20:00 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA25413 at pad-thai.cam.ov.com>; Fri, 14 Mar 1997 23:49:24 GMT
Message-Id: <199703142348.AA08967 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
Orig-To: wray at tuxedo.enet.dec.com (John Wray, Digital DPE,
To: cat-ietf at mit.edu, 508/486-5210 at hw1464.wdf.sap-ag.de,
14-Mar-1997 at hw1464.wdf.sap-ag.de, 0910 at ingwwdf.wdf.sap-ag.de
Date: Fri, 14 Mar 1997 11:42:02 -0500 (EST)
In-Reply-To: <9703141418.AA27457 at us1rmc.bb.dec.com> from "John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910" at Mar 14, 97 09:18:01 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910 wrote:
>
> We haven't yet reached resolution on this question (what happens to the context
> provided to gss_export_sec_context in the case where the routine returns an
> error). There seem to be advocates in favor of always deleting the context
> regardless of the error (so that an effect of calling gss_export_sec_context is
> that the specified context is always released upon return), and others who
> favor keeping the context valid in the event of an error (so that the caller
> can invoke gss_inquire_context() on the context to log a failure message).
>
> Any suggestions on how to proceed? This item is the one unresolved issue that
> I'd like to get sorted out before I send out the next revision of the
> C-bindings.
Try to keep the context valid as hard as possible. Someone might want
to fallback to a single-process model if the context export fails.
Otherwise this wouldn't be possible at all when someone implements a
multimechanism that combines a context-transfer capable mechanism with
a mechanism that doesn't support it, and someone else builds a server
that tries to scale as good as possible.
>
> Actually, there's probably a similar issue around
> init-sec_context/accept_sec_context. If the first invocation of one of these
> calls succeeds, and a subsequent call fails, we should specify whether or not
> the "half-built" context has to be deleted by the application.
AFAIK it is already specified that the application has to delete the
context once it has seen GSS_S_CONTINUE_NEEDED, even if completion fails.
I don't like to see that changed, although all sane implementations should
be able to handle this gracefully either way.
-Martin
Received: from cnri by ietf.org id aa04041; 14 Mar 97 21:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25390;
14 Mar 97 21:03 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA25845 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 00:02:44 GMT
Message-Id: <199703150002.AA046284158 at relay.hp.com>
To: Peter Brundrett <petebr at microsoft.com>
Cc: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>
Subject: Re: optimistic snego for performance
In-Reply-To: petebr's message of Fri, 14 Mar 1997 09:33:55 -0800.
<640796DB4262D0118D3300805FD4EFCF93DC78 at RED-32-MSG.dns.microsoft.com>
Date: Fri, 14 Mar 1997 19:02:37 -0500
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Precedence: bulk
This proposal removes one of my two objections to snego in its current
form, and should be adopted.
[my other objection is that snego doesn't protect the negotiation
against a active downgrade attack.]
- Bill
Received: from ietf.org by ietf.org id aa04468; 14 Mar 97 21:19 EST
Received: from cnri by ietf.org id aa04175; 14 Mar 97 21:13 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa25568; 14 Mar 97 21:13 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA24385 for <@sgi.engr.sgi.com:ietf at cnri.reston.va.us>; Fri, 14 Mar 1997 18:10:43 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id TAA25152 for ietf at cnri.reston.va.us; Fri, 14 Mar 1997 19:10:40 -0700
Date: Fri, 14 Mar 1997 19:10:40 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199703150210.TAA25152 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: re: bcc's (was Authenticated Mail)
Source-Info: From (or Sender) name not authenticated.
] > > whether it came via my ISP account/domain or via one of my custom
] > > domain name
] > > addresses. Thus, I don't even know what name to ask to have removed!
] > >
] > Then it wouldn't be a "BCC," a blind copy. One caveat to
]
] There is nothing fundamental in the notion of a blind copy which requires
] removal of the blind addressee from the copy delivered to that copy.
]
] I've been b'ccd many times on physical memos/mail and always have a
] bcc cover sheet with my address on it. No other way to be sure it was
] intended for me.
Who says the blind addressee is removed?
The envelope is not the same as the message itself.
If your SMTP code does not include "for xxxx" in the Received: line or
your mail user agent does not let you see the full headers upon demand,
then fix them. There's no need to change the protocol.
It is nice when the originating MUA sends a separate copy with a
special cover sheet, but that is also not a protocol issue.
Vernon Schryver, vjs at sgi.com
Received: from cnri by ietf.org id aa06183; 14 Mar 97 21:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26148;
14 Mar 97 21:56 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <AAA26065 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 00:07:04 GMT
Message-Id: <199703150006.AA09502 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
Orig-To: wray at tuxedo.enet.dec.com (John Wray)
To: cat-ietf at mit.edu
Date: Fri, 14 Mar 1997 11:42:02 -0500 (EST)
In-Reply-To: <9703141418.AA27457 at us1rmc.bb.dec.com> from "John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910" at Mar 14, 97 09:18:01 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910 wrote:
>
> We haven't yet reached resolution on this question (what happens to the context
> provided to gss_export_sec_context in the case where the routine returns an
> error). There seem to be advocates in favor of always deleting the context
> regardless of the error (so that an effect of calling gss_export_sec_context is
> that the specified context is always released upon return), and others who
> favor keeping the context valid in the event of an error (so that the caller
> can invoke gss_inquire_context() on the context to log a failure message).
>
> Any suggestions on how to proceed? This item is the one unresolved issue that
> I'd like to get sorted out before I send out the next revision of the
> C-bindings.
Try to keep the context valid as hard as possible. Someone might want
to fallback to a single-process model if the context export fails.
Otherwise this wouldn't be possible at all when someone implements a
multimechanism that combines a context-transfer capable mechanism with
a mechanism that doesn't support it, and someone else builds a server
that tries to scale as good as possible.
>
> Actually, there's probably a similar issue around
> init-sec_context/accept_sec_context. If the first invocation of one of these
> calls succeeds, and a subsequent call fails, we should specify whether or not
> the "half-built" context has to be deleted by the application.
AFAIK it is already specified that the application has to delete the
context once it has seen GSS_S_CONTINUE_NEEDED, even if completion fails.
I don't like to see that changed, although all sane implementations should
be able to handle this gracefully either way.
-Martin
Received: from ietf.org by ietf.org id aa15897; 15 Mar 97 2:49 EST
Received: from cnri by ietf.org id aa15579; 15 Mar 97 2:41 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03466;
15 Mar 97 2:41 EST
Received: from mail1.socomm.net by venera.isi.edu (5.65c/5.61+local-26)
id <AA11051>; Fri, 14 Mar 1997 23:38:31 -0800
Received: from seraphim.memphisonline.com (du-138.tch3nsc.memphisonline.com [207.15.162.138]) by mail1.socomm.net (8.8.5/8.6.12) with SMTP id AAA03355; Sat, 15 Mar 1997 00:45:33 -0600
Message-Id: <3.0.1.32.19970314233311.006b39c4 at mail.memphisonline.com>
X-Sender: seraphim at mail.memphisonline.com
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Fri, 14 Mar 1997 23:33:11 -0600
To: seraphim at memphisonline.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Len Ruck <seraphim at memphisonline.com>
Cc: distribution: ;
Source-Info: From (or Sender) name not authenticated.
t.com,
iar at helix.xiii.com, ibb at boursy.news.erols.com, ibm at svpal.svpal.org,
ic1 at fdma.fdma.com, icd at ionews.ionet.net, icm at news1.iamerica.net,
id7 at twwells.com, ietf at venera.isi.edu, if3 at chronicle.concentric.net,
iff at grog.ric.edu, ifg at chronicle.concentric.net,
igeldard at capital.demon.co.uk, ihi at natasha.rmii.com,
iiiybrmahzewso at harding.demon.co.uk, iimagine at onramp.net,
ik2 at murrow.corp.sgi.com, il at taunivm.tau.ac.il, ilu at twwells.com,
ima at twwells.com, imalunatic at the.aslyum, in at individual.net,
inezewcm at ferjani.demon.co.uk, inf at iname.com, inkygrr at airmail.net,
inoctavo at mail.dotcom.fr, interest at relay.sgi.com,
internet at munnari.oz.au, ion at pacbell.net,
ip3spwauwqkzewhj at harding.demon.co.uk, ipf at newsops.execpc.com,
ipsnake at redline.ru, ir0 at geolabserver.geo,
irelandurby1_7m8 at maestro.clari.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
>I was searching around the Internet for some Christian discussion groups,
and thought you might be interested in our bookstore. We carry early
Christian writings, Bible commentaries from the ancient Church, Eastern
Orthodox books. We have accumulated a rare collection of works from some
of the most inspired Christians of all ages.
We have books in all kinds of categories, from Spiritual Life, to the
Desert Fathers, Holy Women to Family Life, Russian, Greek, Byzantine,
Coptic and Early Church history to the present. It is quite a unique
collection.
Our bookstore is online at URL:
http://ourworld.compuserve.com/homepages/Seraphim_Rose_Books
We also are publishing a series of pamphlets called,
"WHAT THE BIBLE SAYS ABOUT..." So far we have produced the following titles:
PRAYER & FASTING
PRIDE & HUMILITY
WEALTH & POVERTY
WORLDLINESS & GODLINESS
THE LAST DAYS
GOOD WORKS
FAITH & WORKS
THE NAME OF THE LORD
SAINTS & HOLINESS
more titles will be forthcoming.
The price for these pocket sized pamphlets is between 50 and 75 cents each,
plus postage. They vary from 14 to 24 pages.
Please forgive this unsolicited email if you are uninterested.
Pray for us
Len
>>
>
%%% overflow headers %%%
Cc: f9b at owl.jmu.edu, f9s at pith.uoregon.edu, fabianandrade at mail.telepac.pt,
fact at fiction.com, fact at non.fiction, fail at taunivm.tau.ac.il,
fantome at netdepot.com, fcc at miranda.gmrc.gecm.com,
ferjani at ferjani.demon.co.uk, fgds5sr.040397.1.jensbender at delphi.com,
fgzew1n at tucana.demon.co.uk, filbur at unix.as, filbur at unix.asb.com,
filters at arn.net, firearms at ns1.rutgers.edu, fireweaver at insync.net,
fishhook at access.digex.net, fkg at hecate.umd.edu,
fla at mtinsc03.worldnet.att.net, flak at online.no, fmc at news.snowcrest.net,
fmcwezaudtizewly at harding.demon.co.uk, fmi at news.is, fmi at news.istar.ca,
fnh at chronicle.concentric.net, fnr at vixen.cso.uiuc.edu,
foetusuber at aol.com, fogarty at netcom.com, fogartye6pgvn.2vz at netcom.com,
fox at stt.msu.edu, fph at twwells.com, franzm at cebu.weblinq.com,
freedman at netmedia.net.il, freenet at otol.fi, friar at helix.xiii.com,
fso at fdma.fdma.com, fsphoenix at aol.com, ftg at kew.globalnet.co.uk,
fui at lander.es, futint at primenet.com, g0 at news.nd.edu,
g17 at knot.queensu.ca, g2g at saint.win.or.jp, g2j at news.istar.ca,
g38 at whitecliff.sierra.net, g4s at duke.telepac.pt,
g57 at hondo.cyberverse.com, g6m at twwells.com, g6o at clarknet.clark.net,
g7f at fdma.fdma.com, g7f at knot.queensu.ca, g7i at mtinsc03.worldnet.att.net,
g8s at news.umbc.edu, g90 at news.acns.nwu.edu, gahn at wiwi.uni,
gary at dialnet.nett, gatebau at euterpe.owl.de, gators at worldnet.att,
gators at worldnet.att.net, gbcxkbaxon9yewpf at aristos.demon.co.uk,
gblack at midland.co.nz, gbugge at mail.bcpl.lib.md.us,
gc8 at frazier.backbone.ou.edu, gct at fdma.fdma.com, gdq at knot.queensu.ca,
gdy52150 at prairie.lakes.com, geg at news.acns.nwu.edu, geoffb at webspan.net,
gf at goldfish.co.uk, gh6 at usenet.rpi.edu, ghp at twwells.com,
gmcauli at ibm.net, gmooth at sprynet.com, go3 at twwells.com, god at big.sky.net,
godzilla at sover.net, goextreme at hotmail.com, gorilla at elaine.drink.com,
gothrobert at popalex1.linknet.net, gp3 at twwells.com,
gq2 at synthemesc.insync.net, gr0 at ucsbuxb.ucsb.edu, gr3 at twwells.com,
gr8tao at aol.com, grandma at axxess.mountain.net, grants at note.nsf.gov,
greatdane at mindspring.com, greg9 at dlcwest.com, grimes at fcol.com,
grisha at athena.mit.edu, grs at lore.sprynet.com, grydove at aol.com,
gst at cybernews.cyberus.ca, gstarr at epix.net, gtp at pcisys.net,
gua at pith.uoregon.edu, gundlach at geocities.com, gustitus at idir.net,
gypsy95 at seanet.com, gzag75a at prodigy.com, h3b at mochi.lava.net,
h3n at fdma.fdma.com, h5a at crow.cybercomm.net, h5bbxnt.tlm at delphi.com,
h6o at dove.qut.edu.au, hackers at freebsd.org, hamster at nas.com,
hanke6w4fm.f72 at netcom.com, hard.to at plea.se, hargrove at ucs.india,
hargrove at ucs.indiana.edu, harttc at qtm.net, haters at mc.lcs.mit.edu,
hayward at umcs.m, hayward at umcs.maine.edu, hbe at twwells.com,
hbj at twwells.com, hbk at usenet.rpi.edu, hc7 at twwells.com,
healing at healing.demon.co.uk, heamfgfzew9d at aldred.demon.co.uk,
hellenicfighter at athenia.com, hendrix at magick.net,
henrysv at intermapping.com, herfj40 at aol.com, heuston at onthenet.com.au,
heybaby at ripco.com, hezewce at ferjani.demon.co.uk, hf0_001 at ppp.hooked.net,
hfq8oc1w165w at uunet.ca, hin at gte.net, hkl at chronicle.concentric.net,
hkt at wwa.com, hl7 at lex.zippo.com, hlarsen at halling.org.com,
hmiddlet at worldnet.att.net, hmjohans at online.no, hn1 at twwells.com,
hnia at aol.com, ho7 at van1s03.cyberion.com, holly at sybase.com,
holocaustur5wy_7m8 at maestro.clari.net, hoopdie at aol.com,
hosts at nnsc.nsf.net, hpj3 at u.washing, hpj3 at u.washingto,
hpj3 at u.washington.edu, hps at mackrel.fishnet.net, hpv at sonoma.edu,
hr7 at epx.cis.umn.edu, hre at usenet.rpi.edu, hud at knot.queensu.ca,
hurtwood at interpath.com, hz at bohunt.demo, hz at bohunt.demon.cot,
hzewum at harding.demon.co.uk, i at cocoa.brown.edu, i10 at news.missouri.edu,
i12 at twwells.com, i21bkmahzewtb at harding.demon.co.uk,
i6c at felix.seas.gwu.edu, i72 at news.acns.nwu.edu, i8g at owl.jmu.edu,
i9d at kew.globalnet.co.uk, i9p at nnrp1.news.primene
%%% end overflow headers %%%
Received: from cnri by ietf.org id aa17278; 15 Mar 97 4:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04647;
15 Mar 97 4:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA08356 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 07:19:54 GMT
To: Johan Danielsson <joda at pdc.kth.se>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703120927.aa26530 at ietf.org> <xofybbtuhvu.fsf at blubb.pdc.kth.se>
<t53rahksjyd.fsf at rover.cygnus.com> <xofu3mgv2cq.fsf at blubb.pdc.kth.se>
<t534teguwyf.fsf at rover.cygnus.com> <xofrahjv7sx.fsf at blubb.pdc.kth.se>
From: Marc Horowitz <marc at provo17.modem.xmission.com>
Date: 14 Mar 1997 23:19:29 -0800
In-Reply-To: joda at pdc.kth.se's message of 13 Mar 1997 21:46:54 +0100
Message-Id: <t53hgid1v26.fsf at provo17.modem.xmission.com>
Lines: 7
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
joda at pdc.kth.se (Johan Danielsson) writes:
>> This makes this an update of, rather than a complement to, 1510?
I suppose it does.
Marc
Received: from cnri by ietf.org id aa17926; 15 Mar 97 5:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05633;
15 Mar 97 5:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA08349 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 07:19:13 GMT
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: cat-ietf at mit.edu
Subject: Re: kerb-chg-password
References: <9703131947.AA04612 at dcl.MIT.EDU>
From: Marc Horowitz <marc at provo17.modem.xmission.com>
Date: 14 Mar 1997 23:18:56 -0800
In-Reply-To: "Theodore Y. Ts'o"'s message of Thu, 13 Mar 1997 14:47:52 -0500
Message-Id: <t53iv2t1v33.fsf at provo17.modem.xmission.com>
Lines: 12
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"Theodore Y. Ts'o" <tytso at MIT.EDU> writes:
>> Does this imply that the server has to keep a cache of responses so it
>> can resend the ack? Or does the server send a "wrong password" error,
>> which the client then has to try to decipher?
Neither. The client generates a new request every time. The server
just has to remember the password (which it has to do anyway). If the
request is to change the password to what it currently is, then the
database is left unchanged, and an ack is sent to the client.
Marc
Received: from ietf.org by ietf.org id aa18152; 15 Mar 97 5:35 EST
Received: from AIC.NET by ietf.org id aa18061; 15 Mar 97 5:31 EST
Received: by aic.net for ietf at ietf.org at Sat, 15 Mar 1997 13:28:55 +0300 (GMT)
Message-Id: <199703151028.NAA11742 at aic.net>
Subject: Returned mail: unknown mailer error 1 (fwd)
To: ietf at ietf.org
Date: Sat, 15 Mar 1997 13:28:54 +0300 (GMT)
Sender:ietf-request at ietf.org
From: Edgar Danielyan <edd at acm.org>
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Very annoying. This is unacceptable in the case of InterNIC...
-edd
Forwarded message:
> From postmaster Sat Mar 15 13:21 GMT 1997
> Date: Sat, 15 Mar 1997 05:21:32 -0500 (EST)
> From: Mail Delivery Subsystem <MAILER-DAEMON at internic.net>
> Message-Id: <199703151021.FAA24820 at opsmail.internic.net>
> To: <edd at AIC.NET>
> MIME-Version: 1.0
> Subject: Returned mail: unknown mailer error 1
> Auto-Submitted: auto-generated (failure)
> Content-Type: multipart/report; report-type=delivery-status;
> boundary="FAA24820.858421292/opsmail.internic.net"
> Content-Length: 2330
>
> This is a MIME-encapsulated message
>
> --FAA24820.858421292/opsmail.internic.net
>
> The original message was received at Sat, 15 Mar 1997 05:21:30 -0500 (EST)
> from rs3.internic.net [198.41.0.8]
>
> ----- The following addresses had permanent fatal errors -----
> "| /home/reg/mts/bin/spool_mail -u hostmast -l"
> (expanded from: hostmaster-queue)
>
> ----- Transcript of session follows -----
> 554 "| /home/reg/mts/bin/spool_mail -u hostmast -l"... unknown mailer error 1
>
> --FAA24820.858421292/opsmail.internic.net
> Content-Type: message/delivery-status
>
> Reporting-MTA: dns; opsmail.internic.net
> Received-From-MTA: DNS; rs3.internic.net
> Arrival-Date: Sat, 15 Mar 1997 05:21:30 -0500 (EST)
>
> Final-Recipient: RFC822; hostmaster at opsmail.internic.net
> Action: expanded (to multi-recipient alias)
> Status: 2.0.0
> Last-Attempt-Date: Sat, 15 Mar 1997 05:21:32 -0500 (EST)
>
> Final-Recipient: RFC822; hostmaster at opsmail.internic.net
> X-Actual-Recipient: RFC822; | /home/reg/mts/bin/spool_mail -u hostmast -l at opsmail.internic.net
> Action: failed
> Status: 5.0.0
> Last-Attempt-Date: Sat, 15 Mar 1997 05:21:32 -0500 (EST)
>
> --FAA24820.858421292/opsmail.internic.net
> Content-Type: message/rfc822
>
> Return-Path: <edd at aic.net>
> Received: from rs3.internic.net (rs3.internic.net [198.41.0.8]) by opsmail.internic.net (8.8.5/8.8.0) with SMTP id FAA24819 for <hostmaster at internic.net>; Sat, 15 Mar 1997 05:21:30 -0500 (EST)
> Received: (qmail 15041 invoked from network); 15 Mar 1997 10:21:29 -0000
> Received: from aic.net (195.250.64.80)
> by rs3.internic.net with SMTP; 15 Mar 1997 10:21:29 -0000
> Received: by aic.net for hostmaster at internic.net at Sat, 15 Mar 1997 13:21:26 +0300 (GMT)
> Message-Id: <199703151021.NAA11705 at aic.net>
> Subject: Problems with authorization
> To: hostmaster at internic.net
> Date: Sat, 15 Mar 1997 13:21:25 +0300 (GMT)
> From: edd at acm.org (Edgar Danielyan)
> Content-Type: text
>
Received: from cnri by ietf.org id aa20313; 15 Mar 97 8:11 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07949;
15 Mar 97 8:11 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <LAA13245 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 11:32:50 GMT
Date: Sat, 15 Mar 1997 06:32:40 -0500 (EST)
From: Rich Salz <rsalz at osf.org>
Message-Id: <199703151132.GAA14942 at sulphur.osf.org>
To: bjb at trsvr.tr.unisys.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
Cc: cat-ietf at mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Well, gee, if you're gonna rule out anything that disagrees with you
as being out of scope ...
How about where the "admin" isn't the host admin, but is instead somewhere
else? Suppose the SEC requires 3des to encrypt all financial transactions,
and the investment bank must make sure that insiders don't use weak
crypto to allow Boesky++ to take certain advantages? This seems like
another case where the program knows best.
/r$
Received: from ietf.org by ietf.org id aa28288; 15 Mar 97 15:23 EST
Received: from songbird.com by ietf.org id aa28033; 15 Mar 97 15:15 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id MAA26285; Sat, 15 Mar 1997 12:11:18 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703152011.MAA26285 at songbird.com>
Subject: Re: call for a new email infrastructure
To: Phil Karn <karn at qualcomm.com>
Date: Sat, 15 Mar 1997 12:11:18 -0800 (PST)
Cc: paulh at imc.org, ietf at ietf.org
In-Reply-To: <199703140524.VAA22666 at servo.qualcomm.com> from "Phil Karn" at Mar 13, 97 09:24:52 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Phil Karn allegedly said:
>
> >Receiver filtering today is only available to skilled people with the time
> >to implement it for themselves. I'd like to see methods (technical and/or
> >legal) be put into place to make receiver filtering easier for everyone.
>
> Sounds like a business opportunity for someone!
No kidding.
[...]
> Let's give the technical approaches a serious go before we give up.
>
> And if we can't completely solve the spam problem, that'll be
> something I'll just have to accept in exchange for access to one of
> the most powerful communication mediums ever made.
Thinking in the long term:
Two things are missing from the current email infrastructure --
authentication and intelligent filtering.
There is negative feedback in the system -- spam makes email
unattractive, and an unattractive medium is not worth the trouble to
spam. Effective client-side filtering is even stronger negative
feedback for spam. But spam first has to become bad enough for
there to be incentive to develop good client-side filtering. Once
good client-side filtering is in place, the value of spam diminishes
considerably, and focussed marketing strategies will become the
norm.
Thus, attempts to control spam are really misguided. We should
welcome the growth of spam, because it creates the market potential
for authenticated email with intelligent filtering, two things we
really need anyway, just to control information flow.
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html
Received: from cnri by ietf.org id aa29419; 15 Mar 97 16:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16012;
15 Mar 97 16:05 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA27622 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 19:30:20 GMT
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu, 508/486-5210 at hw1464.wdf.sap-ag.de,
14-Mar-1997 at hw1464.wdf.sap-ag.de, 0910 at ingwwdf.wdf.sap-ag.de
Subject: Re: gss_export_sec_context()
References: <199703142348.AA08967 at sap-ag.de>
From: Sam Hartman <hartmans at mit.edu>
Date: 15 Mar 1997 14:30:12 -0500
In-Reply-To: Martin Rex's message of Fri, 14 Mar 1997 11:42:02 -0500 (EST)
Message-Id: <tslendhq7gb.fsf at luminous.MIT.EDU>
Lines: 27
X-Mailer: Gnus v5.2.37/Emacs 19.34
Precedence: bulk
>>>>> "Martin" == Martin Rex <martin.rex at sap-ag.de> writes:
Martin> John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910
Martin> wrote:
>> We haven't yet reached resolution on this question (what
>> happens to the context provided to gss_export_sec_context in
>> the case where the routine returns an error). There seem to be
>> advocates in favor of always deleting the context regardless of
>> the error (so that an effect of calling gss_export_sec_context
>> is that the specified context is always released upon return),
>> and others who favor keeping the context valid in the event of
>> an error (so that the caller can invoke gss_inquire_context()
>> on the context to log a failure message).
>>
>> Any suggestions on how to proceed? This item is the one
>> unresolved issue that I'd like to get sorted out before I send
>> out the next revision of the C-bindings.
Martin> Try to keep the context valid as hard as possible.
Martin> Someone might want to fallback to a single-process model
Martin> if the context export fails.
What if it is impossible under the mechanism to do so? What
error do you propose be returned?
--Sam
Received: from cnri by ietf.org id aa00447; 15 Mar 97 16:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17084;
15 Mar 97 16:56 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA26760 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 19:06:02 GMT
Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970315185040Z-22889 at bwdldb.ott.bnr.ca>
From: Michel Ranger <rangerm at entrust.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'CryptoAPI at listserv.msn.com'" <CryptoAPI at listserv.msn.com>,
"'ssl-talk at netscape.com'" <ssl-talk at netscape.com>,
"'bjb at trsvr.tr.unisys.com'" <bjb at trsvr.tr.unisys.com>
Subject: RE: GSS-API and SSL - their coexistence, and related issues
Date: Sat, 15 Mar 1997 13:50:40 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 68 TEXT
Precedence: bulk
comments below
>----------
>From: bjb at trsvr.tr.unisys.com[SMTP:bjb at trsvr.tr.unisys.com]
>Sent: Wednesday, March 12, 1997 4:33 PM
>To: cat-ietf at mit.edu; CryptoAPI at listserv.msn.com; ssl-talk at netscape.com
>Subject: GSS-API and SSL - their coexistence, and related issues
>
>Judging by the traffic level, it seems to me that there's a lot of
>apathy on the question of the merits and feasibility of putting GSS-API
>over SSL. Which leads me to think that perhaps this is the wrong
>question. I want to try to summarize what I think are the requirements,
>and what the options and issues are.
>
>(in what follows, I'm using "mechanism" in its jargon sense, to indicate
>a GSS mechanism (for example, Kerberos))
>
>Requirements
>1) Mechanism-independent API for applications and middleware to use.
>
>2) Transport-independent mechanisms
>
>3) CryptoAlgorithm-independent mechanisms.
>
>
>Possible Options
>
>1) GSS-API as the mechanism-independent API.
>Issues:
>(a) Application writers seem not to like GSS-API. It seems very
>cumbersome to program.
>(b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
>to require much effort and some compromise.
>(c) Popular support for GSS-API seems weak. It's now the native
>interface to Kerberos, but the only other mechanism so far using it is
>Entrust's SPKM (an X.509-based public key mechanism). No other
>developer, to the best of my knowledge, has embraced SPKM. (Can anyone
>from Entrust comment on the uptake of GSS-API in the Entrust user base?)
Yes, we implemented SPKM under GSS-API.
Some other vendor(s) did successful interop testing with Entrust on
SPKM/GSS-API.
The activities were under NDA, the vendors involved have posted to this
list, I'll
let them volunteer their information if they choose to.
There are a number Entrust-ready applications, Entrust resellers, VARs
and OEMs
using GSS-API/SPKM. They are listed on our web site.
http:www.entrust.com.
The attractions too many of the partners and customers are :
- the API approach vs the protocol argument
- the migration from GSS-API in the Kerberos/DCE markets to public key
technology
- the fact SPKM was reviewed and analyzed by CAT
- hi-level APIs where the crypto bit banging is not exposed
- SSLv2 was the alternative at the time, many felt it needed some more
attention and analysis
- platform independent API
In the end Entrust builds APIs to what is requested. SPKM was the
message we
were/are hearing from customers in the "GSS" market.
Other stuff deleted
>
Received: from cnri by ietf.org id aa03738; 15 Mar 97 20:12 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20443;
15 Mar 97 20:12 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA05135 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 23:22:55 GMT
To: Mike Eisler <Michael.Eisler at eng.sun.com>
Cc: bjb at trsvr.tr.unisys.com, cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <Roam 0.9.4.858358569.32629.mre at jurassic.eng.sun.com>
From: Marc Horowitz <marc at splash.cygnus.com>
Date: 15 Mar 1997 15:22:16 -0800
In-Reply-To: Mike Eisler's message of Fri, 14 Mar 1997 08:56:09 -0800 (PST)
Message-Id: <t53bu8khhav.fsf at splash.cygnus.com>
Lines: 15
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Mike Eisler <Michael.Eisler at eng.sun.com> writes:
>> SSL and GSS-API simply represent two ways to encapsulate the
>> outputs of various security schemes. The core bits each produces
>> are the same. Existing application protocols will find one approach
>> more suitable than the other, and may find neither appropriate. New
>> ones can design to the approach that makes sense, or use an RPC or
>> remote object method system that already has the security built in.
GSSAPI is designed to be appropriate for the large majority of
connection-oriented protocols. If you can think of a reason it's not
appropriate for some class of applications or protocols, I'd like to
hear it, so we can fix it.
Marc
Received: from cnri by ietf.org id aa05084; 15 Mar 97 21:06 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21758;
15 Mar 97 21:06 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA05508 at pad-thai.cam.ov.com>; Sat, 15 Mar 1997 23:35:12 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: gss_export_sec_context()
References: <9703141418.AA27457 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at splash.cygnus.com>
Date: 15 Mar 1997 15:34:52 -0800
In-Reply-To: "John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910"'s message of Fri, 14 Mar 97 09:18:01 EST
Message-Id: <t53afo4hgpv.fsf at splash.cygnus.com>
Lines: 29
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, 508/486-5210 14-Mar-1997 0910" <wray at tuxedo.enet.dec.com> writes:
>> There seem to be advocates in favor of always deleting the context
>> regardless of the error (so that an effect of calling
>> gss_export_sec_context is that the specified context is always
>> released upon return), and others who favor keeping the context
>> valid in the event of an error (so that the caller can invoke
>> gss_inquire_context() on the context to log a failure message).
Nit: another reason to keep the context valid is to keep using it, not
just to log a failure.
In any case, there is a middle ground:
Mechanisms should strive to keep the context handle valid, but
applications should be aware that the mechanism might not be able to
do this, invalidating the handle if the call to export_sec_context
fails. This would mean that applications *must* delete a sec_context
if the export fails. If we do this, we need to figure out what the
various context calls do in this state. It would seem that
inquire_context would be ok, but other calls should fail, probably
with GSS_S_NO_CONTEXT.
This is the most complex, but the most powerful, option, I think.
Otherwise, I would prefer always deleting the context, rather than
specifying behavior which may be inachievable.
Marc
Received: from cnri by ietf.org id aa13674; 15 Mar 97 23:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01163;
15 Mar 97 23:56 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA13072 at pad-thai.cam.ov.com>; Sun, 16 Mar 1997 03:13:23 GMT
Date: Sat, 15 Mar 1997 22:10:49 -0500
Message-Id: <9703160310.AA06044 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Marc Horowitz <marc at splash.cygnus.com>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
In-Reply-To: Marc Horowitz's message of 15 Mar 1997 15:34:52 -0800,
<t53afo4hgpv.fsf at splash.cygnus.com>
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Marc Horowitz <marc at splash.cygnus.com>
Date: 15 Mar 1997 15:34:52 -0800
Mechanisms should strive to keep the context handle valid, but
applications should be aware that the mechanism might not be able to
do this, invalidating the handle if the call to export_sec_context
fails. This would mean that applications *must* delete a sec_context
if the export fails. If we do this, we need to figure out what the
various context calls do in this state. It would seem that
inquire_context would be ok, but other calls should fail, probably
with GSS_S_NO_CONTEXT.
I like the first part, but why should applications *must* delete a
sec_context if the export fails? Instead, just require them to check
whether or not the context is still good by using inquire_context, and
and if it returns GSS_S_NO_CONTEXT, they'll know that the context is no
longer there. If applications don't do that, and they call other GSSAPI
calls, those calls will fail with GSS_S_NO_CONTEXT --- what's wrong with
that?
- Ted
Received: from ietf.org by ietf.org id aa15997; 16 Mar 97 1:27 EST
Received: from shell1.aimnet.com by ietf.org id aa15926; 16 Mar 97 1:26 EST
Received: from dial-berk1-23.iway.aimnet.com (dial-berk1-23.iway.aimnet.com [204.118.73.23]) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id WAA14260; Sat, 15 Mar 1997 22:23:15 -0800 (PST)
Date: Sat, 15 Mar 1997 22:23:15 -0800 (PST)
Message-Id: <199703160623.WAA14260 at shell1.aimnet.com>
X-Authentication-Warning: shell1.aimnet.com: dial-berk1-23.iway.aimnet.com [204.118.73.23] didn't use HELO protocol
X-Sender: jed at aimnet.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Kent Crispin <kent at songbird.com>
Sender:ietf-request at ietf.org
From: "James E. [Jed] Donnelley" <jed at webstart.com>
Subject: Re: a new email infrastructure, comm. label fraud
Cc: ietf at ietf.org, Phil Karn <karn at qualcomm.com>, paulh at imc.org
Source-Info: From (or Sender) name not authenticated.
At 12:11 PM 3/15/97 -0800, Kent Crispin <kent at songbird.com> wrote:
>Thus, attempts to control spam are really misguided. We should
>welcome the growth of spam, because it creates the market potential
>for 1. authenticated email with 2. intelligent filtering, two things we
>really need anyway, just to control information flow.
I'm not so sure about this Kent. 1. It seems to me that SPAM
is already effectively authenticated. If you can't identify
who sent it (at least the party with the vested interest,
who must be the ultimate source) then you can't communicate
with the sender to buy whatever it is they are selling. Is
this often a problem with real SPAM? That would surprise me.
If SPAM is anonymous then what is the motivation for sending it?
Even if it had an authenticated sender, how would that help?
If there was no disincentive to send it, people sending SPAM
would have no particular concern being clear about who
they are. Except perhaps for the concern now about being blasted
by people who don't like getting the SPAM. I actually think
that such deliberate harrasment should be illegal, but that
is another story.
2. As for filtering, if one wants to be open for unsolicited
mail (e.g. from a long lost friend) then it seems to me that
SPAM can be made to look like such mail to just about any level
of "intelligent filtering." I think that doing so would
in some sense be fraudulent, but then we are talking about
another sort of solution - social/legal.
I am reaching a bit here, and going against my typically
libertarian leanings, but I believe I would favor a law
(perhaps existing law?) that enforces some sort of essential
truth in communication. I believe that solicitations should
be labeled directly as such. It seems to me quite clear what
they are. I think perhaps another possible approach would
be to require that machine generated copies be labeled
as to roughly how many copies were generated.
With information like that available it wouldn't take
"intelligent" filtering to identify SPAM.
On the other hand, I think perhaps the machine aspect
isn't significant. I consider mass telephonings
equivalent to SPAM. As is "junk" mail. I would like
to have all of these clearly labeled and I would like
to have the opportunity to "filter" (i.e. not receive)
them. I am not saying that I would exercise that option.
I am not sure I would. Sometimes I find such mass
communication useful.
One problem with mass e-mailings is that they are so
close to being completely free (unlike telephone campaigns
and postal mail). This means that anybody can send
SPAM for any crackpot idea, product, or service - without
even an effective profit motive to limit the ridiculous.
I have seen some of the discussion surrounding this
cost issue. I would rather not tackle that part of
it directly, but let the market work it out. However,
when it comes to e-mail fraudlently representing itself
as something other than SPAM, I think I would like to
see that illegal. Ditto telephone solicitations and
postal junkmail. I would probably accept junk postal mail
and SPAM, but I would turn off telephone solicitations (they
take too much time) IF I had the option(s) I think.
Why shouldn't I? The cost is mine as the receiver...
This crime is not victimless - the receiver is the
victim. If you just consider the cost to the receivers
of dealing with SPAM (or postal or telephone "SPAM"),
the cost (figured per person-hour) could easily run into
the thousands of dollars. I believe this sort of
larceny should be controlled.
--Jed http://www.webstart.com/cc/jed-signature.html
Received: from ietf.org by ietf.org id aa00569; 16 Mar 97 10:37 EST
Received: from quicklink.com by ietf.org id aa00333; 16 Mar 97 10:32 EST
Received: from host (dialup-006.quicklink.com) by www (5.x/SMI-SVR4)
id AA23166; Sun, 16 Mar 1997 10:29:32 -0500
Message-Id: <332BCA59.2762 at quicklink.com>
Date: Sun, 16 Mar 1997 11:24:25 +0000
Sender:ietf-request at ietf.org
From: Stephen Messer <smesser at quicklink.com>
Reply-To: smesser at quicklink.com
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: a little help
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I hope that this does not offend anyone on the list, but I thought that
this would be the best place to get an answer. I have been following
silently the lists discussion for some time, and while I would have
prefered to enter the discussion with more of a pertinent question I
have to ask for a different kind of help. I work for an american
research institute and have been asked by a reporter from a major
magazine if I can recommend a Negrophonte type on the internet (in
europ)who can be interviewed for an upcomming article. Any suggestions
would be more tehn welcomed, and once again I apologize if this message
offends any on the list.
Steve
Received: from ietf.org by ietf.org id aa05864; 16 Mar 97 16:42 EST
Received: from cnri by ietf.org id aa05574; 16 Mar 97 16:32 EST
Received: from village.ios.com by CNRI.Reston.VA.US id aa18659;
16 Mar 97 16:32 EST
Received: from localhost (davin at localhost) by village.ios.com (8.8.3/8.6.12) with SMTP id QAA09147; Sun, 16 Mar 1997 16:29:48 -0500 (EST)
Date: Sun, 16 Mar 1997 16:29:48 -0500 (EST)
Sender:ietf-request at ietf.org
From: David Vineberg <davin at village.ios.com>
To: davin at village.ios.com
cc: ietf at CNRI.Reston.VA.US
Subject: Internet Monthly Report - October 1995
Message-ID: <Pine.BSF.3.95.970316162444.8946A-100000 at village.ios.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
ctober 1995
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to "IMR at ISI.EDU".
Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
Details on obtaining the current IMR, or back issues, via FTP or
EMAIL may be obtained by sending an EMAIL message to "rfc-
info at ISI.EDU" with the message body "help: ways_to_get_imrs". For
example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
or URL: http://www.isi.edu/in-notes/imr/
Cooper [Page 1]
Internet Monthly Report October 1995
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
FEDERAL NETWORKING COUNCIL (FNC) . . . . . . . . . . . . page 12
Federal Internet Security Workshop. . . . . . . . . . . page 13
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 16
Registration Services . . . . . . . . . . . . . . . . . page 16
Directory Services. . . . . . . . . . . . . . . . . . . page 17
US Domain Registry. . . . . . . . . . . . . . . . . . . page 18
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 21
UCL . . .. . . . . . . . . . . . . . . . . . . . . . . . . page 23
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 24
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 29
Cooper [Page 2]
Internet Monthly Report October 1995
INTERNET ARCHITECTURE BOARD
The minutes of the IAB back to 1990 are available for anonymous ftp
access on host ftp.isi.edu, directory /pub/IAB, or via the IAB
World-Wide Web page with URL http://www.iab.org/iab/.
Brian Carpenter IAB Chair
INTERNET ENGINEERING REPORTS
----------------------------
1. Let me remind everyone that the next IETF meeting will be in
Dallas, Texas from December 4-8, 1995, with the Newcomers'
Orientation and Registration Reception being held on Sunday,
December 3. The Dallas IETF meeting is being hosted by MCI.
Logistic information has been posted to the IETF Announcement
list, and the Secretariat is accepting registrations. The IETF
meeting fee for the Dallas meeting will be $200.
Following Dallas, the IETF will be meeting in Los Angeles,
California from March 4-8, 1996. There will not be a local host
for this meeting, but the terminal room facilities will be
provided by Interop. Following Los Angeles, the IETF will be
meeting in Montreal, Quebec, Canada from June 24-28, 1996. If
this date looks familiar, it is the same date as INET '96! This
is not a "joint" meeting, but both will be held in the Montreal
Convention Center.
Once all the arrangements have been made, notifications will be
sent to the IETF Announcement list. Remember that information
on future IETF meetings can be always be found in the file
0mtg-sites.txt which is located on the IETF shadow directories.
This information can also be viewed from the IETF Home Page on
the Web. The URL is:
http://www.ietf.cnri.reston.va.us
2. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These files
are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
September 28, 1995 (iesg.95-09-28)
October 12, 1995 (iesg.95-10-12)
Cooper [Page 3]
Internet Monthly Report October 1995
3. The IESG approved or recommended the following 11 Protocol
Actions during the month of October, 1995:
o Guidelines for creation, selection, and registration of an
Autonomous System (AS) be published as a Best Current
Practices RFC.
o ARP Extension - UNARP be published as an Experimental
Protocol.
o SMTP Service Extension for Message Size Declaration be
published as an Internet Standard.
o SMTP Service Extensions be published as an Internet Standard.
o SMTP Service Extension for Delivery Status Notifications be
published as a Proposed Standard.
o OSI NSAPs and IPv6 be published as an Experimental Protocol.
o Form-based File Upload in HTML be published as an
Experimental Protocol.
o Mapping between full RFC 822 and RFC 822 with restricted
encoding be reclassified as an Historic document.
o The Multipart/Report Content Type for the Reporting of Mail
System Administrative Messages be published as a Proposed
Standard.
o Enhanced Mail System Status Codes be published as a Proposed
Standard.
o An Extensible Message Format for Delivery Status
Notifications be published as a Proposed Standard.
4. The IESG issued 25 Last Calls to the IETF during the month of
October, 1995:
o Address Allocation for Private Internets
<draft-ietf-cidrd-private-addr-04> for consideration as a
Best Current Practices RFC.
o Conformance Statements for Version 2 of the Simple Network
Management Protocol (SNMPv2) <draft-ietf-snmpv2-conf-ds-05>
for consideration as a Draft Standard.
o Introduction to Version 2 of the Internet-standard Network
Cooper [Page 4]
Internet Monthly Report October 1995
Management Framework <draft-ietf-snmpv2-intro-ds-06> for
consideration as a Draft Standard.
o Party MIB for version 2 of the Simple Network Management
Protocol (SNMPv2) <RFC1447> for consideration as an Historic
document.
o Security Protocols for version 2 of the Simple Network
Management Protocol (SNMPv2) <RFC1446> for consideration as
an Historic document.
o IPv6 Address Allocation Management
<draft-iab-iesg-ipv6-address-alloc-00> for consideration as
a Best Current Practices RFC.
o SMTP Service Extension for 8bit-MIMEtransport
<draft-ietf-smtpext-8bitmime-04> for consideration as an
Internet Standard.
o Administrative Model for version 2 of the Simple Network
Management Protocol (SNMPv2) <RFC1445> for reclassification
as an Historic document.
o SMTP Service Extension for Message Size Declaration
<draft-ietf-smtpext-size-02> for consideration as an Internet
Standard.
o Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework
<draft-ietf-snmpv2-coex-ds-03> for consideration as a Draft
Standard.
o OSI NSAPs and IPv6 <draft-ietf-ipngwg-nsap-ipv6-00> for
consideration as an Experimental Protocol.
o IPv6 Testing Address Allocation
<draft-ietf-ipngwg-test-addr-alloc-00> for consideration as
an Experimental Protocol.
o Form-based File Upload in HTML
<draft-ietf-html-fileupload-03> for consideration as an
Experimental Protocol.
o SMTP Service Extensions <draft-ietf-smtpext-extensions-05>
for consideration as an Internet Standard.
o Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2)
Cooper [Page 5]
Internet Monthly Report October 1995
<draft-ietf-snmpv2-mib-ds-05> for consideration as a Draft
Standard.
o Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2) <draft-ietf-snmpv2-proto-ds-05>
for consideration as a Draft Standard.
o Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2) <draft-ietf-snmpv2-tm-ds-04>
for consideration as a Draft Standard.
o Post Office Protocol - Version 3 <draft-myers-pop-pop3-06>
for consideration as an Internet Standard.
o Manager to Manager Management Information Base <RFC1451> for
reclassification as an Historic document.
o An IPv6 Provider-Based Unicast Address Format
<draft-ietf-ipngwg-unicast-addr-fmt-02> for consideration as
a Proposed Standard.
o An Appeal to the Internet Community to Return Unused IP
Networks(Prefixes) to the IANA <draft-ietf-cidrd-appeal-03>
for consideration as a Best Current Practices RFC.
o Mapping between full RFC 822 and RFC 822 with restricted
encoding <RFC1137> for reclassifying as an Historic document.
o Renumbering Needs Work <draft-iab-renum-02> for consideration
as a Best Current Practices RFC.
o Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-smi-ds-04> for consideration as a Draft
Standard.
o Textual Conventions for Version 2 of the Simple Network
Management Protocol (SNMPv2) <draft-ietf-snmpv2-tc-ds-06>
for consideration as a Draft Standard.
5. Three working Groups were created during this period:
Guide for Internet Standards Writers (stdguide)
Common Indexing Protocol (find)
Public-Key Infrastructure (X.509) (pkix)
and two working groups were concluded:
Cooper [Page 6]
Internet Monthly Report October 1995
Generic Internet Service Description (gisd)
Responsible Use of the Network (run)
6. A total of 80 Internet-Draft actions were taken during the month
of October, 1995:
(Revised draft (o), New Draft (+) )
(wnils) o Architecture of the Whois++ Index Service
<draft-ietf-wnils-whois-06.txt>
(iplpdn) o Management Information Base for Frame Relay DTEs
<draft-ietf-iplpdn-frmib-dte-05.txt>
(svrloc) o Service Location Protocol
<draft-ietf-svrloc-protocol-07.txt>
(pppext) o PPP BSD Compression Protocol
<draft-ietf-pppext-bsd-compress-05.txt>
(ipatm) o IP over ATM: A Framework Document
<draft-ietf-ipatm-framework-doc-06.txt, .ps>
(dnssec) o Domain Name System Security Extensions
<draft-ietf-dnssec-secext-06.txt>
(snanau) o Definitions of Managed Objects for APPC
<draft-ietf-snanau-appcmib-04.txt>
(wnils) o How to interact with a Whois++ mesh
<draft-ietf-wnils-whois-mesh-03.txt>
(ipatm) o Support for Multicast over UNI 3.1 based ATM
Networks. <draft-ietf-ipatm-ipmc-08.txt>
(aft) o SOCKS Protocol Version 5
<draft-ietf-aft-socks-protocol-v5-05.txt>
(snmpv2) o Introduction to Version 2 of the Internet-standard
Network Management Framework
<draft-ietf-snmpv2-intro-ds-06.txt>
(snmpv2) o Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-tc-ds-06.txt>
(snmpv2) o Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-smi-ds-04.txt>
(snmpv2) o Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-proto-ds-05.txt>
(snmpv2) o Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-tm-ds-04.txt>
(snmpv2) o Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-conf-ds-05.txt>
(snmpv2) o Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework
Cooper [Page 7]
Internet Monthly Report October 1995
<draft-ietf-snmpv2-coex-ds-03.txt>
(snmpv2) o Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)
<draft-ietf-snmpv2-mib-ds-05.txt>
(asid) o Definition of X.500 Attribute Types and an Object
Class to Hold Uniform Resource Identifiers (URIs)
<draft-ietf-asid-x500-url-02.txt>
(ripv2) o RIP-II Cryptographic Authentication
<draft-ietf-ripv2-md5-02.txt>
(bmwg) o Benchmarking Methodology for Network Interconnect
Devices <draft-ietf-bmwg-methodology-02.txt>
(dhc) o Dynamic Host Configuration Protocol
<draft-ietf-dhc-dhcp-04.txt>
(cat) o Generic Security Service Application Program
Interface, Version 2 <draft-ietf-cat-gssv2-04.txt>
(none) o ARP Extension - UNARP <draft-malkin-unarp-01.txt>
(none) + Routing Aspects Of IPv6 Transition
<draft-ietf-ngtrans-routing-aspects-00.txt>
(uri) o Uniform Resource Locators for Z39.50
<draft-ietf-uri-url-irp-03.txt>
(dnsind) o DNS NOTIFY: a mechanism for prompt notification of
zone changes <draft-ietf-dnsind-notify-04.txt>
(none) o PGP Message Exchange Formats
<draft-atkins-pgpformat-01.txt>
(mimesgml) o The MIME Multipart/Related Content-type
<draft-ietf-mimesgml-related-03.txt>
(none) o Content-ID and Message-ID Uniform Resource Locators
<draft-levinson-cid-01.txt>
(addrconf) o IPv6 Stateless Address Autoconfiguration
<draft-ietf-addrconf-ipv6-auto-04.txt>
(pppext) + The PPP Internet Protocol Control Protocol (IPCP)
<draft-ietf-pppext-ipcp-network-00.txt>
(dnsind) o Dynamic Updates in the Domain Name System (DNS)
<draft-ietf-dnsind-dynDNS-04.txt>
(ipsec) o The Photuris Session Key Management Protocol
<draft-ietf-ipsec-photuris-06.txt>
(http) o Hypertext Transfer Protocol -- HTTP/1.0
<draft-ietf-http-v10-spec-04.txt, .ps>
(none) o The IPv6 Payload Header
<draft-kre-ipv6-payload-01.txt>
(sdr) o Source Demand Routing: Packet Format and Forwarding
Specification (Version 1).
<draft-ietf-sdr-packet-spec-01.txt>
(none) o A DNS RR for specifying the location of services
<draft-gulbrandsen-dns-rr-srvcs-01.txt>
(rmonmib) o Remote Network Monitoring Management Information
Base <draft-ietf-rmonmib-rmon2-02.txt>
(cidrd) o Implications of Various Address Allocation Policies
Cooper [Page 8]
Internet Monthly Report October 1995
for Internet Routing
<draft-ietf-cidrd-addr-ownership-03.txt>
(none) o Post Office Protocol - Version 3
<draft-myers-pop-pop3-06.txt>
(cidrd) o An Appeal to the Internet Community to Return Unused
IP Networks (Prefixes) to the IANA
<draft-ietf-cidrd-appeal-03.txt>
(mimesgml) o Encapsulating SGML Documents Using the
Multipart/Related Content-Type
<draft-ietf-mimesgml-encap-02.txt>
(none) o A One-Time Password System <draft-haller-otp-04.txt>
(isdnmib) o ISDN Management Information Base
<draft-ietf-isdnmib-snmp-isdn-mib-01.txt>
(vgmib) o Definitions of Managed Objects for IEEE 802.12
Interfaces <draft-ietf-vgmib-interfaces-mib-03.txt>
(none) o Guidelines for IETF Meeting Sites
<draft-prior-future-host-guidelines-01.txt>
(mobileip) o IP Encapsulation within IP
<draft-ietf-mobileip-ip4inip4-01.txt>
(none) o CyberCash Credit Card Protocol Version 0.8
<draft-eastlake-cybercash-v08-01.txt>
(cidrd) o Address Allocation for Private Internets
<draft-ietf-cidrd-private-addr-04.txt>
(html) o HTML Tables <draft-ietf-html-tables-03.txt>
(none) o Addendum to RFC 1602 -- Variance Procedure
<draft-postel-variance-01.txt>
(ipngwg) o A Method for the Transmission of IPv6 Packets over
Ethernet Networks
<draft-ietf-ipngwg-ethernet-ntwrks-01.txt>
(iab) o Renumbering Needs Work <draft-iab-renum-02.txt>
(poised95) o The Internet Standards Process -- Revision 3
<draft-ietf-poised95-std-proc-3-01.txt>
(poised95) o IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall
Committees <draft-ietf-poised95-nomcom-01.txt>
(none) o MIME Security with Pretty Good Privacy (PGP)
<draft-elkins-pem-pgp-01.txt>
(ipsec) o Simple Key-Management For Internet Protocols (SKIP)
<draft-ietf-ipsec-skip-03.txt>
(none) o The Content-MD5 Header Field
<draft-myers-mime-md5-01.txt>
(none) + Provider Independent vs Provider Aggregatable
Address Space
<draft-rfced-info-pi-vs-pa-addrspac-00.txt>
(none) + An Alternative way of Providing Internet Addressing
and Access <draft-rfced-info-in-address-00.txt>
(none) + Multicast Address Allocation
<draft-rfced-exp-multicast-addr-00.txt>
Cooper [Page 9]
Internet Monthly Report October 1995
(receipt) + An Extensible Message Format for Message Disposition
Notifications <draft-ietf-receipt-mdn-00.txt>
(none) o The SMTP MULT extension command
<draft-myers-smtp-mult-01.txt>
(isdnmib) + Dial Control Management Information Base
<draft-ietf-isdnmib-dial-control-00.txt>
(iab) + Report of the IAB Workshop on Internet Information
Infrastructure, October 12-14, 1994
<draft-iab-iii-report-00.txt>
(none) + PGP MIME Integration <draft-kazu-pgp-mime-00.txt>
(dlswmib) o Definitions of Managed Objects for Data Link
Switching using SNMPv2
<draft-ietf-dlswmib-mib-07.txt>
(none) + Universal Payment Protocol
<draft-eastlake-universal-payment-00.txt>
(rip) + Protocol Analysis for Triggered RIP
<draft-ietf-rip-trigger-analysis-00.txt>
(mimesgml) + SGML Media Types <draft-ietf-mimesgml-types-00.txt>
(none) + Binary to 8bit encoding for RFC 1652-compliant MIME
transfer <draft-hicklin-binary-encoding-00.txt>
(ids) + Introducing a Directory Service
<draft-ietf-ids-x500-intro-dir-00.txt>
(none) + MIME Header Supplemented File Type
<draft-nicol-mime-header-type-00.txt>
(iab) + Architectural Principles of the Internet
<draft-iab-principles-00.txt>
(none) + The Model Primary Content Type for Multipurpose
Internet Mail Extensions
<draft-nelson-model-mail-ext-00.txt>
(idr) o Operational Experience with the BGP-4 protocol
<draft-ietf-idr-bgp4-op-experience-01.txt>
(idr) o BGP-4 Requirement Satisfaction Report
<draft-ietf-idr-bgp4-stdreport1-01.txt>
(trunkmib) + Definitions of Managed Objects for the DS1 and E1
Interface Type <draft-ietf-trunkmib-ds1-mib-00.txt>
(trunkmib) + Definitions of Managed Objects for the DS3/E3
Interface Type <draft-ietf-trunkmib-ds3-mib-00.txt>
7. There were 17 RFC's published during the month of October, 1995:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1845 E (mailext) SMTP Service Extension for
Checkpoint/Restart
RFC1846 E (mailext) SMTP 521 reply code
RFC1847 PS (pem) Security Multiparts for MIME:
Multipart/Signed and Multipart/Encrypted
Cooper [Page 10]
Internet Monthly Report October 1995
RFC1848 PS (pem) MIME Object Security Services
RFC1851 E (none) The ESP Triple DES-CBC Transform
RFC1852 E (none) IP Authentication using Keyed SHA
RFC1853 I (mobileip) IP in IP Tunneling
RFC1854 PS (mailext) SMTP Service Extension for Command
Pipelining
RFC1855 I (run) Netiquette Guidelines
RFC1856 I (opstat) The Opstat Client-Server Model for
Statistics Retrieval
RFC1857 I (opstat) A Model for Common Operational Statistics
RFC1858 I (none) Security Considerations for IP Fragment
Filtering
RFC1859 I (none) ISO Transport Class 2 Non-use of Explicit
Flow Control over TCP RFC1006 extension
RFC1860 I (none) Variable Length Subnet Table For IPv4
RFC1861 I (none) Simple Network Paging Protocol - Version
3 - Two-Way Enhanced
RFC1863 E (idr) A BGP/IDRP Route Server alternative to
a full mesh routing
RFC1864 DS (822ext) The Content-MD5 Header Field
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya <scoya at cnri.reston.va.us>
Cooper [Page 11]
Internet Monthly Report October 1995
INTERNET PROJECTS
-----------------
FEDERAL NETWORKING COUNCIL (FNC)
-------------------------------
Unanimous passage of a resolution by the Federal Networking Council
(FNC) on 10/24/95 supporting the following definition of
"Internet".
RESOLUTION:
"The Federal Networking Council (FNC) agrees that the following
language reflects our definition of the term "Internet".
"Internet" refers to the global information system that --
(i) is logically linked together by a globally unique address
space based on the Internet Protocol (IP) or its subsequent
extensions/follow-ons;
(ii) is able to support communications using the Transmission
Control Protocol/Internet Protocol (TCP/IP) suite or its
subsequent extensions/follow-ons, and/or other IP-compatible
protocols; and
(iii) provides, uses or makes accessible, either publicly or
privately, high level services layered on the communications
and related infrastructure described herein."
This definition was developed in consultation with the leadership
of the Internet and Intellectual Property Rights (IPR) Communities.
The FNC expects that the definition may be included in legislation
which is currently before the Congress.
The second item is the Workshop Announcement / Call for Papers
related to Improving Internet Security. This workshop is an
outgrowth of the Federal Networking Council Security Working
Group's efforts related to the Federal Internet Security Plan
(FISP).
Tracie Monk
DynCorp / FNC Coordination Office
TMONK at ITO.SNAP.ORG
http://www.fnc.gov
(703)522-6410
(703)522-7161 fax
Cooper [Page 12]
Internet Monthly Report October 1995
FEDERAL INTERNET SECURITY WORKSHOP
==================================
Federal Internet Security Workshop
Call for Position Papers
An Invitational Workshop on Improving Internet Security
Date: February 20-21, 1996
San Diego, CA
In September 1995, the Federal Networking Council Security Working
Group (FNC/SWG) published the draft Federal Internet Security Plan
(FISP). The framework presented in this Plan focusses on the
Internet in its broadest sense, with the U.S. Government presented
as a major user. It addresses Internet security requirements,
including interoperability, from the perspective of the goals and
objectives outlined in the National Performance Review (NPR),
http://www.npr.gov/.
The FISP is available at the following URL:
http://www.fnc.gov/SWG.html .
The framework presented in the FISP is targetted toward improving
the security of Federal Internet operations and raising the state
of practice of Internet security by the Federal and other sectors
through a collaborative effort. It recognizes the influential role
that the Government plays as a major sponsor of
communications/computing R&D and as a purchaser of mature products.
The approach is also intended
to highlight the critical interface between Federal and commercial
users / developers of Internet services and technologies. This
approach has been developed in consultation with members of the
Federal Networking Council Advisory Committee (FNCAC), a group with
representation from industry, academia, and the non-profit sectors.
Objectives:
This workshop will bring together principal players in the Federal
and overall Internet community to discuss the problems and
challenges of security on the Internet. It will also form the
foundation for industry and government strategies for implementing
specific FISP recommendations during 1996 / 1997.
The workshop will have as its objectives...
* Revise and extend the Federal Internet Security Plan (FISP)
Cooper [Page 13]
Internet Monthly Report October 1995
* Describe "best practice" examples related to Internet security.
* Develop specific strategies for implementing FISP action items,
involving various sectors of the Internet community.
* Identify the fundamental issues, requirements, and recommendations
related to future Internet Security research and development efforts.
Participants:
Participation in the workshop will be by invitation, primarily
based on submitted position papers which will be reviewed by the
steering and program committees. Additional individuals may be
invited to ensure that participation reflects a broad cross-section
of key players in the Internet community. The material submitted
will be a part of the record of the workshop.
Although a principal focus of the workshop will be on the FISP, the
Federal Networking Council recognizes that there is no easily
partitionable "Federal" part of the Internet and that the entire
global community must be part of any solutions to its security
problems. Therefore, the FISP and the workshop are oriented toward
a scalable continuing improvement process, based on common
principles and mechanisms compatible with the values of the
community and their needs.
Schedule:
Call for participation - November 6, 1995
Position Papers Due - December 8, 1995
Invitations to Participants - January 8, 1996
Workshop - February 21-22, 1996
Forum Sponsors / Organizer:
Member agencies of the Federal Networking Council's Security
Working Group / Massachusetts Institute of Technology
Steering Committee:
Stephen Squires, Advanced Research Projects Agency
(FNC/SWG Co-Chair)
Dennis Steinauer, National Institute of Standards and Technology
(FNC/SWG Co-Chair)
Tice DeYoung, National Aeronautics and Space Administration
Phillip Dykstra, Army Research Laboratory
Mike Green, National Security Agency
George Seweryniak, Department of Energy
Walter Wiebe, Federal Networking Council
Cooper [Page 14]
Internet Monthly Report October 1995
Program Committee:
Jeffrey Schiller - Massachusetts Institute of Technology (MIT)
Steve Walker - Trusted Information Systems (TIS)
Bob Aiken - DOE/Lawrence Livermore National Labs(DOE)
Rich Pethia - Computer Emergency Response Team (CERT)
Logistics Chair:
Richard Solomon, Associate Director, MIT Research Program on
Communications Policy
White papers of no more than 10 pages should be submitted
electronically to: execdir at fnc.gov
FISP Action Items to be addressed during the Workshop:
Internet Security Policy and Policy Support Activities
* Establish overall Internet security policies
* Address security in all Federally supported NII pilots
* Coordinate Internet community involvement
* Establish an ongoing Internet threat database and
assessment capability
* Identify legal and law enforcement issues
Internet Security and Technology Development
* Develop an Internet security maturity model
* Develop Internet security architecture
* Enhance Internet security services and protocols
* Develop a "Secure-Out-of-the-Box" endorsement
* Enhance application security
Internet Security Infrastructure
* Establish a set of Internet security interoperability testbeds
* Support authentication, certificate, and security
services pilots
* Establish Internet security testing and evaluation
capabilities
* Improve security incident handling capabilities
* Develop security self-assessment capabilities
* Establish effective patch distribution mechanisms
Education and Awareness
* Compile Internet user and site profiles
Cooper [Page 15]
Internet Monthly Report October 1995
* Encourage use of available security technologies
* Establish an Internet security information server
* Establish an Internet security symposium/workshop series
* Establish an Internet security fellowship program
Tracie Monk
DynCorp / FNC Coordination Office
TMONK at ITO.SNAP.ORG
INTERNIC
--------
REGISTRATION SERVICES
I. Significant Events
InterNIC Registration Services assigned over 9,843 network
addresses and registered over 20,315 domains. There were three
top-level country domains registered during October: Mauritius
(MU), Brunei (BN), and Ethiopia (ET).
As of October 13, 1995 the InterNIC Registry announced the
availability of the domain registration forms under the web for
both new submissions as well as modifications to existing domains.
The url is http://rs.internic.net/reg/reg-forms.html
Revision 1 to the Domain Name Dispute Policy is available for
review by the internet community. The policy (Revision 01) will be
effective November 23, 1995.
During the month of October, domain requests continue to average
between 1,000 - 1,400 for new submissions per day. Adjustments
continue to be made in domain programs/processing. At the close of
October 1995, the domain backlog had decreased from 7,000+ to
1,000+ new domain registration requests.
II. Current Status
During the month of October 1995, InterNIC Registration Services
received communications as shown below. The majority of the
correspondence concerned the assignment and re-assignment of
network numbers and the registration or change of domain names:
E-mail 47,925 (hostmaster at internic.net)
Postal/Fax 251 (primarily IP number requests)
Phone 16,180
Cooper [Page 16]
Internet Monthly Report October 1995
The Registrations Services host computer supported a large volume
of information retrieval requests during the month of October:
Connections Retrievals
Gopher 48,534 79,089
WAIS 97,704 74,276
FTP 54,556 154,542
Mailserv 3,978
Telnet 85,426
Http 715,930
In addition, for WHOIS the number of queries were:
Client Server
505,651 3,387,819
Debbie Fuller <Debbief at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
The NIC Locator database, hosted by InterNIC Directory and
Database Services, provides the Internet community a place to look
up information about Network Information Centers attached to the
Internet. NIC Locator was built by the IETF Network Information
Services Infrastructure working group to provide a place on the
Internet for NICs to advertise their services.
If you'd like to view the NIC Locator database, take a look at
http://ds.internic.net/ds/niclocate.html
If you'd like advertise a NIC, or know of a NIC that should be
advertised, contact the NIC Liaison at InterNIC Registration
Services (liaison at internic.net).
In October, InterNIC Directory and Database Services upgraded its
Web to X.500 gateways
http://www.internic.net/ds/x500.html
to support two X.500 attributes as hyperlinks: the new "Labeled
URI" attribute and the RFC822 e-mail address attribute. The
former attribute is now being accepted by the InterNIC in entries
it maintains for organizations and persons. An organization can
now be looked up via the Web to X.500 gateway with a Web browser
and the labeled URI attribute-hyperlink followed to its Web home
page. Similarly, a person can be looked up with the Web browser
Cooper [Page 17]
Internet Monthly Report October 1995
and, assuming the browser supports the "mailto" URL scheme, be
sent e-mail directly from the browser simply by clicking on the
"mail" attribute.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter
information about your resource in our WWW suggestion form. The
form can be reached through our Directory of Directories Web page
at:
http://ds.internic.net:80/ds/dsdirofdirs.html
by Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
The US Domain Registry has installed a client/server Rwhois protocol
to support the US Domain WHOIS information. We register third level
delegations. For example, K12.IL.US, TACOMA.WA.US, or STATE.MN.US
would have entries in the US WHOIS database. To look up a US domain
name, do the following:
whois -h nii.isi.edu <domain-name>
We request all third level subdomain administrators of the US Domain
to operate a RWHOIS server for those subdomains under them.
See http://www.isi.edu/us-domain/RWhois Sources and Information for
more information.
For further information about the US Domain, send a message to:
US-DOMAIN at ISI.EDU, or browse our WEB page:
http://www.isi.edu/us-domain
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 1100
PHONE 600
----------------------------
Total Contacts 1700
Cooper [Page 18]
Internet Monthly Report October 1995
DELEGATIONS 36
FORWARDED DELEGATIONS: 1024
OTHER US DOMAIN MSGS: 640
---------------------------
Total 1700
OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or
to/from the InterNic, phone calls, modifications, application
requests, discussion and clarification of the requests, questions
about names, resolving technical problems with zone files and name
servers, and whois listings.
To obtain a copy of the list of other delegated localities and
"us-domain-delegated.txt" below.
URL: http://www.isi.edu/us-domain
URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
49 34 32 47 35 23 21 8 1
===================================================================
THIRD LEVEL DELEGATIONS
=======================
MUS.CA.US California, museums
LIB.NJ.US New Jersey, libraries
LOCALITIES
==========
ANDERSON.IN.US JEFFERSON-CITY.MO.US
MEXICO.MO.US COOS.OR.US
COLUMBIA.MO.US FULTON.MO.US
TRILAKES.NY.US SAN-RAMON.CA.US
BOUNTIFUL.UT.US AMHERST.NY.US
SALEM.IN.US BANKS.OR.US
LUVERNE.MN.US WINDOM.MN.US
REDWOOD.MN.US LITCHFIELD.IL.US
MUNSTER.IN.US CLIVE.IA.US
ANKENY.IA.US URBANDALE.IA.US
Cooper [Page 19]
Internet Monthly Report October 1995
DES-MOINES.IA.US HILLSDALE.NJ.US
WEST-DES-MOINES.IA.US JOHNSTON.IA.US
MASON.TX.US GROVE-CITY.OH.US
MONTGOMERY.OH.US WORTHINGTON.MN.US
FAIRMONT.MN.US MARSHALL.MN.US
AUSTIN.MN.US ALBERT-LEA.MN.US
PIPESTONE.MN.US DELMAR.CA.US
OTHER US DOMAIN DELEGATIONS THIS MONTH
--------------------------------------
CO.BEAVER.PA.US DARIEN.K12.CT.US
RMPL.LIB.CA.US CI.DES-MOINES.WA.US
ENCINA.DST.CA.US CI.POWAY.CA.US
MOBILESO.CO.MOBILE.AL.US SUMMITMRDD.CO.SUMMIT.OH.US
TUNXIS.CC.CT.US CASADY.PVT.K12.OK.US
NORMAN.K12.OK.US HAGLEY.LIB.DE.US
ORC.OAK-RIDGE.TN.US FRIENDS.WILMINGTON.DE.US
LAKE.CO.LAKE.CA.US CI.LYNWOOD.CA.US
CI.DE-KALB.IL.US TOWNHALL-WESTWOOD.MA.US
CO.GRAND.UT.US CI.OREM.UT.US
CHAMBER.AUBURN.MA.US CHAMBER.WESTBOROUGH-NORTHBOROUGH.MA.US
KOPTI.ARLINGTON.VA.US FURBALL.BRIGHTON.MA.US
WWW.BLACK-MOUNTAIN.NC.US FESTIVAL.BLACK-MOUNTAIN.NC.US
TAC.BOSTON.MA.US CSCL.K12.DANVERS.MA.US
MALIBU.CONCORD.CA.US CI.OCEANSIDE.CA.US
CI.WEST-VALLEY.UT.US CO.ST-LUCIE.FL.US
RSUC.GEN.MA.US UNDERSCORE.AUBURN-HILLS.MI.US
CI.KENNEBUNK.ME.US CI.BILOXI.MS.US
CI.MEMPHIS.TN.US KENT.PVT.K12.CT.US
CRC.PARAGOULD.AR.US OERM.MUS.CA.US
FERRET.LAF.IN.US CO.JEFFERSON.WA.US
CO.ISLAND.WA.US CO.GRAYS-HARBOR.WA.US
CO.GRANT.WA.US CO.GARFIELD.WA.US
CO.FRANKLIN.WA.US CO.FERRY.WA.US
CO.DOUGLAS.WA.US CO.COWLITZ.WA.US
CO.COLUMBIA.WA.US CO.CLARK.WA.US
CO.CLALLAM.WA.US CO.CHELLAN.WA.US
CO.KITSAP.WA.US CO.KING.WA.US
CO.KITTITAS.WA.US CO.KLICKITAT.WA.US
CO.LEWIS.WA.US CO.LINCOLN.WA.US
CO.MASON.WA.US CO.OKANOGAN.WA.US
CO.PACIFIC.WA.US CO.PEND-OREILLE.WA.US
CO.SAN-JUAN.WA.US CO.SKAGIT.WA.US
CO.SKAMAINA.WA.US CO.SNOHOMISH.WA.US
CO.STEVENS.WA.US CO.THURSTON.WA.US
CO.WAHKIAKUM.WA.US CO.WALLA-WALLA.WA.US
Cooper [Page 20]
Internet Monthly Report October 1995
CO.WHATCOM.WA.US CO.WHITMAN.WA.US
CO.ADAMS.WA.US CO.BENTON.WA.US
CO.ASTON.WA.US EWS.PUT.K12.CT.US
CO.FREDERICK.MD.US RCMH.CO.RANDOLPH.NC.US
MRCSB.COG.VA.US CEICMHB.COG.MI.US
AAF.WASHINGTON.DC.US CTS.RICHMOND.VA.US
CI.SANTA-MARIA.CA.US WARRENTECH.TEC.NJ.US
SAGE.ROLLA.MO.US FWDHS.COG.MI.US
MIDGLAD.COG.MI.US DCHTH.CO.DOUGLAS.OR.US
BSCC.CC.AL.US BKP.CAMBRIDGE.MA.US
CHAMBER.BLACKSTONE.MA.US
Ann Cooper (Cooper at ISI.EDU)
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes recent activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service
and other projects.
Performance statistics for the Route Servers (RS) at
interconnection points are now online on the RA Web pages:
http://www.ra.net/routing.arbiter/RA/statistics/.rs.html
The following graphical and text-based reports are available:
> DELAY/PACKET LOSS - Packet loss and round-trip delay in milli-
seconds for five ping packets sent from each Route Server to
its peer routers. The data is recorded at 15-minute intervals,
processed, analyzed, and presented in a graphical format.
Packet latency across the interconnection point media is
categorized into four exclusive categories (0-10 ms, 10-100 ms,
100-1000 ms, and >1000ms) and presented graphically over time.
> BGP PEERING - Number of BGP updates received from each peer,
recorded at 15-minute intervals. In a very rough sense, the
routing stability of the global Internet can be measured by
the number and frequency of BGP messages.
> SYSTEM UPTIME - Percentage and length of time in minutes of
Route Server uptime, number of system failures, and maximum
downtime. (Text only.)
Cooper [Page 21]
Internet Monthly Report October 1995
> FREE VIRTUAL MEMORY - Samples of free virtual memory taken at
five minute intervals to monitor Route Server memory management.
The Route Server maintains multiple images of its routing tables
to support policy-based routing with a potentially large number of
peers. RS memory usage is thus a critical issue, given the size
and growth rate of the Internet.
The reports for delay/packet loss, BGP peering, and virtual memory
are currently only available for Route Server/ANS peering at the
Washington, D.C. NAP (MAE-East.) Merit has collected many months
of data from all the interconnection points, and soon expects to
report additional performance statistics for the AADS, PacBell, and
Sprint NAPs and MAE- West. The statistics are processed and
analyzed by Dun Liu of Merit.
Two new Routing Arbiter Database (RADB) reports provide valuable
information about routes registered in the RADB and the status of
CIDR aggregation in the Internet Routing Registry. The new reports
are:
> COUNTS OF RADB PREFIXES BY LENGTH - The number of Route objects
registered in the RADB, with active and withdrawn routes listed
by prefix length. Data from the current week is available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/
counts-by-prefix/Summarize_prefix.current
Reports from previous weeks are available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/
counts-by-prefix/summarize_prefix.yymmdd
> IRR ROUTES SUMMARIZED BY PREFIX LENGTH WITH AGGREGATION - A
summary of unique prefixes registered in the IRR. Routes are
summarized by the first octet of the network number. If routes
within a prefix can be aggregated, a count is printed for each
prefix length that has a different count after aggregation. Data
from the current week is available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/
IRR_profile/IRR_Profile.current
Reports from previous weeks are available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/
IRR_profile/IRR_Profile.yymmdd
Cooper [Page 22]
Internet Monthly Report October 1995
Brian Renaud presented a Routing Arbiter status report at the
22nd RIPE meeting in Amsterdam. A copy of his presentation is
available from:
ftp://ftp.ra.net/routing.arbiter/radb/presentations/
RIPE-22_renaud_routing.ps
The RIPE attendees expressed significant interest in the RA's
implementation of PGP-based authentication for the RADB.
Instructions for using PGP with the RADB are available from:
http://www.ra.net/routing.arbiter/RA/bgp.html
Craig Labovitz attended the Very High Speed Networking Conference
sponsored by the University of Maryland. A focus of discussion at
the meeting was the use of ATM technology in next-generation
networks. Elise Gerich attended meetings of the Federal
Engineering Planning Group and Federal Networking Council Advisory
Committee (FNCAC) in Washington, D.C. At the FNCAC, she discussed
ways in which the Routing Arbiter service can help plan and
facilitate federal R&E network connectivity in the post-NSFNET era.
Susan R. Harris (srh at merit.edu)
UCL
----
Crowcroft attended an ACM SIG Chairs meeting, and some planning of
SIGCOMM 96 (stanford) and SIGCOMM 97 (Cannes/Nice area of south of
france) was done.
Since leading edge Internet Research generally appears first in
SIGCOMM or in the SIGs newsletter, CCR, we think it is of general
interest to readers of this report.
The SIG's WWW page is at: http://www.ohiou.edu/~gwetzel/sigcomm/
and links to back issues of CCR can be found there as well as our
SIG's standards tracking reports.
Comments are always welcome.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 23]
Internet Monthly Report October 1995
CALENDAR
--------
Last update 11/06/95
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at cnri.reston.va.us>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - New Dates for ULPAA in 1995, was Dec. 4-8, 1995
NOW Dec. 11-15, 1995
- The 4th Int'l Conf. on Telecom Systems, Modelling and Analysis
originally scheduled for March 14-17, 1996 has been moved to
March 21-24, 1996. Nashville, TN.
A copy of this calendar is available as follows:
VIA FTP
-------
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
Africa Address: ftp.is.co.za (196.4.160.8)
cd ietf
ls *0mtg*
Gopher
-------
Available on the Gopher Server running on IETF.CNRI.RESTON.VA.US
(132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF
Meetings / Scheduling Calendar".
WWW
-------
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link for
Cooper [Page 24]
Internet Monthly Report October 1995
"meetings" and you should find an entry "listing of other Internet
related events".
************************************************************************
1995
---------
Nov. 4-9 ACM Multimedia '95 San Francisco, CA
(http://acm.org/MM95/)
Nov. 6-9 IEEE 802 Plenary (Firm) Montreal, Quebec
Nov. 6-10 ANSI X3T10 '95 Western Digital Palm Springs, CA
Nov. 7-9 OPENNET '95 Goettingen, Germany
Nov. 7-10 ICNP '95 Tokyo, Japan
Nov. 8 Membermtg/GIGI e.V.
German Internet User Group Goettingen, Germany
Nov. 13-17 GLOBECOM '95 Singapore
Nov. 13-17 OMG TC Makuhari, Chiba, Japan
Nov. 14-16 NORDUnet'95 Conf. Copenhagen, Denmark
(http://info.denet.dk/nordunet/ndn95.html)
Nov. 27-29 European IT Conf. (IETC'95) Brussels, Belgium
Nov. 27-Dec. 1 Email World (Definite) Boston, MA
Nov. 27-Dec. 1 Windows Solutions Germany Frankfurt, Germany
Nov. 29-Dec. 1 Virtual Reality World Boston, MA
Dec. 3-6 ACM SIGOPS
Dec. 4-8 OIW (Firm)
Dec. 4-8 34th IETF (Firm) Dallas, TX
Dec. 4-8 ANSI X3T11 (Firm) San Diego, CA
Dec. 4-8 Supercomputing '95 (Firm) San Diego, CA
Dec. 4-8 Windows Solutions Tokyo Tokyo, Japan
Dec. 4-8 X/Open Security
Dec. 10-15 ATM Forum London, UK
Dec. 11-12 2nd Intntl. Wkshp on High Perf.
Protocol Arch. HIPPARCH'95 Sydney, AU
Dec. 11-14 4th Int'l WWW Conference Boston, MA
Dec. 11-15 11th Comp. Sec. Applications New Orleans, LO
Dec. 11-15 IFIP Upper Layer Protocols
Arch. & Appl. (ULPAA) Sydney, AU
(http://www.ee.uts.edu.au/ifip/ULPAA95.html)
1996
-----------
Jan. 8-12 ANSI X3T10 '96 Quantum Dallas, TX
Jan. 8-12 OMG TC San Diego, CA
Jan. 9-12 Internet World Canada Toronto, Ont, Canada
Jan. 22-26 USENIX 1996 Tech. Conference San Diego, CA
Jan. 23-25 IEEE 802.10 Interim Meeting Salt Lake City, UT
Cooper [Page 25]
Internet Monthly Report October 1995
Jan. 29-31 Multimedia Computing & Netwkg San Jose, CA
Feb. 2-4 Internet World Home Expo New York
Feb. 5-7 Wkshp on Network Security,
Firewalls & Internet Svs. San Jose, CA
Feb. 5-9 ANSI X3T11 San Diego, CA
Feb. 5-9 ATM Forum Los Angeles, CA
Feb. 13-15 Virtual Reality World Europe Stuttgart, Germany
Feb. 14-15 Web Seminars Chicago, IL
Feb. 19-21 EMail World & Internet Expo San Jose, CA
Feb. 19-23 Intntl Zurich Sem. on Digital
Communications Zurich, Switzerland
Feb. 20-Mar. 1 Connectathon '96 San Jose, CA
Feb. 22-23 Internet Society Symp on Ntwk
& Distributed System Security San Diego, CA
Feb. 27-Mar. 1 ICDP '96-IFIP/IEEE Intntl Conf.
on Distributed Platforms Dresden, Germany
Mar. 4-8 35th IETF - CONFIRMED Los Angeles, CA
Mar. 4-8 OMG TC Brisbane, Austalia
Mar. 7-9 Internet World Asia Kuala Lumpur, Malaysia
Mar. 11-13 Wkshp on Network Security
Firewalls & Internet Svs. New York, NY
Mar. 11-14 UniForum San Francisco, CA
Mar. 11-15 ANSI X3T10 '96 QLogic San Diego, CA
Mar. 11-15 IEEE 802 '96 Hyatt Regency La Jolla, CA
Mar. 18-22 OIW (Firm)
Mar. 21-24 4th Intntl Conf. on Telecom Syst.
Modeling & Analysis Nashville, TN
Apr. 1-4 Internet World Brazil Rio de Janiero, Brazil
Apr. 1-5 NetWorld+Interop Las Vegas, NV
Apr. 9-13 ANSI X3T11 (Firm) Palm Springs, CA
Apr. 11-12 2nd ACM/SIGRAPH Conf. on
Assistive Tech. ASSETS'96 Vancouver, Canada
(http://www.cs.rpi.edu/assets)
Apr. 11-14 IEEE SOUTHEASTCON '96 Tampa, FL
(http://www.eng.usf.edu/EE/secon96.html)
Apr. 15-19 ATM Forum Anchorage, Alaska
Apr. 15-19 ANSI X3T11 (Tentative) Irvine, CA
Apr. 29-May 2 Internet World '96 San Jose, CA
May 6-10 ANSI X3T10 '96 Adaptec Ft. Lauderdale, FL
May 6-10 5th Int'l WWW Conference Paris, France
May 7-10 1st Annual Conf. Emerging
Tech & Appl in Communications Portland, OR
May 13-16 7th Joint European Ntwk Conf. Budapest, Hungary
May 13-17 5th UNIX Sys. Admn, Ntwkng
Security Symp. Washington, DC
May 13-29 ISO/IEC JTC 1/SC 21
WGs and Plenary (Firm) Kansas City, MO
May 21-23 Internet World Intntl London, England
Cooper [Page 26]
Internet Monthly Report October 1995
May 23-24 3rd Intntl Wkshp on Community
Networking (Tentative) Antwerpen, Belgium
(http://www.bip.be/cn3)
Jun. 3-5 18th Biennial Symposium on Communications
Kingston, Ont, Canada
Jun. 4-6 Internet World Mexico Mexico City, Mexico
Jun. 10-14 ATM Forum Orlando, FL
Jun. 10-14 NetWorld+Interop Frankfurt, Germany
Jun. 10-14 OIW (Firm)
Jun. 10-14 ANSI X3T11 Santa Fe, NM
Jun. 10-15 Americas TELECOM '96 Rio de Janeiro
Jun. 11-13 EMail World & Internet Expo Chicago, IL
Jun. 11-14 Vir. Reality & VRML World '96 San Jose, CA
Jun. 17-21 2nd Conf. Object-Oriented
Technologies & Sys. (COOTS) Toronto, Ont, Canada
Jun. 23-27 1st Intntl IEEE Wkshp on
Enterprise Ntwkg - w/ICC
SUPERCOM'96 Dallas, TX
Jun. 24-27 ICC '96/SUPERCOMM'96 Dallas, TX
Jun. 24-28 INET '96 Montreal, Canada
Jun. 24-28 36th IETF (Under Consideration)
Jul. 8-12 IEEE 802 '96 Univ of Twente Enschede, Netherlands
Jul. 10-13 4th TCL/TK Workshop (TCL/TK 96) Monterey, CA
Jul. 15-19 ANSI X3T10 '96 Symbios Logic Colorado Springs, CO
Jul. 15-19 NetWorld+Interop Tokyo, Japan
Jul. 22-25 6th USENIX Security Symposium San Jose, CA
Jul. 26-28 Internet World Home Expo '96 San Jose, CA
Aug. 5-8 Internet World Brazil Sao Paulo, Brazil
Aug. 5-9 ANSI X3T11 Boulder, CO area
Aug. 12-16 12th Europ. Conf. on AI (ECAI) Budapest, Hungary
(http://www.dfki.uni-sb.de/ecai96/)
Aug. 14-15 Web Seminars '96 Dallas, TX
Aug. 19-23 ATM Forum Baltimore, MD
Aug. 19-21 Int. World Australia Pacific Sydney, Australia
FALL NSC'96 - Network Services Conf. Bled, Slovenia
Sep. 2-6 14th IFIP Conf. Canberra, AU
Sep. 9-13 ANSI X3T10 '96 Digital Natick, MA
Sep. 9-13 OIW (Firm)
Sep. 13-17 10th USENIX Syst. Admin
Conference (LISA '96) Chicago, IL
Sep. 10-12 EMail World & Internet Expo Boston, MA
Sep. 15-20 OMG TC Hyannis, MA
Sep. 16-20 NetWorld+Interop Atlanta, GA
Sep. 24-27 IFIP WG6.1 w/FORTE/PSTV (Under Consideration)
Oct. 1-3 Email World & Internet Expo Toronto, Ontario, CA
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Oct. 7-11 ATM Forum Montreux, Switzerland
Oct. 7-11 NetWorld+Interop Paris, France
Cooper [Page 27]
Internet Monthly Report October 1995
Oct. 28-Nov. 1 NetWorld+Interop London, England
Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys.
Design & Implement. (OSIDI II) Seattle, WA
Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA
Nov. 11-15 37th IETF (Under Consideration)
Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada
Nov. 18-22 37th IETF (Under Consideration)
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Nov. 25-29 NetWorld+Interop Sydney, Australia
Dec. 2-6 ANSI X3T11 TBD
Dec. 2-6 ATM Forum Vancover, BC
Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA
Dec. 9-12 Internet World '96 Baltimore, MD
Dec. 9-12 37th IETF (Under Consideration)
Dec. 9-13 OIW (Firm)
1997
-----------
Jan. 6-10 ANSI X3T10 '97
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque
Mar. 11-15 ANSI X3T10 '97
Apr. 6-11 38th IETF (Under Consideration)
May 5-9 ANSI X3T10 '97
Jun. 8-12 ICC '97 Montreal
Jun. 9-13 OIW (Firm)
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Nov. 3-7 ANSI X3T10 '97
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
1998
-----------
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
1999
-----
Oct. 8-14 TELECOM '99 Geneva, Switzerland
Cooper [Page 28]
Internet Monthly Report October 1995
TERENA SECRETARIAT
Ref. TSec(95)001 November 1995
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact the
chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
**********************************************************************
MEETING/DATE LOCATION
============ ========
TERENA Executive Committee
--------------------------
13 December Amsterdam
TERENA Technical Committee
--------------------------
10 November Amsterdam
TERENA General Assembly
-----------------------
GA5
16-17 May 1996 Budapest
TERENA Working Groups
---------------------
12, 13 and 15 May 1996 Budapest
-----------------------------------------------------------------
=================================================================
DANTE
-----
Board of Directors
1 December Amsterdam
EBONE
-----
ECCO (Ebone Consortium of Contributing Organisations)
16 April 1996 Paris
Cooper [Page 29]
Internet Monthly Report October 1995
EMC (Ebone Management Committee)
28 November Amsterdam
EOT (Ebone Operations Team)
and EOT-Training
18-19 December Munich
NATO/INSIGHT/WWW
----------------
16-18 November Budapest
RIPE
----
April/May 1996 Berlin
CCIRN
-----
29 June 1996 Montreal, Canada
IETF
----
4-8 December Dallas, Texas, USA
4-8 March 1996 Los Angeles, CA, USA
24-28 June 1996 Montreal, Quebec, Canada
November 1996 tbd
April 1997 tbd
EWOS
----
Technical Assembly
12/13 December Brussels
Workshops
15-19 January 1996 Brussels
25-29 March 1996 "
24-28 June 1996 "
21-25 October 1996 "
ETSI
----
GA22 5-6 December Nice, France
GA23 18-19 April, 1996 "
Cooper [Page 30]
Internet Monthly Report October 1995
GA24 10-11 December, 1996 "
TA23 7-9 November "
TA24 15-17 April, 1996 "
TA25 23-25 October, 1996 "
EEMA
----
Regional Conference
29 November - 1 December Malta
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
------------------
JENC7 - 7th Joint European Networking Conference
------------------------------------------------
13-16 May 1996
Hungarian Academy of Sciences, in Budapest, Hungary
THE ROLE OF NETWORKING IN THE INFORMATION SOCIETY
Subject areas are:
-User Support and Education
-Policy, Economic and Societal Issues
-Network Engineering
-Network Technology
-Application Technology
-Infrastructure Developments
Deadline paper submissions 19 November 1995
For information, email <jenc7-sec at terena.nl>
WWW access address is: http://www.terena.nl/terena/jenc7
NSC'96 - Network Services Conference 1996
-----------------------------------------
Autumn 1996,
Convention Centre, Bled, Slovenia
For information, email <nsc96-sec at terena.nl>
Cooper [Page 31]
Internet Monthly Report October 1995
WWW access address is: http://www.terena.nl/terena/nsc96/
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OTHER CONFERENCES
-----------------
nb. For some of the following events, full text information may be
available from the TERENA Document Store under the directory calendar,
in which case the file name is specified under the information
presented below. The files may be retrieved via:
anonymous FTP: ftp.terena.nl
Email: server at terena.nl
Gopher: gopher.terena.nl
World Wide Web: http://www.terena.nl/terena/information/calendar/
IEE/BMVA COLLOQUIUM
-------------------
DOCUMENT IMAGE PROCESSING FOR MULTIMEDIA ENVIRONMENT
4 November
IEE Savoy Place, London, U.K.
Papers to be submitted by 4 August to:
Dr. R.B. Johnson, Dept. of Electrical & Electronic Engineering, Bristol
email <r.b.johnson at bristol.ac.uk>
or
Dr. t. Tan, Faculty of Science, Dept. of Computer Science, University
of Reading - email <t.tan at rdg.ac.uk> or <k.d.baker at rdg.ac.uk>
OPENNET'95
----------
7-9 November
Goettingen, Germany
For information email <konferenz at digi.de> or <schweiger at multinet.de>
NORDUnet'95 Conference
----------------------
14-16 November
Sheraton Copenhagen Hotel, Copenhagen, Denmark
Organized by UNI-C, this 15th annual conference will provide a
forum for universities, industry and public organizations.
Cooper [Page 32]
Internet Monthly Report October 1995
For information email <Niels.E.Raun at uni-c.dk> or
tel: +45 35 82 83 55 fax: +45 31 83 79 49
European IT Conference (IETC'95)
--------------------------------
27-29 November
Palais des Congres, Brussels, Belgium
Organized by the European Commission, DGIII, the theme of this conference
is "Managing Change" and will focus on the challenges to individuals,
enterprises and the public secton in contributing and adapting to the
Information Society.
For information contact EITC'95 on Internet:
http://www.cordis.lu
or fax: +32 2 296 99 30
Fourth International World Wide Web Conference
----------------------------------------------
"The Web Revolution"
11-14 December
Cambridge, Boston. Massachusetts, USA
Organized by MIT-Laboratory for Computer Science and OSF-Research Institute.
The aim of this conference is to bring together researchers, developers,
and users working with the World Wide Web.
For further information:
http://www.w3.org/hypertext/conferences/WWW/
email <www4-help at w3.org>
tel: +1 617 253 4087 fax: +1 617 258 5090
1995 IFIP International Working Conference
on User Layer Protocols, Architectures and Applications (ULPAA)
---------------------------------------------------------------
11-15 December
Sydney, Australia
To provide an international forum for exchange of information
on technical, economic, and social impacts and experiences with
upper layer protocols, architectures and distributed applications.
For further info: http:/www.ee.uts.edu.au/ifip/ULPAA95.html
MULTIMEDIA COMPUTING AND NETWORKING 1996
----------------------------------------
29-31 January 1996
San Jose, California
This conference is part of the IS&T/SPIE 1996 International Symposium
on Electronic Imaging to be held 28 Jan. - 2 Feb.1996
Cooper [Page 33]
Internet Monthly Report October 1995
Deadline of paper submission 10 July - electronic versions to:
<mmcn96 at cs.utexas.edu>
For up-to-date information about MMCN96 access web page at:
http://www.cs.utexas.edu/users/mmcn96
INTERNATIONAL ZURICH SEMINAR ON DIGITAL COMMUNICATIONS 1996
-----------------------------------------------------------
Broadband Communiations: Networks, Services, Applications,
Future Directions
19-23 February 1996
Swiss Institute of Technology (ETH), Zurich, Switzerland
Deadline for submission of papers is 15 May 1995
For further information, email Prof. Dr. Bernhard Plattner
<izs96-pc-chair at tik.ethz.ch>, fax.+41 1 632 1035
Call for Papers on TERENA Document Server under
rare/information/calendar. The file is called izs96-cfp.txt.
The 1996 Internet Society Symposium on Network
and Distributed System Security
----------------------------------------------
22-23 February 1996
San Diego Princess Resort, San Diego, CA, USA
Concerning the practical aspects of network and distributed system
security,
Advance program and registration information will be made available
on URL: http://nii.isi.edu/info/sndss
ASSETS'96 - The 2nd ACM/SIGCAPH Conference on Assistive Technologies
--------------------------------------------------------------------
(sponsored by ACM's Special Interest Group on Computers and the
Physically Handicapped)
11-12 April 1996
Waterfront Center Hotel, Vancouver, Canada
The conference scope spans disability and special needs of all kinds,
including but not limited to: sensory; motor; cognitive; and emotional.
For further information contact:
Conference Program Chair <jaffe at roses.stanford.edu>
Conference General Chair <glinert at cs.rpi.edu>
The Conference Web Page may be found at:
http://www.cs.rpi.edu/assets
3rd International Conference on Electronic Library and
Visual Information Research (ELVIRA 96)
Cooper [Page 34]
Internet Monthly Report October 1995
------------------------------------------------------
The UK Digital Libraries Conference.
30 April - 2 May 1996
Hilton National Hotel, Milton Keynes, UK
Covering both technical and socio-economic aspects of the electronic
library, as well as providing a forum discussion of new areas of
development.
Submission of papers is 17 November 1995.
For further information contact:
Kathryn Arnold <karnld at dmu.ac.uk> or
WWW page: http://ford.mk.dmu.ac.uk/elvira/elvira3.html
EEMA '96 Conference
-------------------
(European Electronic Messaging Association)
11-14 June 1996
Les Pyramides/Sheraton Hotel & Towers, Brussels, Belgium.
Working to shape the future of global messaging, this will be a
user-driven conference, created for the business user.
For information contact: <eemaoffice at attmail.com>
or tel: +44 1386 793 028 fax: +44 1386 793 268
INET'96 - Developing Country Workshop
-------------------------------------
June 1996
Montreal, Quebec, Canada
A seven-day program - prior to the conference - of intensive instruction
with a hands-on emphasis on Internet set up, operations, maintenance and
management.
For information email: <workshop-info at isoc.org>
For application to attend email: <workshop-apply at isoc.org>
INET'96
The Internet: Transforming our Society Now
------------------------------------------
25-28 June 1996
Montreal Convention Center, Montreal, Quebec, Canada
Focusing on worldwide issues of Internet networking
Papers to be submitted by 15 Jan.1996 to <inet-submission at isoc.org>
The Program Committee may be contacted at <inet-program at isoc.org>
Information also available on:
WWW page: http://www.crim.ca/inet96/mtl.html
Gopher://gopher.isoc.org:70/11/isoc/conferences/inet96/
Cooper [Page 35]
Internet Monthly Report October 1995
ftp://ftp.isoc.org/isoc/conferences/onet96/
International Congress and Technical Exhibition
"Water: Ecology and Technology"
-----------------------------------------------
17-21 September 1996
Moscow, Russia
Organized by: Russian Federal Committee for Water Management,
Russian Federal Ministry of Construction, Ministry of Environment
and Natural Resources Protection, Municipal Enterprise "Mosvodokanal",
State Enterprise "Vodokanal St. Petersburg",Stock Company "SIBICO
International".
For all further information, contact:
<postmaster at sibico.MSK.RU>
telephone/telefax: +7 095 207 63 60
==================
updated 03.11.1995
==================
--------------------
Madeleine Oberholzer
TERENA Secretary
Address:
TERENA Secretariat
Singel 466 - 468
NL - 1017 AW AMSTERDAM
Voice : + 31 20 639 11 31
Fax : + 31 20 639 32 89
Email : secretariat at terena.nl (for all general matters)
Cooper [Page 36]
Received: from ietf.org by ietf.org id aa06960; 16 Mar 97 17:11 EST
Received: from mail1.themall.net by ietf.org id aa06879; 16 Mar 97 17:10 EST
Received: from Default (usr15-dialup36.mix2.Boston.mci.net [166.55.70.164]) by mail.themall.net (8.8.5/8.8.2/IIAM 1.0 (DCH)) with SMTP id OAA13113 for <ietf at ietf.org>; Sun, 16 Mar 1997 14:07:01 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leslie_Mann <fosterm1 at mail.themall.net>
Message-Id: <199703162207.OAA13113 at mail.themall.net>
Comments: Authenticated sender is <fosterm1 at mail.themall.net>
To: ietf at ietf.org
Date: Sun, 16 Mar 1997 16:50:25 +0000
Subject: Take me off the list Please
X-Confirm-Reading-To: fosterm1
X-pmrqc: 1
Return-receipt-to: fosterm1
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)
Source-Info: From (or Sender) name not authenticated.
remove me from the list
take me off the list
don't send any more
Received: from ietf.org by ietf.org id aa16127; 16 Mar 97 20:36 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa16005;
16 Mar 97 20:32 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA07926; Sun, 16 Mar 97 20:29:51 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA12162; Sun, 16 Mar 1997 20:29:43 -0500
Date: Sun, 16 Mar 1997 20:29:43 -0500
Message-Id: <9703170129.AA12162 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Leslie_Mann <fosterm1 at mail.themall.net>
Cc: ietf at ietf.org
In-Reply-To: Leslie_Mann's message of Sun, 16 Mar 1997 16:50:25 +0000,
<199703162207.OAA13113 at mail.themall.net>
Subject: Re: Take me off the list Please
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
From: Leslie_Mann <fosterm1 at mail.themall.net>
Date: Sun, 16 Mar 1997 16:50:25 +0000
remove me from the list
take me off the list
don't send any more
I will note that despite the calls for automatic "remove unsubcribe"
messages, it's not going to solve the problem for idiotic people who
don't know about the listname-request at host.name convention --- or any
other convention.
Unless someone comes up with a "smart mailer" that can parse arbitrary
English sentences, we're not going to be able to come up with a
technological solution to a problem which is fundamentally a
sociological problem.
Perhaps the best thing we can do is to arrange to arrange to have a
message get sent out to each person as they join the IETF list,
instructing them in the standard, decades old, INTERNET
listname-request at host.name convention. (Sending a single "unsubscribe"
to the main list was a BITNET-ism, historically, and nothing more.)
- Ted
Received: from ietf.org by ietf.org id aa16687; 16 Mar 97 20:52 EST
Received: from dumbcat.codewright.com by ietf.org id aa16643;
16 Mar 97 20:51 EST
Return-Path: <marc at dumbcat.codewright.com>
Received: from localhost.codewright.com by dumbcat.codewright.com (4.1/smail-24May90)
id AA03369; Sun, 16 Mar 97 17:47:46 PST
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: Leslie_Mann <fosterm1 at mail.themall.net>, ietf at ietf.org
Subject: Re: Take me off the list Please
In-Reply-To: Your message of "Sun, 16 Mar 1997 20:29:43 EST."
<9703170129.AA12162 at dcl.MIT.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 16 Mar 1997 17:47:29 -0800
Message-Id: <3366.858563249 at dumbcat.codewright.com>
Sender:ietf-request at ietf.org
From: Marco S Hyman <marc at dumbcat.codewright.com>
Source-Info: From (or Sender) name not authenticated.
"Theodore Y. Ts'o" writes:
> Perhaps the best thing we can do is to arrange to arrange to have a
> message get sent out to each person as they join the IETF list,
> instructing them in the standard, decades old, INTERNET
> listname-request at host.name convention. (Sending a single "unsubscribe"
> to the main list was a BITNET-ism, historically, and nothing more.)
Such a message is sent out, but I don't know how long that has been
true. However, the message (attached) may need some work -- I once
forwarded it to someone who sent "remove" to the list and got back
email saying, in effect, "what does that mean?".
// marc
-----
General info
------------
Subcription/unsubscription/help requests should always be sent to the -request
address of a mailinglist.
If a mailinglist for example is called "thelist at some.domain", then the -request
address can be inferred from this to be: "thelist-request at some.domain".
To subscribe to a mailinglist, simply send a message with the word "subscribe"
in the Subject: field to the -request address of that list.
To unsubscribe from a mailinglist, simply send a message with the word
"unsubscribe" in the Subject: field to the -request address of that list.
In the event of an address change, it would probably be the wisest to first
send an unsubscribe for the old address (this can be done from the new
address), and then a new subscribe to the new address (the order is important).
Do not send multiple (un)subscription or info requests in one mail. Only one
will be processed per mail.
If you feel you need to reach a human, send email to ietf-lists at ietf.org.
--
Received: from ietf.org by ietf.org id aa26208; 16 Mar 97 23:37 EST
Received: from cnri by ietf.org id aa26114; 16 Mar 97 23:33 EST
Received: from shell1.aimnet.com by CNRI.Reston.VA.US id aa00584;
16 Mar 97 23:33 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id UAA19723; Sun, 16 Mar 1997 20:29:55 -0800 (PST)
Date: Sun, 16 Mar 1997 20:29:55 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Vernon Schryver <vjs at mica.denver.sgi.com>
cc: ietf at CNRI.Reston.VA.US
Subject: re: bcc's (was Authenticated Mail)
In-Reply-To: <199703150210.TAA25152 at mica.denver.sgi.com>
Message-ID: <Pine.SOL.3.95.970316202436.18340G-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 14 Mar 1997, Vernon Schryver wrote:
> Who says the blind addressee is removed?
Well I have done some experiments and when the mail has arrived at the
blind addressee, the 'for dwm at xpasc.com' is missing from the 'from ...'
line in the mail headers. I made the experiments after another individual
on another list complained about the information being missing.
> The envelope is not the same as the message itself.
>
> If your SMTP code does not include "for xxxx" in the Received: line or
> your mail user agent does not let you see the full headers upon demand,
> then fix them. There's no need to change the protocol.
My ISP is using some version of sendmail. Is this a sendmail bug or a
configuration error?
>
> It is nice when the originating MUA sends a separate copy with a
> special cover sheet, but that is also not a protocol issue.
My post did not intend to suggest that a cover sheet should be attached,
I was refuting the privacy argument by describing how BCCs are handled
in the physical mail world.
Dave Morris
Received: from ietf.org by ietf.org id aa27117; 16 Mar 97 23:57 EST
Received: from cnri by ietf.org id aa27031; 16 Mar 97 23:55 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa00932; 16 Mar 97 23:55 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA08950 for <@sgi.engr.sgi.com:ietf at CNRI.Reston.VA.US>; Sun, 16 Mar 1997 20:52:51 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA02963 for ietf at CNRI.Reston.VA.US; Sun, 16 Mar 1997 21:52:47 -0700
Date: Sun, 16 Mar 1997 21:52:47 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199703170452.VAA02963 at mica.denver.sgi.com>
Subject: re: bcc's (was Authenticated Mail)
Cc: ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
> Received: from momserv.denver.sgi.com (momserv.denver.sgi.com [169.238.64.2]) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02900 for <vjs at mica.denver.sgi.com>; Sun, 16 Mar 1997 21:30:23 -0700
> Received: from sgi.sgi.com by momserv.denver.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO)
> for <vjs at mica.denver.sgi.com> id VAA23850; Sun, 16 Mar 1997 21:30:18 -0700
> Received: from shell1.aimnet.com (shell1.aimnet.com [204.247.0.210]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA06192 for <vjs at mica.denver.sgi.com>; Sun, 16 Mar 1997 20:30:05 -0800
> Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id UAA19723; Sun, 16 Mar 1997 20:29:55 -0800 (PST)
> ...
> Well I have done some experiments and when the mail has arrived at the
> blind addressee, the 'for dwm at xpasc.com' is missing from the 'from ...'
> line in the mail headers. I made the experiments after another individual
> on another list complained about the information being missing.
Of course the blind addressees are not in the From: or cc: lines.
If they were present there, the copy would not be very blind.
Consider the 1st, 2nd, and 3rd Received: lines in the copy of your
message sent to me.
> ...
> My ISP is using some version of sendmail. Is this a sendmail bug or a
> configuration error?
Look for a line in sendmail.cf that starts "HReceived:" and check
to see if it contains something like "for $u$.".
That feature has been around in sendmail for more than 10 years. Some
people remove the "for $u$." on the grounds that a bounce would
otherwise include addressees that would otherwise be hidden. While
that is a logically valid statement, I think that concern is
superficial. There are too many other leaks of such information in
SMTP as it is commonly used. You should always assume that anything
you write in cleartext will be seen by many people, and should not be
bothered if it is published in the newspaper in the morning.
Vernon Schryver, vjs at sgi.com
$dOI+2z#tjA9 \
.pdefaults
.loc-cshrc
.nevotinit
.gamtables
.signature
.sgihelprc
.insightrc
.Xdefaults
Received: from ietf.org by ietf.org id aa02230; 17 Mar 97 3:54 EST
Received: from proxy3.ba.best.com by ietf.org id aa01860; 17 Mar 97 3:42 EST
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy3.ba.best.com (8.8.5/8.8.3) with SMTP id AAA19185; Mon, 17 Mar 1997 00:36:37 -0800 (PST)
Date: Mon, 17 Mar 1997 00:36:37 -0800 (PST)
Sender:ietf-request at ietf.org
From: Walter Ian Kaye <walter at natural-innovations.com>
X-Sender: boo at shellx.best.com
To: David Vineberg <davin at village.ios.com>
cc: ietf at ietf.org
Subject: Re: Internet Monthly Report - October 1995
In-Reply-To: <Pine.BSF.3.95.970316162444.8946A-100000 at village.ios.com>
Message-ID: <Pine.SGI.3.95.970317003522.9110B-100000 at shellx.best.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
October 1995?!?
Received: from ietf.org by ietf.org id aa02662; 17 Mar 97 4:08 EST
Received: from cnri by ietf.org id aa02604; 17 Mar 97 4:07 EST
Received: from shell1.aimnet.com by CNRI.Reston.VA.US id aa05176;
17 Mar 97 4:07 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id BAA02972; Mon, 17 Mar 1997 01:04:26 -0800 (PST)
Date: Mon, 17 Mar 1997 01:04:26 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Vernon Schryver <vjs at mica.denver.sgi.com>
cc: ietf at CNRI.Reston.VA.US
Subject: re: bcc's (was Authenticated Mail)
In-Reply-To: <199703170452.VAA02963 at mica.denver.sgi.com>
Message-ID: <Pine.SOL.3.95.970317010105.2631B-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 16 Mar 1997, Vernon Schryver wrote:
> > Received: from momserv.denver.sgi.com (momserv.denver.sgi.com
> [169.238.64.2]) by mica.denver.sgi.com
> (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02900 for
^^^
> <vjs at mica.denver.sgi.com>; Sun, 16 Mar 1997 21:30:23 -0700
^^^^^^^^^^^^^^^^^^^^^^^^^
Is missing on mail sent to me when I am on bcc: address rather than to: or
cc:. (I presume that bcc: is what the ietf mailing list uses as well.)
I will discuss this with my ISP. THanks for your suggestions.
Dave Morris
Received: from ietf.org by ietf.org id aa02864; 17 Mar 97 4:09 EST
Received: from AIC.NET by ietf.org id aa02666; 17 Mar 97 4:08 EST
Received: by aic.net for at Mon, 17 Mar 1997 12:01:57 +0300 (GMT)
Message-Id: <199703170901.MAA16214 at aic.net>
Subject: Re: Take me off the list Please
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Mon, 17 Mar 1997 12:01:56 +0300 (GMT)
Cc: fosterm1 at mail.themall.net, ietf at ietf.org
In-Reply-To: <9703170129.AA12162 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 16, 97 08:29:43 pm
Sender:ietf-request at ietf.org
From: Edgar Danielyan <edd at acm.org>
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> Perhaps the best thing we can do is to arrange to arrange to have a
> message get sent out to each person as they join the IETF list,
> instructing them in the standard, decades old, INTERNET
> listname-request at host.name convention. (Sending a single "unsubscribe"
> to the main list was a BITNET-ism, historically, and nothing more.)
But it worked, in most cases....
- Edgar
Received: from ietf.org by ietf.org id aa07213; 17 Mar 97 6:34 EST
Received: from mersey.hursley.ibm.com by ietf.org id aa06935; 17 Mar 97 6:30 EST
Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03)
id AA75982; Mon, 17 Mar 1997 11:27:44 GMT
Date: Mon, 17 Mar 1997 11:27:44 GMT
Message-Id: <9703171127.AA75982 at hursley.ibm.com>
Sender:ietf-request at ietf.org
From: "(Brian E Carpenter)" <bcarpent at hursley.ibm.com>
Subject: Open IAB at Memphis
To: ietf at ietf.org
Reply-To: brian at hursley.ibm.com
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 438
Source-Info: From (or Sender) name not authenticated.
IETF,
The IAB held an invitational workshop on Internet Security
Architecture earlier this month, hosted by ATT. A report on
this will be the main item in the open IAB meeting in Memphis:
Internet Architecture Board (iab)
Wednesday, April 9 at 2000-2100
===============================
AGENDA:
1. Report on IAB Security Architecture workshop
(Steve Bellovin)
2. Open microphone session
--
Brian Carpenter (IAB chair)
Received: from ietf.org by ietf.org id aa08104; 17 Mar 97 6:56 EST
Received: from mail.datakom.su.se by ietf.org id aa07973; 17 Mar 97 6:55 EST
Received: (from uucp at localhost) by mail.datakom.su.se (8.7.3/8.7.3) id LAA00781 for <ietf at ietf.org>; Mon, 17 Mar 1997 11:51:39 GMT
Message-Id: <199703171151.LAA00781 at mail.datakom.su.se>
Received: from t6o3p13.telia.com(194.22.192.99) by mail via smap (V1.3)
id smab00744; Mon Mar 17 12:51:18 1997
Sender:ietf-request at ietf.org
From: David Lerdell <fdl at hhs.se>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Researching IETF
Date: Mon, 17 Mar 1997 12:48:10 +0100
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1157
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Dear Sirs,
My name is David Lerdell, and I am a Research Assistant at the Stockholm
School of Economics and affiliated to SCORE (Stockholm Center for
Organizational Research) and SCANCOR at Stanford university.
I am writing my Ph.D.-thesis on how the Internet is organised, and as a
part of that research project I am currently studying ISOC (to which I am
also a member), IETF etc. My interest of these organisations depends upon
the role they play in the organisation and/or standardisation of the
Internet. They are also interesting since they have linkages to the earlier
part of the history of the Internet, and the role they play "between"
science, business and politics. The organising of the Internet cannot be
explained from the existing theories in disciplines like International
Politics/International Relations, Organisation theory, etc. or what have
you in the social sciences. So other than being a very interesting
phenomenon as such, the Internet is very interesting from a theoretical
point of view.
When talking to one of the members of ISOC's Advisory Council in Sweden, Mr
Olle Thylander, he thought it would be a good idea for me to visit you.
Since I will attend the 38th IETF-meeting in Memphis in April, and am
planning to spend some time in the Washington D.C.-area the week after that
meeting, I am wondering if you would have the kindness to let me visit you
sometime between Monday April 14th until Wednesday April 16th. I would be
very grateful if you or one of your colleagues could spare some time to
have a talk with me about IETF and its activities and the role you play in
the process of organising the Internet.
Yours sincerely,
David Lerdell
--
_____________________________________________________________________
Stockholm School of Economics / Dept. of Public Management (F)
SCORE-Stockholm Center for Organizational Research
SE-106 91 STOCKHOLM / Tel: +46-(0)8-6747415 / Fax: +46-(0)8-164908
E-mail: fdl at hhs.se / WWW: http://www.update.uu.se/~dli/
PGP: 8F 65 AA FD BB 1B D2 57 81 96 92 89 F7 9A 44 B2 (key on request)
_____________________________________________________________________
Received: from ietf.org by ietf.org id aa12598; 17 Mar 97 9:21 EST
Received: from ietf.ietf.org by ietf.org id aa12220; 17 Mar 97 9:17 EST
To: ietf at ietf.org
Subject: 1st European Conference on Voting, Rating, Annotation in Vienna 21-22
April 97
Sender:ietf-request at ietf.org
From: Roland Alton-Scheidl <Roland.Alton-Scheidl at oeaw.ac.at>
Date: Mon, 17 Mar 1997 09:16:59 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703170917.aa12220 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
**************************************************************
* First European Conference on Internet Voting and Rating *
* *
* VOTING, RATING, ANNOTATION *
* WEB4GROUPS AND THE FUTURE OF COMMUNICATION ON THE INTERNET *
* *
* 21-22 April 1997, Vienna, Austria *
**************************************************************
This conference aims to bring together people working on future aspects of
computer mediated communications. Based on a study, which will be made
available to all participants before the conference, experts are invited to
make comments and present their own approaches. In a workshop we will
collaborate on common visions, metaphors, implementation and dissemination
strategies for voting, rating and annotation services in the Internet.
The study 'Voting and Rating: Perspectives for information collection,
decision making and collaborative rating using Web4Groups' investigates
possible ways of 'rating' in computer-mediated communication (CMC)
processes. This refers both to rating activities in decision making
('voting') and to the rating of content ('rating' of web-pages, of
contributions to a discussion, etc.). The specific implementation of rating
and voting features in Web4Groups is examined in order to assess the
potential and feasability of computer supported rating.
The following experts will give presentations:
John December (New York, USA): The Matrix of Society and Technology in CMC;
Jakob Hummes (Sophia Antipolis, FR): Annotation Concepts;
Arnold B.Urken (New Jersey, USA): Voting Implementation Issues;
Miklos Irmay (Z=FCrich,CH): Information Quality in Science;
Steven L.Clift (USA): Minnesota E-Democracy;
David R. Newman (IR): Preferendum;
Marylin Davis (USA): eVote;
... and many more will come!
* * *
The conference is an activity of the EC funded *Web4Groups* project.
Web4Groups is an international initiative for setting up a global group
communication service by combining public and personal messaging tools
already commonly available and adding value by integrating group
communication facilities like joint editing, multilingual support, voting
and rating support, audiotex and fax gateway, etc.
With Web4Groups, it takes you only a mouse-click to give any real world
acitivity in which two or more people are involved a virtual place in
Cyberspace!
Try http://www.Web4Groups.at to access an early alfa release to get a first
impression! Web4Groups will have its first public presentation at the first
conference day.
* * *
Find a preliminary program about the conference at:
http://www.Web4Groups.at/w4g/source/conf.html
The conference is organised by the
Austrian Academy of Sciences'
Research Unit for Socioeconomics
Baeckerstrasse 13, A-1010 Vienna
phone +43 1 51581 441, fax +43 1 51581 566
together with the Hungarian Academy of Sciences,
MTA SZTAKI, Computer and Automation Research Institute
* * *
REGISTRATION:
There is no conference fee.
Registration is necessary for receiving a copy of the study.
And it will make the planning of the conference easier!
Please register by e-mail or by fax:
Your name: .............................
E-Mail: ................................
Postal Address: ........................
Need support to find accomodation: yes/no
Send to:
Sabine Benzer
email: benzer at oeaw.ac.at
fax: +43 1 515 81 566
We are looking forward to seeing you in Vienna!
Received: from ietf.org by ietf.org id aa14763; 17 Mar 97 10:01 EST
Received: from rodan.UU.NET by ietf.org id aa14523; 17 Mar 97 9:59 EST
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQchgt28911; Mon, 17 Mar 1997 09:56:34 -0500 (EST)
Message-Id: <QQchgt28911.199703171456 at rodan.UU.NET>
X-Mailer: exmh version 2.0gamma 1/27/96
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Danger Will Robinson! S/N ratio approaching zero!
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Mar 1997 09:56:34 -0500
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
How about we designate some of the IETF meeting registration fees to
fund someone to moderate an IETF mailing list, to be used for the transaction
of IETF business? We could advance the state of the art, and insist
that all submissions be privacy enhanced, or maybe just signed. Perhaps
some of the domain registration fees set aside to enhance the Internet
infrastructure might be used for such a purpose?
Between conference announcements, requests for papers, educating people
how Internet mailing lists have worked for the last decade, and helpful
offers on how to make a lot 'o money, it's tough to find the occasional
message involved in some meta-discussion related to the IETF.
Alternatively, we might rely on IETF-ANNOUNCE to warn us of upcoming
meetings and hotel room shortages, and conduct business only on the
working group mailing lists. I fear that this list has been mentioned
in a few too many articles in the press and is no longer useful for it's
original purpose.
Received: from cnri by ietf.org id aa15653; 17 Mar 97 10:24 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12234;
17 Mar 97 10:24 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <NAA16100 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 13:59:09 GMT
Message-Id: <9703171349.AA25058 at us1rmc.bb.dec.com>
Date: Mon, 17 Mar 97 08:49:41 EST
From: "John Wray, Digital DPE, 508/486-5210 17-Mar-1997 0843" <wray at tuxedo.enet.dec.com>
To: marc at splash.cygnus.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at splash.cygnus.com
Subject: Re: gss_export_sec_context()
Precedence: bulk
>>> There seem to be advocates in favor of always deleting the context
>>> regardless of the error (so that an effect of calling
>>> gss_export_sec_context is that the specified context is always
>>> released upon return), and others who favor keeping the context
>>> valid in the event of an error (so that the caller can invoke
>>> gss_inquire_context() on the context to log a failure message).
>
>Nit: another reason to keep the context valid is to keep using it, not
>just to log a failure.
>
>In any case, there is a middle ground:
>
>Mechanisms should strive to keep the context handle valid, but
>applications should be aware that the mechanism might not be able to
>do this, invalidating the handle if the call to export_sec_context
>fails. This would mean that applications *must* delete a sec_context
>if the export fails. If we do this, we need to figure out what the
>various context calls do in this state. It would seem that
>inquire_context would be ok, but other calls should fail, probably
>with GSS_S_NO_CONTEXT.
How about mechanisms should strive to keep the context handle valid; mechanisms
that are unable to do so should delete the context and set the context-handle
parameter to GSS_C_NO_CONTEXT to indicate that it is no longer valid.
Therefore the application should inspect the context handle after an error
return from gss_export_sec_context(), and only delete the context (or attempt
to work-around the error) if the handle is not equal to GSS_C_NO_CONTEXT.
We could take a similar approach in the init/accept_sec_context case -
encourage mechanisms to leave the context valid after an error (on a follow-on
call), but allow mechanisms to choose to delete the context, provided they set
the handle parameter to GSS_C_NO_CONTEXT.
John
Received: from cnri by ietf.org id aa17165; 17 Mar 97 11:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13207;
17 Mar 97 11:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA16998 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 14:20:42 GMT
Date: Mon, 17 Mar 1997 09:19:24 -0500
From: "David P. Kemp" <dpkemp at missi.ncsc.mil>
Message-Id: <199703171419.JAA03121 at argon.ncsc.mil>
To: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
X-Sun-Charset: US-ASCII
Precedence: bulk
> From: Bill Buffam <bjb at trsvr.tr.unisys.com>
>
> Okay, here's some real flame bait: <soapbox> I regard user level
> authentication provided by IPSEC as a monumental kludge. It says to the
> application layer "never mind this pretty layered structure, just assume
> what's underneath and drive it." Application protocols should work over
> any protocol stack - that's what the layered structure is all about.
> This whole idea really pollutes the cleanliness of the layers. As
> Abraham Maslow said, "When the only tool you have is a hammer,
> everything looks like a nail." I could go on at length, but I won't.
> </soapbox>
You mean you believe that any form of application-layer security
is a monumental kludge?
If the application is security-aware, and requests security services
using some API (say for example GSS-API, or some sockopt-based API),
then why should the application know or care how those services are
provided? The actual transport protection could in theory be provided
anywhere in the stack, from layer 1 on up. And (again, in theory) each
layer could have a well-defined interface to the adjacent layers so
that the session-layer module, having received a request for a secure
connection for a particular user, could either set it up using the
(misnamed) TLS protocol, or merely maintain a mapping between the
session/user ID and an SPI and rely on IPSEC to do the data transforms.
The application doesn't have to know whether the data is protected
by AH/ESP or by TLS Record Layer, it just knows that it's getting a
specified Quality of Protection.
Of course no current implementations are designed to do clean layering,
(this is, after all, the I-Q&D-ETF :-), but there is no architectural
reason that they couldn't be.
Received: from cnri by ietf.org id aa18499; 17 Mar 97 11:47 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14345;
17 Mar 97 11:47 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <NAA15778 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 13:51:30 GMT
Message-Id: <199703171351.AA01857 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: "Theodore Y. Ts'o" <tytso at mit.edu>, marc at cygnus.com
Date: Mon, 17 Mar 1997 08:51:07 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703160310.AA06044 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 15, 97 10:10:49 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
>
> From: Marc Horowitz <marc at splash.cygnus.com>
> Date: 15 Mar 1997 15:34:52 -0800
>
> Mechanisms should strive to keep the context handle valid, but
> applications should be aware that the mechanism might not be able to
> do this, invalidating the handle if the call to export_sec_context
> fails. This would mean that applications *must* delete a sec_context
> if the export fails. If we do this, we need to figure out what the
> various context calls do in this state. It would seem that
> inquire_context would be ok, but other calls should fail, probably
> with GSS_S_NO_CONTEXT.
>
> I like the first part, but why should applications *must* delete a
> sec_context if the export fails? Instead, just require them to check
> whether or not the context is still good by using inquire_context, and
> and if it returns GSS_S_NO_CONTEXT, they'll know that the context is no
> longer there. If applications don't do that, and they call other GSSAPI
> calls, those calls will fail with GSS_S_NO_CONTEXT --- what's wrong with
> that?
Proposed behaviour:
1) success: GSS_S_COMPLETE, context_token != valid interprocess token
context_handle = GSS_C_NO_CONTEXT
2) failure: GSS_S_*, context_token = EMPTY_BUFFER
context_handle = valid context handle
3) double failure for exceptionally bad situations:
GSS_S_FAILURE, context_token = EMPTY_BUFFER
context_handle = GSS_C_NO_CONTEXT
maybe GSS_S_CONTEXT_LOST?
Any reasonable application should already be able to handle (3) correctly.
-Martin
Received: from ietf.org by ietf.org id aa19258; 17 Mar 97 12:03 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa18814; 17 Mar 97 11:54 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA28722;
Mon, 17 Mar 1997 11:51:20 -0500
Message-Id: <199703171651.LAA28722 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "James E. [Jed] Donnelley" <jed at webstart.com>
Cc: ietf at ietf.org
Subject: Re: a new email infrastructure, comm. label fraud
In-Reply-To: Your message of "Sat, 15 Mar 1997 22:23:15 PST."
<199703160623.WAA14260 at shell1.aimnet.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199703160623.WAA14260 at shell1.aimnet.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1430171956P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Mon, 17 Mar 1997 11:51:15 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1430171956P
Content-Type: text/plain; charset=us-ascii
On Sat, 15 Mar 1997 22:23:15 PST, "James E. [Jed] Donnelley" said:
> I'm not so sure about this Kent. 1. It seems to me that SPAM
> is already effectively authenticated. If you can't identify
> who sent it (at least the party with the vested interest,
> who must be the ultimate source) then you can't communicate
Well, the *problem* is that usually, said communication is via a
'send a FAX to..' or "check out this URL". Of the UCE's that hit
my mailbox this morning, I didn't see many that I'd consider
"authenticated".
Examples:
To: Dear.Customer at nova.unix.portal.com,
From: please at don't.reply
From: takecards at answerme.com
Reply-To: Please.reply.to.fax.number.or.smail.address at as.shown.below.Thank.you
From: tempting at LOCNET.COM
From: nobody <nobody at mail.mass-email.com>
To: email at mass-email.com
Reply-To: emailusa at hotmail.com
Yep, sure look authenticated to *ME* ;) Half are bogus, and the people at
mass-email.com pointed the primary MX at a non-existent hostname....
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1430171956P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMy12gdQBOOoptg9JAQFNWgP/QHbamqwBeTlk4JoV786wOMA40wodVXKR
9EQm3UJsrrCEIOWnlkRcdaaJqizmk5VmBMAgyJc0BPTnQ5tM4UD70KqwL76AWAEG
+Xx9mEARCT9sBqicmPOPFoyn5Qf/+kPWGZ6xds3rIp65zbsB4mB0wpYNJM2Zhhel
xKwmeMo0cNY=
=vsSg
-----END PGP MESSAGE-----
--==_Exmh_-1430171956P--
Received: from ietf.org by ietf.org id aa22426; 17 Mar 97 13:14 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa22277;
17 Mar 97 13:09 EST
Received: from Ikkoku-Kan.Panda.COM (clane at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id KAA01479; Mon, 17 Mar 1997 10:06:02 -0800 (PST)
Received: from localhost (chj at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id KAA03028; Mon, 17 Mar 1997 10:05:39 -0800 (PST)
Date: Mon, 17 Mar 1997 09:14:03 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: a new email infrastructure, comm. label fraud
To: Valdis.Kletnieks at vt.edu
cc: ietf at ietf.org
In-Reply-To: <199703171651.LAA28722 at black-ice.cc.vt.edu>
Message-ID: <MailManager.858618843.392.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997 11:51:15 -0500, Valdis.Kletnieks at vt.edu wrote:
> Yep, sure look authenticated to *ME* ;) Half are bogus, and the people at
> mass-email.com pointed the primary MX at a non-existent hostname....
It is for this reason that I believe that attempts by individuals to take
direct action against spammers are doomed to failure. The action must be
directed against their host ISPs.
No court is going to pay much attention to an individual who got spammed, and
even if he is awarded damages, the cost of collection is too high. The small,
obscure, ISPs are no longer the problem. It's all too easy to cut off the
small guys, and as a result they've been getting quite good at corrective and
preventative measures. The worst offenders these days are the large ISPs, who
simply do not care. The spammers know this.
The only way to make the large ISPs care would be if they are hit with a class
action lawsuit. But that's unlikely to happen until we have some clearer
legislation.
Received: from ietf.org by ietf.org id aa23268; 17 Mar 97 13:31 EST
Received: from mail.proper.com by ietf.org id aa23118; 17 Mar 97 13:30 EST
Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA15332; Mon, 17 Mar 1997 10:23:20 -0800 (PST)
X-Sender: paulh at mail.proper.com
Message-Id: <v03101f01af533d0610fe at [165.227.249.100]>
In-Reply-To: <QQchgt28911.199703171456 at rodan.UU.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Mar 1997 10:30:01 -0800
To: "Louis A. Mamakos" <louie at uu.net>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Paul Hoffman <paulh at imc.org>
Subject: Re: Danger Will Robinson! S/N ratio approaching zero!
Source-Info: From (or Sender) name not authenticated.
I strongly agree. This list would be *much* more useful if moderated with a
light hand, such as removing all sub/unsub requests and UCE, and with a
gentle reminder from the moderator every once and a while when we are no
longer talking about IETF-specific business. Beginnings of threads about
"how the Internet should be" are just fine, but they should then move to
topic-specific lists within a few days.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: from cnri by ietf.org id aa24285; 17 Mar 97 13:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17282;
17 Mar 97 13:44 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA21431 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 16:09:38 GMT
Message-Id: <199703171609.AA18059 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Sam Hartman <hartmans at mit.edu>
Date: Mon, 17 Mar 1997 11:09:23 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <tslendhq7gb.fsf at luminous.MIT.EDU> from "Sam Hartman" at Mar 15, 97 02:30:12 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sam Hartman wrote:
>
> Martin> Try to keep the context valid as hard as possible.
> Martin> Someone might want to fallback to a single-process model
> Martin> if the context export fails.
>
>
> What if it is impossible under the mechanism to do so? What
> error do you propose be returned?
GSS_S_FAILURE accompanied by a meaningful minor_status for logging.
It's not a policy issue, the impossibility to restore the context
may only happen in out_of_memory case. I currently can not think
of any other close-to-panic situation. Anything else can be checked
and considered before the security context is modified or deleted.
An application may always decide to reimport a security context
that it has just finished exporting, and this should always work,
even if the mechanism tries to impose some fancy policy; therefore
context export can not be an irreversible operation.
-Martin
Received: from cnri by ietf.org id aa25607; 17 Mar 97 14:18 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18137;
17 Mar 97 14:18 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA26026 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 17:21:35 GMT
Message-Id: <199703171721.AA26324 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: gss_export_sec_context()
To: Martin.Rex at sap-ag.de
Date: Mon, 17 Mar 1997 12:21:02 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703171351.AA01857 at sap-ag.de> from "Martin Rex" at Mar 17, 97 08:51:07 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Ooops, sorry, a typo:
I wrote:
>
> Theodore Y. Ts'o wrote:
> >
> > From: Marc Horowitz <marc at splash.cygnus.com>
> > Date: 15 Mar 1997 15:34:52 -0800
> >
> > Mechanisms should strive to keep the context handle valid, but
> > applications should be aware that the mechanism might not be able to
> > do this, invalidating the handle if the call to export_sec_context
> > fails. This would mean that applications *must* delete a sec_context
> > if the export fails. If we do this, we need to figure out what the
> > various context calls do in this state. It would seem that
> > inquire_context would be ok, but other calls should fail, probably
> > with GSS_S_NO_CONTEXT.
> >
> > I like the first part, but why should applications *must* delete a
> > sec_context if the export fails? Instead, just require them to check
> > whether or not the context is still good by using inquire_context, and
> > and if it returns GSS_S_NO_CONTEXT, they'll know that the context is no
> > longer there. If applications don't do that, and they call other GSSAPI
> > calls, those calls will fail with GSS_S_NO_CONTEXT --- what's wrong with
> > that?
>
> Proposed behaviour:
> 1) success: GSS_S_COMPLETE, context_token != valid interprocess token
> context_handle = GSS_C_NO_CONTEXT
Typo, should have been: context_token = valid interprocess token
>
> 2) failure: GSS_S_*, context_token = EMPTY_BUFFER
> context_handle = valid context handle
>
> 3) double failure for exceptionally bad situations:
> GSS_S_FAILURE, context_token = EMPTY_BUFFER
> context_handle = GSS_C_NO_CONTEXT
> maybe GSS_S_CONTEXT_LOST?
>
> Any reasonable application should already be able to handle (3) correctly.
-Martin
Received: from ietf.org by ietf.org id aa25688; 17 Mar 97 14:21 EST
Received: from rome.zeitnet.com by ietf.org id aa25586; 17 Mar 97 14:18 EST
Received: from smtpgw.zeitnet.com by zeitnet.com (8.6.12/SMI-4.1)
id LAA22068; Mon, 17 Mar 1997 11:15:28 -0800
Received: by smtpgw.zeitnet.com with Microsoft Mail
id <332D97D0 at smtpgw.zeitnet.com>; Mon, 17 Mar 97 11:13:20 PST
Sender:ietf-request at ietf.org
From: Dave Roberts <dave.roberts at zeitnet.com>
To: Mark Crispin <MRC at panda.com>
Cc: ietf <ietf at ietf.org>
Subject: RE: a new email infrastructure, comm. label fraud
Date: Mon, 17 Mar 97 11:13:00 PST
Message-ID: <332D97D0 at smtpgw.zeitnet.com>
Encoding: 80 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
Mark,
While I'm not a SPAM enthusiast, I have a couple problems with this
approach. They are the same problems I have with the communications
decency act recently passed by the US Congress. The issue is, who decides
what is and isn't acceptable, and how do you hold a service provider
liable for the actions of its subscribers. The first is an issue of
censorship, plain and simple. The second issue is of assigning liability
to the actual wrongdoers, not to those who are simply providing a service
which can be used for either good or evil ;-).
Basically, I want my ISP to worry about one thing: providing me the best
Internet service. I also want my ISP fees going to nothing more than this
goal. I don't want my ISP having to invest in all sorts of solutions to
try to combat spam just so that someone, somewhere doesn't get ticked and
decide to sue them because they have deep pockets. Put another way, I
want the ISP to worry about providing the network, not to worry about the
network content. This idea of holding the ISP somehow responsible is
equivalent to holding AT&T responsible for the actions of telephone
solicitors or General Motors responsible for the actions of bank robbers
that drive Chevy getaway cars.
Personally, I don't see how you will be able to do anything reasonable
about SPAM anywhere other than the receiver. Simply, advertising exists
everywhere. It will exist on the net. The best you could hope to do is
regulate it, possibly with some sort of "Content-Disposition: SPAM"
tagging.
Note, however, that regulation is possible only *if* you could actually
get some sort of international agreement on such regulations. You must
have every possible point of SPAM injection signed up to prosecute the
perps, otherwise they just do it from another location. The net is still
wrestling with these international law issues and I don't think they'll
be solved for quite a few years. (I'm still wondering what Congress
thinks should be done if someone in Europe sends a kiddie porn picture
through email to someone in the US...)
I'm resigned to the fact that I'll have to do something about it myself,
on my end, and make do with whatever compromises result. The best the
IETF can hope for is to give me some additional filtering tools to help
separate the stuff from people I know from people I don't know
(authentication, etc.).
-- Dave Roberts
----------
From: Mark Crispin
Sent: Monday, March 17, 1997 9:14 AM
To: Valdis.Kletnieks
Cc: ietf
Subject: Re: a new email infrastructure, comm. label fraud
On Mon, 17 Mar 1997 11:51:15 -0500, Valdis.Kletnieks at vt.edu wrote:
> Yep, sure look authenticated to *ME* ;) Half are bogus, and the people
at
> mass-email.com pointed the primary MX at a non-existent hostname....
It is for this reason that I believe that attempts by individuals to take
direct action against spammers are doomed to failure. The action must be
directed against their host ISPs.
No court is going to pay much attention to an individual who got spammed,
and
even if he is awarded damages, the cost of collection is too high. The
small,
obscure, ISPs are no longer the problem. It's all too easy to cut off
the
small guys, and as a result they've been getting quite good at corrective
and
preventative measures. The worst offenders these days are the large
ISPs, who
simply do not care. The spammers know this.
The only way to make the large ISPs care would be if they are hit with a
class
action lawsuit. But that's unlikely to happen until we have some clearer
legislation.
Received: from ietf.org by ietf.org id aa26868; 17 Mar 97 14:48 EST
Received: from mwunix.mitre.org by ietf.org id aa26727; 17 Mar 97 14:45 EST
Received: from geeeffpee.mitre.org (geeeffpee.mitre.org [128.29.222.237])
by mwunix.mitre.org (8.8.5/8.8.4/mitre.0) with SMTP
id OAA17310 for <ietf at ietf.org>; Mon, 17 Mar 1997 14:42:15 -0500 (EST)
Received: by geeeffpee.mitre.org with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC32E1.3B6841D0 at geeeffpee.mitre.org>; Mon, 17 Mar 1997 14:41:00 -0500
Message-ID: <c=US%a=_%p=The_MITRE_Corpor%l=GEEEFFPEE-970317194059Z-163 at geeeffpee.mitre.org>
Sender:ietf-request at ietf.org
From: "Blythe, Thomas G." <blythe at geeeffpee.mitre.org>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Up-to-date RFC site?
Date: Mon, 17 Mar 1997 14:40:59 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Is there an up-to-date, reliable, web site providing current status of
RFCs in the standards track? I just visited the RFC Editor page
(http://www.isi.edu/rfc-editor/status.html) which states that it was
last modified in June 1996. Are OSPF v2 and POP 3 really still draft
standards and HTML 2 still a Proposed Standard?
Gary
----------------------------------------------------------------------
| Gary Blythe | Email : blythe at mitre.org
|
| The MITRE Corporation |
|
| 145 Wyckoff Rd. | Phone : (908) 389-6789
|
| Eatontown, NJ 07724 | Fax : (908) 544-8317
|
----------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa26873; 17 Mar 97 14:48 EST
Received: from cs.columbia.edu by ietf.org id aa26711; 17 Mar 97 14:45 EST
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA24407; Mon, 17 Mar 1997 14:40:59 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id OAA19186; Mon, 17 Mar 1997 14:40:53 -0500 (EST)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <332D9E45.783E at cs.columbia.edu>
Date: Mon, 17 Mar 1997 14:40:53 -0500
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Dave Roberts <dave.roberts at zeitnet.com>
CC: ietf <ietf at ietf.org>
Subject: Re: a new email infrastructure, comm. label fraud
References: <332D97D0 at smtpgw.zeitnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
As long as the perp resides in or visits the US (or countries with
similar laws), it doesn't matter whether he sent the spam (or porn) from
Albania (assuming they still have a working telephone line...) in order
to be prosecuted. With advertisements, it is likely that somebody
identifiable, likely in the US, wants to profit from these spams - you'd
drag him into court, not the ISP in Albania that distributed the spam.
Note also that many European countries have much stricter laws that, for
example, prohibit 'unsolicited commercial phone calls' for residences.
Received: from ietf.org by ietf.org id aa28197; 17 Mar 97 15:08 EST
Received: from cornpuffs.cisco.com by ietf.org id aa28127; 17 Mar 97 15:06 EST
Received: (dhaval at localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id MAA03316; Mon, 17 Mar 1997 12:03:16 -0800
Sender:ietf-request at ietf.org
From: Dhaval Shah <dhaval at cisco.com>
Message-Id: <199703172003.MAA03316 at cornpuffs.cisco.com>
Subject: Re: Up-to-date RFC site?
To: "Blythe Thomas G." <blythe at geeeffpee.mitre.org>
Date: Mon, 17 Mar 1997 12:03:15 -0800 (PST)
Cc: ietf at ietf.org
In-Reply-To: <c=US%a=_%p=The_MITRE_Corpor%l=GEEEFFPEE-970317194059Z-163 at geeeffpee.mitre.org> from "Blythe, Thomas G." at Mar 17, 97 02:40:59 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 897
Source-Info: From (or Sender) name not authenticated.
>
> Is there an up-to-date, reliable, web site providing current status of
> RFCs in the standards track? I just visited the RFC Editor page
You may want to try :
http://ds.internic.net/ds/dspg1intdoc.html
Dhaval
> (http://www.isi.edu/rfc-editor/status.html) which states that it was
> last modified in June 1996. Are OSPF v2 and POP 3 really still draft
> standards and HTML 2 still a Proposed Standard?
>
> Gary
>
> ----------------------------------------------------------------------
>
> | Gary Blythe | Email : blythe at mitre.org
> |
> | The MITRE Corporation |
> |
> | 145 Wyckoff Rd. | Phone : (908) 389-6789
> |
> | Eatontown, NJ 07724 | Fax : (908) 544-8317
> |
> ----------------------------------------------------------------------
>
>
>
>
Received: from ietf.org by ietf.org id aa29653; 17 Mar 97 15:28 EST
Received: from callandor.cybercash.com by ietf.org id aa29338;
17 Mar 97 15:24 EST
Received: by callandor.cybercash.com; id PAA20496; Mon, 17 Mar 1997 15:14:47 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma020448; Mon, 17 Mar 97 15:14:23 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA24331; Mon, 17 Mar 97 15:17:43 EST
Date: Mon, 17 Mar 1997 15:17:43 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: "Blythe, Thomas G." <blythe at geeeffpee.mitre.org>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Re: Up-to-date RFC site?
In-Reply-To: <c=US%a=_%p=The_MITRE_Corpor%l=GEEEFFPEE-970317194059Z-163 at geeeffpee.mitre.org>
Message-Id: <Pine.SUN.3.91.970317151423.23426B-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
The latest status RFC is RFC 2000 and pending items and recent protocol
actions are available via http://www.ietf.org/iesg.html. Assuming the recent
protocol actions pages is kept around until the next summarizing RFC comes
out, these items together would provide what you want.
Donald
On Mon, 17 Mar 1997, Blythe, Thomas G. wrote:
> Date: Mon, 17 Mar 1997 14:40:59 -0500
> From: Blythe, Thomas G. <blythe at geeeffpee.mitre.org>
> To: "'ietf at ietf.org'" <ietf at ietf.org>
> Subject: Up-to-date RFC site?
>
> Is there an up-to-date, reliable, web site providing current status of
> RFCs in the standards track? I just visited the RFC Editor page
> (http://www.isi.edu/rfc-editor/status.html) which states that it was
> last modified in June 1996. Are OSPF v2 and POP 3 really still draft
> standards and HTML 2 still a Proposed Standard?
>
> Gary
>
> ----------------------------------------------------------------------
>
> | Gary Blythe | Email : blythe at mitre.org
> |
> | The MITRE Corporation |
> |
> | 145 Wyckoff Rd. | Phone : (908) 389-6789
> |
> | Eatontown, NJ 07724 | Fax : (908) 544-8317
> |
> ----------------------------------------------------------------------
>
>
>
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa29652; 17 Mar 97 15:28 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa29554;
17 Mar 97 15:26 EST
Received: from Ikkoku-Kan.Panda.COM (groves at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id MAA01612; Mon, 17 Mar 1997 12:23:46 -0800 (PST)
Received: from localhost (gnof at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id MAA03465; Mon, 17 Mar 1997 12:23:43 -0800 (PST)
Date: Mon, 17 Mar 1997 11:18:43 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: RE: a new email infrastructure, comm. label fraud
To: Dave Roberts <dave.roberts at zeitnet.com>
cc: ietf <ietf at ietf.org>
In-Reply-To: <332D97D0 at smtpgw.zeitnet.com>
Message-ID: <MailManager.858626323.392.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 97 11:13:00 PST, Dave Roberts wrote:
> The issue is, who decides
> what is and isn't acceptable,
The recipient; if it is sent unsolicited, and if it offends the recipient, it
is unacceptable.
This is a matter of private property rights. UCE and telephone solicitation
are no different from the solicitor at the front door who wishes to hawk his
wares or conjure according to his favorite superstition. All are trespassing.
> and how do you hold a service provider
> liable for the actions of its subscribers.
The ISP profited from the actions of that subscriber. If the ISP incurs
liability from the actions of that subscriber, then recovery of those losses
is between the ISP and its subscriber.
It's unlikely that an ISP will be able to recover the loss without the
customer's signature on an Acceptable Use Policy. ISPs will also probably
find themselves obliged to expend some effort in measures to detect, stop, and
limit the impact of abuse when it happens. My heart bleeds.
> The first is an issue of
> censorship, plain and simple.
One thing that has not dawned on a number of individuals is that "freedom of"
includes "freedom from". It is not censorship when the recipient does not
want the material.
> The second issue is of assigning liability
> to the actual wrongdoers, not to those who are simply providing a service
> which can be used for either good or evil ;-).
The large ISPs have gone beyond this point; they are openly harboring the
wrongdoers. This places them in the same category as the wrongdoers.
> This idea of holding the ISP somehow responsible is
> equivalent to holding AT&T responsible for the actions of telephone
> solicitors or General Motors responsible for the actions of bank robbers
> that drive Chevy getaway cars.
True for the former but not for the latter.
In the case of the former, AT&T resources are used. Yes, I do want AT&T held
accountable for how its owned resources are used to invade my privacy, since
it profits by the sale of access to my private residence.
In the case of the latter, GM transfers title to the vehicle to the purchaser,
and has no further ownership claim. Even in the case of a lease, title is
transferred to the leasing company by the manufacturer.
Received: from ietf.org by ietf.org id aa29757; 17 Mar 97 15:29 EST
Received: from apprentice.qualcomm.com by ietf.org id aa29699;
17 Mar 97 15:29 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA28707; Mon, 17 Mar 1997 12:25:50 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03102004af53462feb80 at [129.46.166.223]>
In-Reply-To: <199703140524.VAA22666 at servo.qualcomm.com>
References: <v03101f00af4dde06451b at [165.227.249.100]> (message from Paul
Hoffman on Thu, 13 Mar 1997 08:53:30 -0800)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1fc32-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Mon, 17 Mar 1997 11:59:33 -0800
To: Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: call for a new email infrastructure
Cc: paulh at imc.org, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 9:24 PM -0800 3/13/97, Phil Karn wrote:
>
>Let's give the technical approaches a serious go before we give up.
Exactly so.
Regardless of our personal definition of spam, we must preserve the ability
for people to send unsolicited and anonymous messages. There are
legitimate applications for them. Any attempt to define spam legally will
ultimately rest on some logical absurdity. Applying the definition will
always be gratuitous and arbitrary for some group.
When we've exhausted possible solutions that are independent of the message
content, then perhaps it is time for new social conventions, new laws.
=46or now, I still see a long road to walk before I'm ready for that.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
Setting out on the voyage to Ithaca
you must pray that the way be long,
full of adventures and experiences.
-- C.P. Cavavy, "Ithaca", 1911
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa02041; 17 Mar 97 16:11 EST
Received: from callandor.cybercash.com by ietf.org id aa01799;
17 Mar 97 16:08 EST
Received: by callandor.cybercash.com; id PAA25243; Mon, 17 Mar 1997 15:58:27 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma025186; Mon, 17 Mar 97 15:58:04 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA25650; Mon, 17 Mar 97 16:01:24 EST
Date: Mon, 17 Mar 1997 16:01:23 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Danger Will Robinson! S/N ratio approaching zero!
In-Reply-To: <QQchgt28911.199703171456 at rodan.UU.NET>
Message-Id: <Pine.SUN.3.91.970317122232.19228B-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997, Louis A. Mamakos wrote:
> Date: Mon, 17 Mar 1997 09:56:34 -0500
> From: Louis A. Mamakos <louie at uu.net>
>
> How about we designate some of the IETF meeting registration fees to
> fund someone to moderate an IETF mailing list, to be used for the transaction
> of IETF business? We could advance the state of the art, and insist
> that all submissions be privacy enhanced, or maybe just signed. Perhaps
> some of the domain registration fees set aside to enhance the Internet
> infrastructure might be used for such a purpose?
IETF meeting costs are subsidized by the US government. They have not been
surplus producing events. However I would have been happy if ISOC dues had
stayed at $70 per years instead of being cut to $35 and the additional
collected used for this and similar purposes.
It would be pretty expensive to have human moderation but that isn't an
excuse not to do simple technical things like only allowing posts from list
members, confirming subscritions via an mail loop (I assume this is being
done now), etc. It would have to be phased in over time but I think it would
be reasonable to require all submissions to be digitally signed starting some
months from now and some months after that, start actually checking the
signatures.
The NSI fees that have been set aside are basicly owned by the NSF and it
would appear that government gridlock will stop those funds from being spent
by anyone for anything anytime soon.
> Between conference announcements, requests for papers, educating people
> how Internet mailing lists have worked for the last decade, and helpful
> offers on how to make a lot 'o money, it's tough to find the occasional
> message involved in some meta-discussion related to the IETF.
I believe that all conference announcements and requests for papers appearing
on the IETF list are spam unless the event is an IETF or ISOC event. The
ACM, IEEE, etc. all maintain their own event announcement lists where those
who wish to be emailed can sign up. (They also maintain web pages, which is
a fine non-intrusive way to advertise.)
> Alternatively, we might rely on IETF-ANNOUNCE to warn us of upcoming
> meetings and hotel room shortages, and conduct business only on the
> working group mailing lists. I fear that this list has been mentioned
> in a few too many articles in the press and is no longer useful for it's
> original purpose.
It would still needed for the IETF Last Call if nothing else.
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa04342; 17 Mar 97 16:33 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa04016;
17 Mar 97 16:31 EST
Received: from Ikkoku-Kan.Panda.COM (jms at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id NAA01707; Mon, 17 Mar 1997 13:28:10 -0800 (PST)
Received: from localhost (jim at localhost [127.0.0.1]) by Ikkoku-Kan.Panda.COM id NAA03675; Mon, 17 Mar 1997 13:28:06 -0800 (PST)
Date: Mon, 17 Mar 1997 13:12:53 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: call for a new email infrastructure
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: Phil Karn <karn at qualcomm.com>, paulh at imc.org, ietf at ietf.org
In-Reply-To: <v03102004af53462feb80 at [129.46.166.223]>
Message-ID: <MailManager.858633173.392.mrc at Ikkoku-Kan.Panda.COM>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997 11:59:33 -0800, John W. Noerenberg wrote:
> Regardless of our personal definition of spam, we must preserve the ability
> for people to send unsolicited and anonymous messages.
Why?
> There are legitimate applications for them.
Please offer substantiation for this statement.
What legitimate application is there to send unsolicited and anonymous
messages to an unwilling recipient?
What legitimate application is there to expend communications bandwidth that
is paid by an unwilling recipient?
What legitimate application is there to use privately-owned facilities of an
unwilling recipient?
Received: from ietf.org by ietf.org id aa05166; 17 Mar 97 16:44 EST
Received: from rome.zeitnet.com by ietf.org id aa05043; 17 Mar 97 16:43 EST
Received: from smtpgw.zeitnet.com by zeitnet.com (8.6.12/SMI-4.1)
id NAA22628; Mon, 17 Mar 1997 13:40:07 -0800
Received: by smtpgw.zeitnet.com with Microsoft Mail
id <332DB9B7 at smtpgw.zeitnet.com>; Mon, 17 Mar 97 13:37:59 PST
Sender:ietf-request at ietf.org
From: Dave Roberts <dave.roberts at zeitnet.com>
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Cc: ietf <ietf at ietf.org>
Subject: RE: a new email infrastructure, comm. label fraud
Date: Mon, 17 Mar 97 13:37:00 PST
Message-ID: <332DB9B7 at smtpgw.zeitnet.com>
Encoding: 27 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
Agreed. My using Europe was simply a quick grab for a non-US region, not
meant to imply that Europeans are more lax about this sort of thing than
anyone else. The basic point was simply that, given a global network, the
location to commit a crime using that network quickly shifts to the
region with the most lenient law enforcement and without a global
agreement on the regulation and enforcement of the network, there is no
real hope of punishment.
-- Dave
----------
From: Henning Schulzrinne
Sent: Monday, March 17, 1997 2:40 PM
To: Dave Roberts
Cc: ietf
Subject: Re: a new email infrastructure, comm. label fraud
As long as the perp resides in or visits the US (or countries with
similar laws), it doesn't matter whether he sent the spam (or porn) from
Albania (assuming they still have a working telephone line...) in order
to be prosecuted. With advertisements, it is likely that somebody
identifiable, likely in the US, wants to profit from these spams - you'd
drag him into court, not the ISP in Albania that distributed the spam.
Note also that many European countries have much stricter laws that, for
example, prohibit 'unsolicited commercial phone calls' for residences.
Received: from ietf.org by ietf.org id aa06443; 17 Mar 97 17:02 EST
Received: from egoshin.genesyslab.com by ietf.org id aa06325;
17 Mar 97 17:01 EST
Received: (from egoshin at localhost) by egoshin.genesyslab.com (8.8.5/8.6.9) id NAA10663; Mon, 17 Mar 1997 13:58:37 -0800
Date: Mon, 17 Mar 1997 13:58:37 -0800
Sender:ietf-request at ietf.org
From: Leonid Yegoshin <egoshin at genesyslab.com>
Message-Id: <199703172158.NAA10663 at egoshin.genesyslab.com>
To: jed at webstart.com, kent at songbird.com
Subject: Re: a new email infrastructure, comm. label fraud
Cc: ietf at ietf.org, karn at qualcomm.com, paulh at imc.org
Source-Info: From (or Sender) name not authenticated.
>From: "James E. [Jed] Donnelley" <jed at webstart.com>
>
>Even if it had an authenticated sender, how would that help?
>If there was no disincentive to send it, people sending SPAM
>would have no particular concern being clear about who
>they are. Except perhaps for the concern now about being blasted
>by people who don't like getting the SPAM. I actually think
>that such deliberate harrasment should be illegal, but that
>is another story.
>
>2. As for filtering, if one wants to be open for unsolicited
>mail (e.g. from a long lost friend) then it seems to me that
>SPAM can be made to look like such mail to just about any level
>of "intelligent filtering." I think that doing so would
Logic error in two previous paragraph - if "it had an authenticated
sender" then "SPAM can _NOT_ made to look like such mail" and filtering
is possible.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa06557; 17 Mar 97 17:02 EST
Received: from aquila.ece.utexas.edu by ietf.org id aa06441; 17 Mar 97 17:01 EST
Received: from brando.ece.utexas.edu (snekkant at brando.ece.utexas.edu [128.83.59.201]) by aquila.ece.utexas.edu (8.7.5/8.7.3) with ESMTP id QAA52450; Mon, 17 Mar 1997 16:00:52 -0600
Received: from localhost (snekkant at localhost) by brando.ece.utexas.edu (8.7.5/8.7.3) with SMTP id QAA16243; Mon, 17 Mar 1997 16:00:45 -0600 (CST)
X-Authentication-Warning: brando.ece.utexas.edu: snekkant owned process doing -bs
Date: Mon, 17 Mar 1997 16:00:44 -0600 (CST)
Sender:ietf-request at ietf.org
From: Shantharam Nekkanti <snekkant at ece.utexas.edu>
To: Mark Crispin <MRC at panda.com>
cc: Dave Roberts <dave.roberts at zeitnet.com>, ietf <ietf at ietf.org>
Subject: unsubsribe
In-Reply-To: <MailManager.858626323.392.mrc at Ikkoku-Kan.Panda.COM>
Message-ID: <Pine.SOL.3.93.970317155940.27649A-100000 at brando.ece.utexas.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
please remove my name from all the mailing lists
Received: from ietf.org by ietf.org id aa06940; 17 Mar 97 17:06 EST
Received: from songbird.com by ietf.org id aa06848; 17 Mar 97 17:05 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id OAA14751; Mon, 17 Mar 1997 14:01:19 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703172201.OAA14751 at songbird.com>
Subject: Re: a new email infrastructure, comm. label fraud
To: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Date: Mon, 17 Mar 1997 14:01:19 -0800 (PST)
Cc: dave.roberts at zeitnet.com, ietf at ietf.org
In-Reply-To: <332D9E45.783E at cs.columbia.edu> from "Henning Schulzrinne" at Mar 17, 97 02:40:53 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Henning Schulzrinne allegedly said:
>
> As long as the perp resides in or visits the US (or countries with
> similar laws), it doesn't matter whether he sent the spam (or porn) from
> Albania (assuming they still have a working telephone line...) in order
> to be prosecuted. With advertisements, it is likely that somebody
> identifiable, likely in the US, wants to profit from these spams - you'd
> drag him into court, not the ISP in Albania that distributed the spam.
> Note also that many European countries have much stricter laws that, for
> example, prohibit 'unsolicited commercial phone calls' for residences.
Technology is available to allow anonymous transactions. Remailers
allow an individual or business to completely conceal themselves on
the net. Given that, your legal argument is vacuous.
Well, you say, let us make anonymity illegal. That, IMHO, would be a
decidedly bad idea, only a shade less bad than making privacy
illegal.
There is a lot of technology waiting to be built -- I would rather
explore that a lot further, before we call in the feds.
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html
Received: from ietf.org by ietf.org id aa08905; 17 Mar 97 17:21 EST
Received: from cs.columbia.edu by ietf.org id aa08677; 17 Mar 97 17:20 EST
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id RAA29326; Mon, 17 Mar 1997 17:17:14 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with SMTP id RAA19412; Mon, 17 Mar 1997 17:17:10 -0500 (EST)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <332DC2E5.4C3D at cs.columbia.edu>
Date: Mon, 17 Mar 1997 17:17:09 -0500
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Kent Crispin <kent at songbird.com>
CC: ietf at ietf.org
Subject: Re: a new email infrastructure, comm. label fraud
References: <199703172201.OAA14751 at songbird.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Yes, you can send anonymous advertisements. Except when they offer
weapons-grade plutonium, how likely would anybody respond to that kind
of ad? Kind of defeats the purpose of advertising... As I said before,
it doesn't matter who sent the mail, it matters who benefits and who, in
many cases, can't stay anon. to gain any economic benefit from the spam.
Won't cure the whole disease, but will get the MLM types out of my
mailbox.
Nobody has demonstrated a technical solution that is practical (i.e.,
doesn't prevent me receiving mail from people I haven't met before and
who may or may not sign their email).
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from ietf.org by ietf.org id aa09754; 17 Mar 97 17:34 EST
Received: from rome.zeitnet.com by ietf.org id aa09474; 17 Mar 97 17:31 EST
Received: from smtpgw.zeitnet.com by zeitnet.com (8.6.12/SMI-4.1)
id OAA22859; Mon, 17 Mar 1997 14:28:31 -0800
Received: by smtpgw.zeitnet.com with Microsoft Mail
id <332DC50E at smtpgw.zeitnet.com>; Mon, 17 Mar 97 14:26:22 PST
Sender:ietf-request at ietf.org
From: Dave Roberts <dave.roberts at zeitnet.com>
To: Dave Roberts <dave.roberts at zeitnet.com>, Mark Crispin <MRC at panda.com>
Cc: ietf <ietf at ietf.org>
Subject: RE: a new email infrastructure, comm. label fraud
Date: Mon, 17 Mar 97 14:25:00 PST
Message-ID: <332DC50E at smtpgw.zeitnet.com>
Encoding: 119 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
Mark Crispin wrote:
On Mon, 17 Mar 97 11:13:00 PST, Dave Roberts wrote:
> The issue is, who decides
> what is and isn't acceptable,
The recipient; if it is sent unsolicited, and if it offends the
recipient, it
is unacceptable.
This is a matter of private property rights. UCE and telephone
solicitation
are no different from the solicitor at the front door who wishes to hawk
his
wares or conjure according to his favorite superstition. All are
trespassing.
If the recipient decides, then the recipient should have the job of
filtering, not the ISP. As an ISP, I could hardly read your mind and know
what you might find acceptable or not, even if the source was "obviously"
a spammer. Heck, some of your text above might apply to my in-laws. :-)
> and how do you hold a service provider
> liable for the actions of its subscribers.
The ISP profited from the actions of that subscriber. If the ISP incurs
liability from the actions of that subscriber, then recovery of those
losses
is between the ISP and its subscriber.
It's unlikely that an ISP will be able to recover the loss without the
customer's signature on an Acceptable Use Policy. ISPs will also
probably
find themselves obliged to expend some effort in measures to detect,
stop, and
limit the impact of abuse when it happens. My heart bleeds.
This is nonsensical to me. The ISP is in the bit tranport business. The
ISP profited in so much as the ISP moved bits from here to there and was
paid for it. That a "crime" (if we really want to elevate this to that
level) was committed is no more the ISPs fault than the US Postal
Service's for carrying Unabomber packages. Note that the US Postal
Service also benefited from the Unabomber's mailings. Should they be
allowed to be sued by the Unabombers victims? I do think so...
> The first is an issue of
> censorship, plain and simple.
One thing that has not dawned on a number of individuals is that "freedom
of"
includes "freedom from". It is not censorship when the recipient does
not
want the material.
Hmmm... again, I'm not arguing for SPAM. I hate getting it just like the
next guy. But it seems like censorship to me if anybody but myself does
the filtering. I actually don't want my ISP to censor messages that I
might find offensive. Why should I think that their filter is so good?
Would I find the, "You have just won the $1,000,000 lottery award" email
offensive? Do I really want them "reading" (whether automatically or not)
my messages and deciding what is good or not? Even if I provide them with
a profile of my likes and dislikes, would they be liable if they deleted
my lottery notice, above, because it matched my dislike profile? I guess
what I'm saying is, I hear you, but I don't see a workable way to make
what you want happen.
> The second issue is of assigning liability
> to the actual wrongdoers, not to those who are simply providing a
service
> which can be used for either good or evil ;-).
The large ISPs have gone beyond this point; they are openly harboring the
wrongdoers. This places them in the same category as the wrongdoers.
One man's garbage is another's gold mine. What you find unacceptable is
probably acceptable to someone. Obviously, they must be getting some
people answering all those SPAM adverts. If not, I'd presume that they
would stop.
> This idea of holding the ISP somehow responsible is
> equivalent to holding AT&T responsible for the actions of telephone
> solicitors or General Motors responsible for the actions of bank
robbers
> that drive Chevy getaway cars.
True for the former but not for the latter.
In the case of the former, AT&T resources are used. Yes, I do want AT&T
held
accountable for how its owned resources are used to invade my privacy,
since
it profits by the sale of access to my private residence.
If you don't want people to call you because they offend you, disconnect
your phone, or at least don't answer it.
Actually, think of it the other way around and it might help. How would
you like to call AT&T to speak with someone to find out if your content
was acceptable to your mother before you were connected? What if they
declined to connect you because they felt your content would someone be
objectionable to your mom or otherwise invade her privacy?
In the case of the latter, GM transfers title to the vehicle to the
purchaser,
and has no further ownership claim. Even in the case of a lease, title
is
transferred to the leasing company by the manufacturer.
Fair enough. Then, how about the US Postal Service analogy? Should the
USPS be liable for the Unabomber's actions? If so, do you really want
them reading your mail, just so nobody sends you a bomb?
Anyhow, like others on this list, I think we can do a lot better with
technology at the receiver end before we start holding ISPs liable for
some spammer somewhere.
-- Dave
Received: from ietf.org by ietf.org id aa10862; 17 Mar 97 17:49 EST
Received: from tomobiki-cho.cac.washington.edu by ietf.org id aa10645;
17 Mar 97 17:48 EST
Received: from Ikkoku-Kan.Panda.COM (longo at UW-Gateway.Panda.COM [192.107.14.65]) by Tomobiki-Cho.CAC.Washington.EDU id OAA01827; Mon, 17 Mar 1997 14:46:01 -0800 (PST)
Received: from Ikkoku-Kan.Panda.COM (mrc at localhost) by Ikkoku-Kan.Panda.COM id OAA03944; Mon, 17 Mar 1997 14:45:58 -0800 (PST)
Date: Mon, 17 Mar 1997 14:45:56 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <mrc at panda.com>
To: Dave Roberts <dave.roberts at zeitnet.com>
cc: ietf <ietf at ietf.org>
Subject: RE: a new email infrastructure, comm. label fraud
In-Reply-To: <332DC50E at smtpgw.zeitnet.com>
Message-ID: <Pine.NXT.4.00.970317143348.3873B-100000 at Ikkoku-Kan.Panda.COM>
Organization: Pandamonium Reigns
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997, Dave Roberts wrote:
> If the recipient decides, then the recipient should have the job of
> filtering, not the ISP. As an ISP, I could hardly read your mind and know
> what you might find acceptable or not, even if the source was "obviously"
> a spammer. Heck, some of your text above might apply to my in-laws. :-)
A cute argument, but it doesn't fly.
Unlike the postal service, you charge your customers not only to send
material, but also to receive it. You therefore have a moral obligation
to your customer to comply with your customers' wishes with regards to the
material. Your customer is paying for it.
I want to make that a legal obligation as well, just as the telephone
companies are starting to be compelled to maintain "no call" lists and
solicitors are being compelled to consult such lists before calling.
Just consider it the cost of your business.
> This is nonsensical to me. The ISP is in the bit tranport business. The
> ISP profited in so much as the ISP moved bits from here to there and was
> paid for it. That a "crime" (if we really want to elevate this to that
> level) was committed is no more the ISPs fault than the US Postal
> Service's for carrying Unabomber packages. Note that the US Postal
> Service also benefited from the Unabomber's mailings. Should they be
> allowed to be sued by the Unabombers victims? I do think so...
The difference is that the recipient of postal mail does not pay for it.
You can be sure that Congress would quickly ban all forms of junk postal
mail if receipients had to pay for postal mail the way email recipients
pay now.
> Hmmm... again, I'm not arguing for SPAM. I hate getting it just like the
> next guy. But it seems like censorship to me if anybody but myself does
> the filtering.
Not if the other guy gets instructions from me of the form:
no anonymous mail
no unsolicited advertising
and execute my specific instructions.
What this means is that anonymous mail must be labelled as anonymous, and
that unsolicited advertising must be labelled as unsolicited advertising,
and there should be severe punitive civil sanctions against failure to
label.
> One man's garbage is another's gold mine. What you find unacceptable is
> probably acceptable to someone. Obviously, they must be getting some
> people answering all those SPAM adverts. If not, I'd presume that they
> would stop.
I doubt it. I suspect that these spammers do it because they *think*
there may be a return; or more likely that they know that there is no
return, but have tricked advertisers who don't know any better into buying
their services.
> If you don't want people to call you because they offend you, disconnect
> your phone, or at least don't answer it.
I have Caller ID and Anonymous Call Rejection. "Out of Area" calls are
answered by a robot. Anyone who has something important to say will
either properly identify himself, will use postal mail, or in an emergency
would ask the telephone company operator to put the call through.
> Actually, think of it the other way around and it might help. How would
> you like to call AT&T to speak with someone to find out if your content
> was acceptable to your mother before you were connected? What if they
> declined to connect you because they felt your content would someone be
> objectionable to your mom or otherwise invade her privacy?
Calls from my mother would be properly identified.
> Fair enough. Then, how about the US Postal Service analogy? Should the
> USPS be liable for the Unabomber's actions?
If and when the USPS starts charging me to recieve postal mail, yes.
-- Mark --
Unsolicited commercial email is NOT welcome at this email address.
Received: from cnri by ietf.org id aa12330; 17 Mar 97 18:11 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24503;
17 Mar 97 18:12 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA06120 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 21:26:27 GMT
Message-Id: <332DC75B.4C1E at unikix.com>
Date: Mon, 17 Mar 1997 14:36:11 -0800
From: John Jones <j.jones at unikix.com>
Reply-To: j.jones at unikix.com
Organization: UniKix Technologies
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: [Fwd: Re: GSS-API and SSL - their coexistence, and related issues]
Content-Type: multipart/mixed; boundary="------------49636A255FCB"
Precedence: bulk
This is a multi-part message in MIME format.
--------------49636A255FCB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
What about the more complex SET protocol in which the data is intended
for two independent entities but routed via one of the entities.
Different pieces of the data being encoded under different secrets
derived from different certs and multiply signed. This surely can only
be done at the application level.
> From: Bill Buffam <bjb at trsvr.tr.unisys.com>
>
> Okay, here's some real flame bait: <soapbox> I regard user level
> authentication provided by IPSEC as a monumental kludge. It says to the
> application layer "never mind this pretty layered structure, just assume
> what's underneath and drive it." Application protocols should work over
> any protocol stack - that's what the layered structure is all about.
> This whole idea really pollutes the cleanliness of the layers. As
> Abraham Maslow said, "When the only tool you have is a hammer,
> everything looks like a nail." I could go on at length, but I won't.
> </soapbox>
You mean you believe that any form of application-layer security
is a monumental kludge?
If the application is security-aware, and requests security services
using some API (say for example GSS-API, or some sockopt-based API),
then why should the application know or care how those services are
provided? The actual transport protection could in theory be provided
anywhere in the stack, from layer 1 on up. And (again, in theory) each
layer could have a well-defined interface to the adjacent layers so
that the session-layer module, having received a request for a secure
connection for a particular user, could either set it up using the
(misnamed) TLS protocol, or merely maintain a mapping between the
session/user ID and an SPI and rely on IPSEC to do the data transforms.
The application doesn't have to know whether the data is protected
by AH/ESP or by TLS Record Layer, it just knows that it's getting a
specified Quality of Protection.
Of course no current implementations are designed to do clean layering,
(this is, after all, the I-Q&D-ETF :-), but there is no architectural
reason that they couldn't be.
--------------49636A255FCB
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from webserver.unikix.com ([208.145.185.180]) by mailserver (AIX4.2/UCB 8.7/8.7) with SMTP id HAA12036 for <john at warp_core.unikix.com>; Mon, 17 Mar 1997 07:19:58 -0700 (MST)
Received: from h-205-217-233-39.netscape.com by webserver.unikix.com (AIX 4.1/UCB 5.64/4.03)
id AA12090; Mon, 17 Mar 1997 07:29:45 -0700
Received: (from list at localhost) by glacier.mcom.com (8.7.3/8.7.3) id GAA28577; Mon, 17 Mar 1997 06:22:25 -0800 (PST)
Resent-Date: Mon, 17 Mar 1997 06:22:25 -0800 (PST)
Date: Mon, 17 Mar 1997 09:19:24 -0500
From: dpkemp at missi.ncsc.mil (David P. Kemp)
Message-Id: <199703171419.JAA03121 at argon.ncsc.mil>
To: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
X-Sun-Charset: US-ASCII
Resent-Message-Id: <"43clb3.0.Pz6.-CLBp"@glacier>
Resent-From: ssl-talk at netscape.com
X-Mailing-List: <ssl-talk at netscape.com> archive/latest/4227
X-Loop: ssl-talk at netscape.com
Precedence: list
Resent-Sender: ssl-talk-request at netscape.com
> From: Bill Buffam <bjb at trsvr.tr.unisys.com>
>
> Okay, here's some real flame bait: <soapbox> I regard user level
> authentication provided by IPSEC as a monumental kludge. It says to the
> application layer "never mind this pretty layered structure, just assume
> what's underneath and drive it." Application protocols should work over
> any protocol stack - that's what the layered structure is all about.
> This whole idea really pollutes the cleanliness of the layers. As
> Abraham Maslow said, "When the only tool you have is a hammer,
> everything looks like a nail." I could go on at length, but I won't.
> </soapbox>
You mean you believe that any form of application-layer security
is a monumental kludge?
If the application is security-aware, and requests security services
using some API (say for example GSS-API, or some sockopt-based API),
then why should the application know or care how those services are
provided? The actual transport protection could in theory be provided
anywhere in the stack, from layer 1 on up. And (again, in theory) each
layer could have a well-defined interface to the adjacent layers so
that the session-layer module, having received a request for a secure
connection for a particular user, could either set it up using the
(misnamed) TLS protocol, or merely maintain a mapping between the
session/user ID and an SPI and rely on IPSEC to do the data transforms.
The application doesn't have to know whether the data is protected
by AH/ESP or by TLS Record Layer, it just knows that it's getting a
specified Quality of Protection.
Of course no current implementations are designed to do clean layering,
(this is, after all, the I-Q&D-ETF :-), but there is no architectural
reason that they couldn't be.
--------------49636A255FCB--
Received: from ietf.org by ietf.org id aa12374; 17 Mar 97 18:12 EST
Received: from songbird.com by ietf.org id aa12216; 17 Mar 97 18:11 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id PAA15244; Mon, 17 Mar 1997 15:06:43 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703172306.PAA15244 at songbird.com>
Subject: Re: call for a new email infrastructure
To: Mark Crispin <MRC at panda.com>
Date: Mon, 17 Mar 1997 15:06:43 -0800 (PST)
Cc: jwn2 at qualcomm.com, karn at qualcomm.com, paulh at imc.org, ietf at ietf.org
In-Reply-To: <MailManager.858633173.392.mrc at Ikkoku-Kan.Panda.COM> from "Mark Crispin" at Mar 17, 97 01:12:53 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Mark Crispin allegedly said:
>
> On Mon, 17 Mar 1997 11:59:33 -0800, John W. Noerenberg wrote:
> > Regardless of our personal definition of spam, we must preserve the ability
> > for people to send unsolicited and anonymous messages.
>
> Why?
>
> > There are legitimate applications for them.
>
> Please offer substantiation for this statement.
The good examples are political, not economic.
> What legitimate application is there to send unsolicited and anonymous
> messages to an unwilling recipient?
None, but there is no way to know who is unwilling and who isn't,
beforehand, so the example is vacuous. The question is What
legitimate application is there to send unsolicited and anonymous
messages. Period.
And for that there are all kinds of possibilities. The usual reason
for anonymous messages is fear of retaliation...
> What legitimate application is there to expend communications bandwidth that
> is paid by an unwilling recipient?
The issue is the implied contract of connecting to the net. When you
connected to the net you damn well agreed to accept unsolicited
messages -- just as when you signed on to a mailing list and posted
messages about email infrastructure you implicitly agree to receive
*this* message, even though a significant percentage of the members
of this list think your messages and my messages are unsolicited junk.
> What legitimate application is there to use privately-owned facilities of an
> unwilling recipient?
There is no "unwilling recipient" -- by connecting to a communication
channel you implicitly signal your willingness to receive whatever
comes down that channel. Since you don't own the net, your decision
to hook up to it constitutes an agreement to accept what it sends you.
If you don't like it you are perfectly free to take your business
elsewhere ;-)
In particular, you are perfectly free to take your business to an ISP
that filters spam.
Of course, you are also free to lobby to get your particular views
institutionalized in the legal system, and I am free to lobby against
them.
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html
Received: from ietf.org by ietf.org id aa13557; 17 Mar 97 18:26 EST
Received: from rome.zeitnet.com by ietf.org id aa13350; 17 Mar 97 18:25 EST
Received: from smtpgw.zeitnet.com by zeitnet.com (8.6.12/SMI-4.1)
id PAA23091; Mon, 17 Mar 1997 15:22:25 -0800
Received: by smtpgw.zeitnet.com with Microsoft Mail
id <332DD1B0 at smtpgw.zeitnet.com>; Mon, 17 Mar 97 15:20:16 PST
Sender:ietf-request at ietf.org
From: Dave Roberts <dave.roberts at zeitnet.com>
To: Mark Crispin <mrc at panda.com>
Cc: ietf <ietf at ietf.org>
Subject: RE: a new email infrastructure, comm. label fraud
Date: Mon, 17 Mar 97 15:20:00 PST
Message-ID: <332DD1B0 at smtpgw.zeitnet.com>
Encoding: 39 TEXT
X-Mailer: Microsoft Mail V3.0
Source-Info: From (or Sender) name not authenticated.
Okay, now this is both doable and probably appropriate. The issue I have
is what happens if the solicitor doesn't consult the list? What if they
just call you anyway? According to what I thought you wrote previously,
you would be able to sue the phone company...? If so, that's bogus.
In short, I'm not against having the phone company or ISP help me out in
protecting my privacy, but
1. I don't want anybody reading my mail or filtering based on supposed
content.
2. I don't think the ISP or telco should be held responsible when it
can't reasonably protect me anyway (that is, when protection would force
rule 1 to be violated). (BTW, which ISP would you hold responsible? You
own ISP? The spammer's ISP? The ones in the middle that carried the
spam?)
The question with this one is, who keeps the master "don't-want-no-spam"
list? I suppose you could create a convention/standard that sending an
email to "no-spam at domain.tld" would send you back a complete no-spam
list. Before sending unsolicited email into that domain, you would be
required to retrieve the list and adhere to its filtering. Failure to do
so would be subject to fine, etc. Hmmm... is actually just what AOL and
Compuserve, etc., would probably love to see.
Again, in this case, hold the violator responsible, not any ISP. Come to
think of it, with this model, the ISP couldn't be responsible unless it
had a domain name under which people could register for email service. In
other words, your domain = your responsibility for providing your own
filter list. Simply providing the list and maintaining it would absolve
you from any liability.
-- Dave
----------
I want to make that a legal obligation as well, just as the telephone
companies are starting to be compelled to maintain "no call" lists and
solicitors are being compelled to consult such lists before calling.
Just consider it the cost of your business.
Received: from ietf.org by ietf.org id aa15373; 17 Mar 97 18:42 EST
Received: from dumbcat.codewright.com by ietf.org id aa15187;
17 Mar 97 18:39 EST
Return-Path: <marc at dumbcat.codewright.com>
Received: from localhost.codewright.com by dumbcat.codewright.com (4.1/smail-24May90)
id AA16516; Mon, 17 Mar 97 15:36:33 PST
To: ietf <ietf at ietf.org>
Subject: Re: a new email infrastructure, comm. label fraud
In-Reply-To: Your message of "Mon, 17 Mar 1997 14:45:56 PST."
<Pine.NXT.4.00.970317143348.3873B-100000 at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Mar 1997 15:36:32 -0800
Message-Id: <16514.858641792 at dumbcat.codewright.com>
Sender:ietf-request at ietf.org
From: Marco S Hyman <marc at dumbcat.codewright.com>
Source-Info: From (or Sender) name not authenticated.
Mark Crispin writes:
> Unlike the postal service, you charge your customers not only to send
> material, but also to receive it. You therefore have a moral obligation
> to your customer to comply with your customers' wishes with regards to the
> material. Your customer is paying for it.
The only thing I expect -- no demand -- of my ISP is to deliver packets
to my router and accept packets from my router. I do NOT want my ISP
looking at the content of those packets unless addressed to the ISp.
I may sometimes even encrypt the payload to ensure privacy.
> The difference is that the recipient of postal mail does not pay for it.
> You can be sure that Congress would quickly ban all forms of junk postal
> mail if receipients had to pay for postal mail the way email recipients
> pay now.
I do not pay for mail, I pay for bandwidth. I accept that some of that
bandwidth is going to be wasted by UCE -- its the price I pay for local
control of that bandwidth. Local control is MUCH more important than
having to hit the d(elete) key in my mailer three or four times a day.
// marc
Received: from ietf.org by ietf.org id aa16720; 17 Mar 97 19:05 EST
Received: from songbird.com by ietf.org id aa16666; 17 Mar 97 19:04 EST
Received: (from kent at localhost) by songbird.com (8.8.3/8.7.3) id PAA15615; Mon, 17 Mar 1997 15:59:55 -0800
Sender:ietf-request at ietf.org
From: Kent Crispin <kent at songbird.com>
Message-Id: <199703172359.PAA15615 at songbird.com>
Subject: Re: a new email infrastructure, comm. label fraud
To: Mark Crispin <mrc at panda.com>
Date: Mon, 17 Mar 1997 15:59:55 -0800 (PST)
Cc: dave.roberts at zeitnet.com, ietf at ietf.org
In-Reply-To: <Pine.NXT.4.00.970317143348.3873B-100000 at Ikkoku-Kan.Panda.COM> from "Mark Crispin" at Mar 17, 97 02:45:56 pm
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Mark Crispin allegedly said:
>
> On Mon, 17 Mar 1997, Dave Roberts wrote:
> > If the recipient decides, then the recipient should have the job of
> > filtering, not the ISP. As an ISP, I could hardly read your mind and know
> > what you might find acceptable or not, even if the source was "obviously"
> > a spammer. Heck, some of your text above might apply to my in-laws. :-)
>
> A cute argument, but it doesn't fly.
>
> Unlike the postal service, you charge your customers not only to send
> material, but also to receive it. You therefore have a moral obligation
> to your customer to comply with your customers' wishes with regards to the
> material. Your customer is paying for it.
No such moral obligation exists. You can write a contract that
states your "moral obligation" and see if your ISP will sign it.
They won't, because they have no way of knowing what is unsolicited
and what is anonymous.
OTOH, you might get one to filter unauthenticated email, at an
additional cost.
> I want to make that a legal obligation as well, just as the telephone
> companies are starting to be compelled to maintain "no call" lists and
> solicitors are being compelled to consult such lists before calling.
>
> Just consider it the cost of your business.
Just as meaningful to say that you should consider it a cost of
connecting to the net.
[...]
> The difference is that the recipient of postal mail does not pay for it.
> You can be sure that Congress would quickly ban all forms of junk postal
> mail if receipients had to pay for postal mail the way email recipients
> pay now.
Not necessarily. Even with the post office other solutions are
possible. We all know that junk mail subsidizes first class postage
-- the USPS could offer a delivery service that would filter bulk
mailings, and charge you for it.
> > Hmmm... again, I'm not arguing for SPAM. I hate getting it just like the
> > next guy. But it seems like censorship to me if anybody but myself does
> > the filtering.
>
> Not if the other guy gets instructions from me of the form:
> no anonymous mail
> no unsolicited advertising
> and execute my specific instructions.
>
> What this means is that anonymous mail must be labelled as anonymous,
Authenticating mailers would be nice, yes -- that doesn't require any
legislation, just a technical infrastructure...
> and
> that unsolicited advertising must be labelled as unsolicited advertising,
> and there should be severe punitive civil sanctions against failure to
> label.
If you only accept authenticated messages, it would be easy for you
or your ISP to filter out bulk mailers.
> > One man's garbage is another's gold mine. What you find unacceptable is
> > probably acceptable to someone. Obviously, they must be getting some
> > people answering all those SPAM adverts. If not, I'd presume that they
> > would stop.
>
> I doubt it. I suspect that these spammers do it because they *think*
> there may be a return; or more likely that they know that there is no
> return, but have tricked advertisers who don't know any better into buying
> their services.
In which case the error of their ways will become clear over time,
and legislation will be unnecessary.
[...]
>
> > Fair enough. Then, how about the US Postal Service analogy? Should the
> > USPS be liable for the Unabomber's actions?
>
> If and when the USPS starts charging me to recieve postal mail, yes.
Once again, it depends on what service you pay for -- if you pay for
bomb-filtered mail, then of course you should be able to sue. That
would be a fairly expensive option, I imagine...
--
Kent Crispin "No reason to get excited",
kent at songbird.com,kc at llnl.gov the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html
Received: from ietf.org by ietf.org id aa18199; 17 Mar 97 19:31 EST
Received: from cnri by ietf.org id aa18130; 17 Mar 97 19:30 EST
Received: from soglio.Colorado.EDU by CNRI.Reston.VA.US id aa26069;
17 Mar 97 19:30 EST
Received: from [128.138.200.95] (ecemac-citrin.Colorado.EDU [128.138.200.95]) by soglio.Colorado.EDU (8.6.9/8.6.9/UnixOps) with ESMTP id RAA02433; Mon, 17 Mar 1997 17:20:33 -0700
X-Sender: citrin at soglio.colorado.edu
Message-Id: <v03007801af539e6dbcce at [128.138.200.95]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Mar 1997 17:21:55 -0800
To: BM-List1 at cs.ucdavis.edu, cellular at dfv.rwth-aachen.edu,
cnom at maestro.bellcore.com, comsoc.bog at tab.ieee.org,
comsoc.tac at tab.ieee.org, comsoc-gicb at ieee.org, comsoc-tcii at ieee.com,
commsoft at cc.bellcore.com, comswtc at gmu.edu,
cost237-transport at comp.lancs.ac.uk, ctc-members at redbank.tinac.com,
dbworld <@bbn.com:dbworld at cs.wisc.eduenternet>,
gcomlist1 at manjaro.ece.iit.edu, giga at tele.pitt.edu,
hipparch at sophia.inria.fr, ieee_rtc_list at cs.tamu.edu,
ieeetcpc at ccvm.sunysb.edu, ietf at CNRI.Reston.VA.US, isadsoc at fokus.gmd.de,
itc at fokus.gmd.de, modern-heuristics at uk.ac.mailbase.ucdavis.edu,
multicomm at cc.bellcore.com, osimcast at bbn.com, prs at masi.ibp.fr,
reres at laas.fr, sc6wg4 at ntd.comsat.com, sigmedia at bellcore.com,
tccc at cs.umass.edu, testnet at canarie.ca, xtp-relay at cs.concordia.ca
Sender:ietf-request at ietf.org
From: Wayne Citrin <citrin at cs.colorado.edu>
Subject: CFP: ACM MULTIMEDIA '97 -- Seattle, November 8-14, 1997
Source-Info: From (or Sender) name not authenticated.
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES!
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Call For Participation Call For Participation
=--=--=--=--=--=--=--= =--=--=--=--=--=--=--=
ACM MULTIMEDIA'97
The 5th ACM International Multimedia Conference
=--=--=--=--=--=--=--=--==--=--=--=--=--=--=--=
November 8-14, 1997
Crowne Plaza Hotel, Seattle
=--=--=--=--=--=--=--=--==--=--=--=--=--=--=--=
Sponsored by ACM SIGMM,
SIGCOMM, SIGGRAPH, SIGLINK and SIGMIS
In Cooperation With
SIGBIT, SIGCHI, SIGIR and SIGOIS
(tentative lists)
FOR THE MOST UP-TO-DATE INFORMATION, PLEASE CONSULT OUR WEB PAGES:
http://www.acm.org/sigmm/MM97 http://www.uni-mannheim.de/acm97
ACM's annual MULTIMEDIA conference is the premier forum where researchers
and developers from academia and industry around the world can meet to
exchange ideas and report on new developments relating to all aspects of
multimedia technology and systems. The world of computing continues to
reinvent itself. Just as we previously witnessed a dramatic transformation
from textual to visual computing, we are now in the midst of an exciting
metamorphosis to an era of multimodal computing whose ultimate shape is as
yet unknown. The conference scope spans technology, tools and techniques
for the construction and delivery of high quality, innovative multimedia
systems and interfaces.
We are especially striving this year to achieve balance in coverage within
the technical program, between issues relating to underlying system design
and delivery - e.g.,
--hardware and architectures
--networking and communications
--compression and synchronization
--databases and information retrieval
--collaboration environments
--digital libraries
and issues relating to the human-computer interface - e.g.,
--hot application domains
--document models and authoring tools
--scalable and translucent interfaces
--interactive audio documents
--alternate modality systems
--virtual realities
We cordially invite -YOU- to take part in this exciting event by submitting
your work in one or more of the ways enumerated below, and look forward to
welcoming -YOU- to Seattle this fall for what will be a most rewarding and
exciting experience!
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
ALL SUBMISSIONS MUST BE RECEIVED no later than TUESDAY, JUNE 3, 1997!
See below for submission categories and addresses
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
TECHNICAL PAPERS of the high quality expected at major ACM conferences
are solicited. These may fall into a variety of categories:
(a) Presentation of original and significant research.
(b) Results of relevant and rigorous empirical studies.
(c) Description of the `look and feel' and discussion of the
internal workings of an implemented system.
Papers must be set in 11-point type and formatted in two-column conference
style, and may not exceed 12 pages in length including all figures, tables,
and references. An award will be given for the best paper, as judged by
the program committee. Papers with a student as the primary author will
separately enter a student paper award competition; a cover letter must
identify your paper as a candidate for the student paper competition, if
applicable. All authors are encouraged to send a short video with their
paper if possible, to clarify and reinforce the concepts discussed - but
acceptance will be based primarily on the written paper itself.
Authors of accepted papers will be required to prepare an electronic
version for the on-line conference proceedings, which will supplement
the traditional printed volume. Authors must assign copyright to ACM as
a condition of publishing their work in the proceedings. An author who
embeds an object, such as an art image, copyrighted by a third party is
expected to obtain that party's permission to include the object with the
understanding that the entire work may be distributed as a unity to ACM
members and others.
All submissions -must- be received no later than Tuesday, June 3, 1997
(this is a firm deadline). Send 8 copies of full papers to the Program
Chair:
James D. Hollan
Computer Science Department
University of New Mexico
Albuquerque, NM 87131
E-mail: hollan at cs.unm.edu
Tel. (505) 277 3112
Fax: (505) 277 6927
Authors will be notified regarding acceptance on or around July 6, and
will be required to return the revised camera-ready copy, the electronic
version, and a completed registration form (at least one per paper), by
August 10.
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
PANEL PROPOSALS up to 3 pages in length on timely and controversial
topics are also welcome. These submissions should be formatted like a
technical paper, and if accepted will be included in the conference
proceedings. They should include:
(a) An introduction by the organizer/moderator.
(b) Position statements from each panelist.
(c) Brief biographical sketches of all participants.
Send 4 copies of panel proposals to the Panels Chair:
Takayuki Dan Kimura
Computer Science Department
Washington University
St. Louis, MO 63130
E-mail: tdk at cs.wustl.edu
Tel. (314) 935 6122
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
TWO DAYS OF IN-DEPTH COURSES by leading experts will precede the technical
program and enhance its value for both novice and seasoned professional
alike. The full- and half-day offerings will span a wide variety of topics,
so that there is something for everybody. Course organizers receive an
honorarium which can be used, for example, to defray part of the cost of
attending the conference. We invite you to take advantage of this excellent
opportunity!
Proposals to organize/present a course at ACM MULTIMEDIA'97 should be 3-4
pages long, to include the following information in the order shown:
(a) Cover page:
o Name and affiliation of the proposer/organizer.
o Course title.
o Preferred duration (full day or half day).
o Level (introductory, intermediate, or advanced).
o Names and affiliations of additional speakers, if any.
o Intended audience.
o Course abstract/overview - what will attendees learn?
o A/V aids to be used in the presentation.
(b) Detailed course description and outline (1-2 pages); if more
than one presenter, who will cover each topic/section?
(c) Biographical sketch of each speaker (one paragraph apiece), to
include: current research interests; important publications,
projects and/or awards (as appropriate); and courses previously
presented at other conferences.
Send 4 copies of course proposals to the Courses Chair:
Margaret Burnett
Computer Science Department
Oregon State University .
Corvallis, Oregon 97331 .
E-mail: burnett at cs.orst.edu
Tel. (541) 737 2539
Fax: (541) 737 3014
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
DAY-LONG WORKSHOPS on topics of great current interest to members of the
multimedia research community will both precede and follow the technical
program. Participation is by invitation only, under the control of the
individual organizer(s), but all workshop organizers and attendees are
expected to register for the conference as well, to foster a symbiotic
relationship among participants.
If you'd like to take advantage of this venue to conduct -YOUR- workshop,
please contact the Workshops Chair:
Stephen Itoga
319 Keller Hall / ICS
University of Hawaii
2565 The Mall
Honolulu, HI 96822
E-mail: itoga at hawaii.edu
Tel. (808) 956 3500
Fax: (808) 956 3548
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
STATE OF THE ART DEMOS will form an integral and important part of the
MULTIMEDIA'97 experience. This year, we want to focus on systems in which
technical innovation is combined with artistic wizardry. We're not 100%
sure what that means, but we'll bet -YOU- know! Amazing research prototypes
and stunning commercial products are welcome. There are just 2 constraints:
we can supply only limited equipment and certainly nothing exotic, so if
you need really special hardware you'll have to supply your own; and space
is limited, so all proposals for demos will be referreed to assure quality.
If you'd like to propose a technically-oriented demo, please contact:
Bikash Sabata
Telecommunications and Distributed Processing Program
SRI International
333 Ravenswood Ave.
Menlo Park, CA 94025
E-mail: sabata at erg.sri.com
Tel. (415) 859 2281
If you'd like to propose an artistically-oriented demo, please contact:
Tim Skelly
Design Happy
26715 NE 50th Street
Redmond, WA 98053
E-mail: TimSkelly at aol.com
Tel. (206) 868 2822
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
QUESTIONS?? Please feel free to contact the General Chair:
Ephraim P. Glinert
Department of Computer Science
Rensselaer Polytechnic Institute
Troy, NY 12180
E-mail: glinert at cs.rpi.edu
Tel. (518) 276 2657
Fax: (518) 276 4033
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
THE ACM MULTIMEDIA'97 ORGANIZING COMMITTEE
Steering Committee Chairs:
--=--=--=--=--=--=--=--=--
Steve Bulick, U S West Advanced Technologies
Allan Kuchinsky, Hewlett Packard Laboratories
General Co-Chairs:
-=--=--=--=--=--=-
Ephraim P. Glinert, Rensselaer Polytechnic Institute
Mark Scott Johnson, vivid studios
Program Co-Chairs:
-=--=--=--=--=--=-
James D. Hollan, University of New Mexico
James D. Foley, MERL
Program Committee Associate Chairs:
--=--=--=--=--=--==--=--=--=--=--=--
Bob Allen, Bellcore
Dick Bulterman, CWI
Isabel Cruz, Tufts University
Takaya Endo, NTT-AT
Thomas Erickson, Apple Computer
Bill Grosky, Wayne State University
Patrick Hanrahan, Stanford University
Jonathan Helfman, AT&T Research
Jessica Hodgins, Georgia Institute of Technology
Philipp Hoschka, INRIA-W3C
Hiroshi Ishii, MIT Media Laboratory
David Kirsh, University of California at San Diego
Michael Lesk, Bellcore
Wendy MacKay, CENA and University of Paris-Sud
Ryohei Nakatsu, ATR Media Integration & Communication Research Labs
Ken Perlin, New York University
Lawrence Rowe, University of California at Berkeley
Steve Roth, Carnegie Mellon University
Brian Smith, Cornell University
Akikazu Takeuchi, Sony Corporation
Alex Weibel, Carnegie Mellon University
Kent Wittenburg, GTE Laboratories
Ramin Zabih, Cornell University
Hong-Jiang Zhang, Hewlett Packard Laboratories
Panels Chair:
--=--=--=--=--
Takayuki Dan Kimura, Washington University
Courses Chair:
--=--=--=--=--
Margaret Burnett, Oregon State University
Workshops Chair:
=--=--=--=--=--=
Stephen Itoga, University of Hawaii
Art Demos Chair:
=--=--=--=--=--=
Tim Skelly, Design Happy
Technical Demos Chair:
=--=--=--=--=--=--=--=
Bikash Sabata, SRI International
Student Volunteers Chair:
=--=--=--=--=--=--=--=--=
Alvin T. Moser, Seattle University
Print Proceedings Chair:
-=--=--=--=--=--=--=--=-
Hong-Jiang Zhang, Hewlett Packard Laboratories
Electronic Proceedings Chair:
=--=--=--=--=--=--=--=--=--=
Lars Wolf, Technical University of Darmstadt
Publicity Chair:
=--=--=--=--=--=
Wayne Citrin, University of Colorado at Boulder
Webmaster:
=--=--=--=
Stephan Fischer, University of Mannheim
Treasurer:
=--=--=--=
John Buford, University of Massachusetts at Lowell
Received: from ietf.org by ietf.org id aa20066; 17 Mar 97 20:03 EST
Received: from apprentice.qualcomm.com by ietf.org id aa19995;
17 Mar 97 20:01 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id QAA18059; Mon, 17 Mar 1997 16:50:06 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03102005af538db3b93d at [129.46.166.223]>
In-Reply-To: <MailManager.858633173.392.mrc at Ikkoku-Kan.Panda.COM>
References: <v03102004af53462feb80 at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1fc32-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Mon, 17 Mar 1997 16:28:43 -0800
To: Mark Crispin <MRC at panda.com>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: call for a new email infrastructure
Cc: Phil Karn <karn at qualcomm.com>, paulh at imc.org, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 1:12 PM -0800 3/17/97, Mark Crispin wrote:
>On Mon, 17 Mar 1997 11:59:33 -0800, John W. Noerenberg wrote:
>> Regardless of our personal definition of spam, we must preserve the abili=
ty
>> for people to send unsolicited and anonymous messages.
>
>Why?
Someone who fears the consequences of being identified with a particular
message should be able to protect themselves. If the Internet had been
available at the time of the American Revolution, for example, pamphlets
published by John Adams, James Madison, etc could have been published more
safely anonymously instead of under pseudonyms. I'm sure you can think of
other, more current examples.
>
>> There are legitimate applications for them.
>
>Please offer substantiation for this statement.
Advertising, like it or not, is a legitimate application for an unsolicited
message. If advertising is not allowed on the net, how do you expect
sellers to find new customers? Word of mouth may be a powerful tool, but
no businessman would rely on one tool alone to reach his potential audience.
>
>What legitimate application is there to send unsolicited and anonymous
>messages to an unwilling recipient?
Indeed, why must an unwilling recepient receive these messages? I don't
claim he must. I only claim it must be possible for the sender to send
them. If a receiver is willing to make an a priori judgement that certain
kinds of messages can be discarded without presentation to him. That can
be done.
>
>What legitimate application is there to expend communications bandwidth tha=
t
>is paid by an unwilling recipient?
If the messages are discarded before presentation to the receiver, what
bandwidth has been used and paid for? (other than the 1-time cost to post
his a priori judgement)
>
>What legitimate application is there to use privately-owned facilities of a=
n
>unwilling recipient?
What privately owned facilities are we talking about? The ISP's or the
receiver's?
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from cnri by ietf.org id aa20435; 17 Mar 97 20:10 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26699;
17 Mar 97 20:10 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <XAA10389 at pad-thai.cam.ov.com>; Mon, 17 Mar 1997 23:11:20 GMT
Message-Id: <332DCF78.77DC at trsvr.tr.unisys.com>
Date: Mon, 17 Mar 1997 18:10:49 -0500
From: Bill Buffam <bjb at trsvr.tr.unisys.com>
Reply-To: bjb at trsvr.tr.unisys.com
Organization: Unisys
X-Mailer: Mozilla 3.0Gold (WinNT; I)
Mime-Version: 1.0
To: "David P. Kemp" <dpkemp at missi.ncsc.mil>
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: GSS-API and SSL - their coexistence, and related issues
References: <199703171419.JAA03121 at argon.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
David P. Kemp wrote:
> If the application is security-aware, and requests security services
> using some API (say for example GSS-API, or some sockopt-based API),
> then why should the application know or care how those services are
> provided? The actual transport protection could in theory be provided
> anywhere in the stack, from layer 1 on up. And (again, in theory) each
> layer could have a well-defined interface to the adjacent layers so
> that the session-layer module, having received a request for a secure
> connection for a particular user, could either set it up using the
> (misnamed) TLS protocol, or merely maintain a mapping between the
> session/user ID and an SPI and rely on IPSEC to do the data transforms.
> The application doesn't have to know whether the data is protected
> by AH/ESP or by TLS Record Layer, it just knows that it's getting a
> specified Quality of Protection.
>
I agree with everything you say. What I was calling a kludge was some of
the functionality described in RFC 1825 sections 4.4 and 4.6. The way I
interpret it, this material implies that the application is invited, by
implementation dependent means, to involve itself with the key
distribution mechanism of IPSEC. Granted, doing this addresses some
stated application level security vulnerabilities, if the only security
mechanism in use is IPSEC. However, the proper way to address those
vulnerabilities, IMO, is by applying the security at the application
level itself, not by involving the application in managing the (assumed
present) IPSEC layer.
--
Bill Buffam
Unisys, Malvern PA
bjb at trsvr.tr.unisys.com
Received: from ietf.org by ietf.org id aa21293; 17 Mar 97 20:31 EST
Received: from ormail.intel.com by ietf.org id aa21239; 17 Mar 97 20:29 EST
Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3])
by ormail.intel.com (8.8.4/8.8.4) with SMTP
id RAA13642 for <ietf at ietf.org>; Mon, 17 Mar 1997 17:26:45 -0800 (PST)
Received: from generic.jf.intel.com by ibeam.intel.com with smtp
(Smail3.1.28.1 #6) id m0w6njL-000RTIC; Mon, 17 Mar 97 17:30 PST
Received: by generic.jf.intel.com with Microsoft Mail
id <01BC32F8.5CE63440 at generic.jf.intel.com>; Mon, 17 Mar 1997 17:26:35 -0800
Message-ID: <01BC32F8.5CE63440 at generic.jf.intel.com>
Sender:ietf-request at ietf.org
From: "John J. Kilfoil" <jk at ibeam.jf.intel.com>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Yet another off-topic IETF mail message!
Date: Mon, 17 Mar 1997 17:26:30 -0800
Encoding: 31 TEXT
Source-Info: From (or Sender) name not authenticated.
Greetings,
I represent Intel at the IETF as part of my job. As a result, I *need* to
subscribe to the IETF mailing lists. A lot of the recent e-mail messages
addressed to the IETF at large have been interesting, but off topic (read
'SPAM'). And while they may provoke thought and stir interesting debate, is anything
really being accomplished? Beyond generating lots of other off topic e-mail,
probably not. I would argue that merely having what you consider
to be a new, different, brilliant, etc. insight is not reason enough to burden
the IETF subscribers. In my opinion, most of the recent off-topic messages would be
more suitable for submission to a relevant discussion in a news group.
A simple request...Before adding your two cents to an off-topic message, please
consider the purpose of the IETF mailing lists and what if anything sending
your e-mail message will really accomplish in the IETF. If your purpose is
merely to inform, why not submit your thoughts to an appropriate news
discussion group?
Thanks for your attention and consideration.
Flames to the bit bucket.
Respectfully,
John Kilfoil
Systems Manageability Group
Intel Platform Architecture Lab
--
My opinions are my own and do not necessarily represent the position of
Intel, the Platform Architecture Lab, or the Systems Manageability group.
Received: from ietf.org by ietf.org id aa22385; 17 Mar 97 20:53 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa22293; 17 Mar 97 20:51 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id UAA06988; Mon, 17 Mar 1997 20:48:14 -0500 (EST)
Message-Id: <199703180148.UAA06988 at ig.cs.utk.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: moore at cs.utk.edu, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 17 Mar 1997 16:28:43 PST."
<v03102005af538db3b93d at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 17 Mar 1997 20:48:14 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> >Please offer substantiation for this statement.
>
> Advertising, like it or not, is a legitimate application for an unsolicited
> message. If advertising is not allowed on the net, how do you expect
> sellers to find new customers? Word of mouth may be a powerful tool, but
> no businessman would rely on one tool alone to reach his potential audience.
I agree that it's very difficult to define spam in such a way that the
definition does not include some kinds of desirable speech. But
saying that advertising is a legitimate purpose for unsolicted mail is
sort of like saying I have the right to walk into J. Random Person's
house and piss on the floor just because I need to take a leak.
(After all, it only takes a few seconds for JRP to clean it up, and he
probably only has to clean no more than a few puddles a day, and
urination, even more than commerce, is essential to the proper
functioning of human society.)
Just as there are more sanitary and less offensive methods of
elimination, there are also far better means for businessmen to "reach
out and touch someone" on the net, than with spam.
Keith
Received: from ietf.org by ietf.org id aa24372; 17 Mar 97 21:36 EST
Received: from ecsis.ecsis.net by ietf.org id aa24247; 17 Mar 97 21:34 EST
Received: from ecsis.ecsis.net by ecsis.ecsis.net with smtp
(Smail3.1.29.1 #3) id m0w6ofK-0009IoC; Mon, 17 Mar 97 20:30 CST
Message-Id: <m0w6ofK-0009IoC at ecsis.ecsis.net>
Sender:ietf-request at ietf.org
From: "Larry E. Smith" <lesmith at ecsis.net>
To: ietf at ietf.org
MMDF-Warning: Parse error in original version of preceding line at ietf.org
Subject: Re: a new email infrastructure, comm. label fraud
Date: Mon, 17 Mar 1997 20:29:00 -0600
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Marco,
In your note you state:
> I do not pay for mail, I pay for bandwidth
which is great for you, but many people who still pay hourly
access fees might argue that point when it takes serval minutes
to even half-hours to download mail only to find much of it
"spam" or the proverbial "junk" mail. And worse yet, many
people (systems) still have "quota" based mail systems or even
charge for email "by the message" so to speak.
==========================================
= Larry E. Smith + Love Your Neighbor
= SysAd ECSIS.NET + But
= lesmith at ecsis.net + Don't cut down your Hedge!
==========================================
Received: from ietf.org by ietf.org id aa24373; 17 Mar 97 21:36 EST
Received: from nacho.cisco.com by ietf.org id aa24315; 17 Mar 97 21:35 EST
Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id SAA03523; Mon, 17 Mar 1997 18:32:54 -0800
Received: from [171.69.128.116] ([171.69.128.116]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id SAA02810; Mon, 17 Mar 1997 18:32:53 -0800
X-Sender: fred at stilton.cisco.com
Message-Id: <v0300780eaf537586e218 at [171.69.128.116]>
In-Reply-To: <QQchgt28911.199703171456 at rodan.UU.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Mar 1997 14:26:28 -0800
To: "Louis A. Mamakos" <louie at uu.net>
Sender:ietf-request at ietf.org
From: Fred Baker <fred at cisco.com>
Subject: Re: Danger Will Robinson! S/N ratio approaching zero!
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 9:56 AM -0500 3/17/97, Louis A. Mamakos wrote:
>Alternatively, we might rely on IETF-ANNOUNCE to warn us of upcoming
>meetings and hotel room shortages, and conduct business only on the
>working group mailing lists. I fear that this list has been mentioned
>in a few too many articles in the press and is no longer useful for it's
>original purpose.
I've been doing that for a while...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It has recently been discovered that research causes cancer in rats.
Received: from ietf.org by ietf.org id aa26829; 17 Mar 97 22:22 EST
Received: from apprentice.qualcomm.com by ietf.org id aa26720;
17 Mar 97 22:19 EST
Received: from [129.46.166.223] (jnoerenberg-mac.qualcomm.com [129.46.166.223]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id TAA05384; Mon, 17 Mar 1997 19:15:24 -0800 (PST)
X-Sender: jwn2 at mage.qualcomm.com
Message-Id: <v03102006af53b102054c at [129.46.166.223]>
In-Reply-To: <199703180148.UAA06988 at ig.cs.utk.edu>
References: Your message of "Mon, 17 Mar 1997 16:28:43 PST."
<v03102005af538db3b93d at [129.46.166.223]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Eudora [Macintosh version 3.1fc32-3.97]
X-PGP-Fingerprint: EA 53 01 A6 C0 76 F9 C2 09 E8 94 80 64 5A 88 57
Date: Mon, 17 Mar 1997 19:09:32 -0800
To: Keith Moore <moore at cs.utk.edu>
Sender:ietf-request at ietf.org
From: "John W. Noerenberg" <jwn2 at qualcomm.com>
Subject: Re: call for a new email infrastructure
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 8:48 PM -0500 3/17/97, Keith Moore wrote:
>> >Please offer substantiation for this statement.
>>
>> Advertising, like it or not, is a legitimate application for an unsolicit=
ed
>> message. If advertising is not allowed on the net, how do you expect
>> sellers to find new customers? Word of mouth may be a powerful tool, but
>> no businessman would rely on one tool alone to reach his potential audien=
ce.
>
>I agree that it's very difficult to define spam in such a way that the
>definition does not include some kinds of desirable speech.
Not difficult, impossible.
And it's out of scope.
We are arguing about whether this content is acceptable or that content is
acceptable. And that is wrong. Restricting the flow of information should
not be the job of information technologists.
I applaud Mark Crispin for giving the matter some thought and proposing an
idea, despite the fact I disagree with his idea.
john noerenberg
jwn2 at qualcomm.com
--------------------------------------------------------------------
She discovered, as many a living being had discovered, that
rational decisions are far more easily made than carried out.
-- Orson Scott Card, Speaker for the Dead, 1986
--------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa05047; 17 Mar 97 23:37 EST
Received: from jekyll.piermont.com by ietf.org id aa04932; 17 Mar 97 23:33 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.5/8.6.12) with SMTP id XAA11515; Mon, 17 Mar 1997 23:28:14 -0500 (EST)
Message-Id: <199703180428.XAA11515 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: Mark Crispin <MRC at panda.com>, paulh at imc.org, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 17 Mar 1997 16:28:43 PST."
<v03102005af538db3b93d at [129.46.166.223]>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 17 Mar 1997 23:28:12 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
"John W. Noerenberg" writes:
> At 1:12 PM -0800 3/17/97, Mark Crispin wrote:
> >On Mon, 17 Mar 1997 11:59:33 -0800, John W. Noerenberg wrote:
> >> Regardless of our personal definition of spam, we must preserve the abili=
> ty
> >> for people to send unsolicited and anonymous messages.
> >
> >Why?
>
> Someone who fears the consequences of being identified with a particular
> message should be able to protect themselves. If the Internet had been
> available at the time of the American Revolution, for example, pamphlets
> published by John Adams, James Madison, etc could have been published more
> safely anonymously instead of under pseudonyms. I'm sure you can think of
> other, more current examples.
Indeed.
I must say that I have no trouble with anonymous or pseudonymous
messages. I do, however, have a problem with messages with
deliberately forged return addresses designed to misdirect reply
mail. I think a distinction may be drawn between these.
Perry
Received: from ietf.org by ietf.org id aa05372; 17 Mar 97 23:38 EST
Received: from ns.jck.com by ietf.org id aa05239; 17 Mar 97 23:38 EST
Received: from tp7.Jck.com ("port 4464"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E77ZLYCM00OAL at a4.jck.com>
for ietf at ietf.org; Mon, 17 Mar 1997 22:41:58 -0500 (EST)
Date: Mon, 17 Mar 1997 22:41:56 -0500 (EST)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: a new email infrastructure, comm. label fraud
In-reply-to: <199703172359.PAA15615 at songbird.com>
To: Kent Crispin <kent at songbird.com>
Cc: dave.roberts at zeitnet.com, ietf at ietf.org, Mark Crispin <mrc at panda.com>
Message-id: <SIMEON.9703172256.B at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1b1 Build (5)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997 15:59:55 -0800 (PST) Kent Crispin
<kent at songbird.com> wrote:
> > I want to make that a legal obligation as well, just as the telephone
> > companies are starting to be compelled to maintain "no call" lists and
> > solicitors are being compelled to consult such lists before calling.
> >
> > Just consider it the cost of your business.
>
> Just as meaningful to say that you should consider it a cost of
> connecting to the net.
Ok. This position is actually a horse of a slightly
different color. There are several organizations out there
(notably the Direct Marketing Assn) which are trying very
hard to get themselves into the business of maintaining
"opt out" lists for the Internet and of applying strong
pressures on those who mail things to get the "opt out"
lists and use them to filter email address lists before
sending out ads. They think this can be done effectively
without legislation; while reasonable people might differ
about that, it is a strategy.
Now, the thing that makes that sort of model important is
that it shifts the burden of not sending to particular
addresses to the sender (and not to the receiver, the
transit ISP, etc.). Whether an opt-out model is good
enough is another question, especially in an environment in
which it is suspected that some spammers have used "remove"
commands to form lists of people who read all their email
and respond to it.
john
Received: from ietf.org by ietf.org id aa05379; 17 Mar 97 23:38 EST
Received: from ns.jck.com by ietf.org id aa05245; 17 Mar 97 23:38 EST
Received: from tp7.Jck.com ("port 4463"@tp7.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E77Z6BC800OAL at a4.jck.com>
for ietf at ietf.org; Mon, 17 Mar 1997 22:32:35 -0500 (EST)
Date: Mon, 17 Mar 1997 22:32:33 -0500 (EST)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: call for a new email infrastructure
In-reply-to: <v03102005af538db3b93d at [129.46.166.223]>
X-Orig-Sender: klensin at mci.net
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
Cc: Phil Karn <karn at qualcomm.com>, paulh at imc.org, ietf at ietf.org,
Mark Crispin <MRC at panda.com>
Message-id: <SIMEON.9703172233.A at tp7.Jck.com>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1b1 Build (5)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997 16:28:43 -0800 "John W. Noerenberg"
<jwn2 at qualcomm.com> wrote:
> >What legitimate application is there to expend communications bandwidth that
> >is paid by an unwilling recipient?
>
> If the messages are discarded before presentation to the receiver, what
> bandwidth has been used and paid for? (other than the 1-time cost to post
> his a priori judgement)
John,
Regardless of the other issues here, it seems to me that
the above statement is true iff the message is stopped at
the originating server. If it has to transit the network
to arrive at the target's maildrop before being discarded,
resources have been consumed (and, ultimately, someone is
paying for them). If it is deposited in the maildrop, not
only are the transit costs incurred, but disk space is
taken up, and, again, sooner or later, someone pays. And
if it has to be downloaded to the target's machine before
being filtered to the bitbucket, additional network
resources and disk resources are used. And, under the
right circumstances, any of these uses of resources can
turn into a denial of service situation, even if
inadvertent. Not only is there no such thing as a free
lunch, there aren't even free appetizers -- fewer and fewer
ISPs are run as public charities these days.
john
Received: from ietf.org by ietf.org id aa05382; 17 Mar 97 23:38 EST
Received: from ns.jck.com by ietf.org id aa05263; 17 Mar 97 23:38 EST
Received: from white-box.jck.com ("port 1985"@white-box.jck.com)
by a4.jck.com (PMDF V5.1-8 #21705) with SMTP id <0E71DFS1E0039Z at a4.jck.com>
for ietf at ietf.org; Fri, 14 Mar 1997 08:57:28 -0500 (EST)
Date: Fri, 14 Mar 1997 08:57:27 -0500 (EST)
Sender:ietf-request at ietf.org
From: John C Klensin <klensin at mci.net>
Subject: Re: Authenticated Mail
In-reply-to: <Pine.SGI.3.95.970314011806.841A-100000 at shellx.best.com>
To: Walter Ian Kaye <walter at natural-innovations.com>
Cc: ietf at ietf.org
Message-id: <SIMEON.9703140827.F at white-box.mci.net>
MIME-version: 1.0
X-Mailer: Simeon for Windows Version 4.1.1b1 Build (5)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL
X-Authentication: none
Source-Info: From (or Sender) name not authenticated.
On Fri, 14 Mar 1997 01:28:39 -0800 (PST) Walter Ian Kaye
<walter at natural-innovations.com> wrote:
> It would also be a great help if mail arriving bcc'd would indicate which
> email address it came in under. When I receive spam, I have no way of knowing
> whether it came via my ISP account/domain or via one of my custom domain name
> addresses. Thus, I don't even know what name to ask to have removed!
Discuss it with your MTA supplier or find another one. It is
trivial for an MTA to incorporate this information into the
message if it wants to. On the other hand, it is almost
impossible to write a protocol that specifies the behavior
since the behavior of copying the final RCPT TO from the
envelope into the message headers or body is not observable on
the wire.
john
Received: from cnri by ietf.org id aa07764; 18 Mar 97 0:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa01330;
18 Mar 97 0:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <DAA19951 at pad-thai.cam.ov.com>; Tue, 18 Mar 1997 03:25:31 GMT
Date: Mon, 17 Mar 1997 22:25:27 -0500
Message-Id: <9703180325.AA12822 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Mon, 17 Mar 1997 12:21:02 -0500 (EST),
<199703171721.AA26324 at sap-ag.de>
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Given that two people have independently suggested that
gss_export_context changes the context_handle to be GSS_C_NO_CONTEXT if
gss_export_context has an error from which it can't recover, shall we go
with that? It seems to be a particularly elegant solution to the
problem.
- Ted
Received: from ietf.org by ietf.org id aa09605; 18 Mar 97 1:01 EST
Received: from IG.CS.UTK.EDU by ietf.org id aa09493; 18 Mar 97 0:57 EST
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
id AAA07976; Tue, 18 Mar 1997 00:54:10 -0500 (EST)
Message-Id: <199703180554.AAA07976 at ig.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
Sender:ietf-request at ietf.org
From: Keith Moore <moore at cs.utk.edu>
To: "John W. Noerenberg" <jwn2 at qualcomm.com>
cc: Keith Moore <moore at cs.utk.edu>, ietf at ietf.org
Subject: Re: call for a new email infrastructure
In-reply-to: Your message of "Mon, 17 Mar 1997 19:09:32 PST."
<v03102006af53b102054c at [129.46.166.223]>
Date: Tue, 18 Mar 1997 00:54:10 -0500
X-Orig-Sender: moore at cs.utk.edu
Source-Info: From (or Sender) name not authenticated.
> We are arguing about whether this content is acceptable or that content is
> acceptable. And that is wrong. Restricting the flow of information should
> not be the job of information technologists.
And restricting the flow of people through doors should not be the job
of locksmiths?
If I understand you, you are saying that information technologists
should not unilaterally be making decisions on behalf of society
as to what content is or is not acceptable to go over the net.
In general, I agree ...but I would also say that politicans should
not be making such decisions either. Nor should clergy, librarians,
newspaper publishers, or schoolteachers.
It is inevitable that the people who design and implement new technology
have some effect on how it is used. Furthermore, it is often desirable.
To the extent that such people are early adopters of that technology,
they are often the first to become familar with its effects.
I believe it is irresponsible for Internet architects and engineers to not
attempt to develop anti-spam countermeasures. Otherwise we would be
saying to the world "we created this mess, now you have to live with it!"
At the same time, we need to realize that technical solutions are
necessarily limited in scope. Perhaps we can reduce the incidence of
spam, but we cannot eliminate it without eliminating a great deal of
useful content. Spam is evil precisely because it interferes with
communication; we must be careful not to make the problem worse.
And we should realize that (e.g.) politicians, clergy, librarians,
newspaper publishers, and schoolteachers all have a voice in this,
and each will use the tools at his/her disposal to combat the problem.
Keith
Received: from cnri by ietf.org id aa12765; 18 Mar 97 3:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04191;
18 Mar 97 3:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <GAA25237 at pad-thai.cam.ov.com>; Tue, 18 Mar 1997 06:26:29 GMT
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Cc: cat-ietf at mit.edu
Subject: Re: gss_export_sec_context()
References: <9703180325.AA12822 at dcl.MIT.EDU>
From: Sam Hartman <hartmans at mit.edu>
Date: 18 Mar 1997 01:26:23 -0500
In-Reply-To: "Theodore Y. Ts'o"'s message of Mon, 17 Mar 1997 22:25:27 -0500
Message-Id: <tslybblsokw.fsf at luminous.MIT.EDU>
Lines: 15
X-Mailer: Gnus v5.2.37/Emacs 19.34
Precedence: bulk
>>>>> "Theodore" == Theodore Y Ts'o <tytso at MIT.EDU> writes:
Theodore> Given that two people have independently suggested that
Theodore> gss_export_context changes the context_handle to be
Theodore> GSS_C_NO_CONTEXT if gss_export_context has an error from
Theodore> which it can't recover, shall we go with that? It seems
Theodore> to be a particularly elegant solution to the problem.
It has the distinct draw-back that it overloads the meaning of
GSS_S_NO_CONTEXT, which is already a valid return for
gss_export_sec_context. Unfortunately, no other errors besides
GSS_S_FAILURE appear to better describe the situation, and overloading
GSS_S_FAILURE is even less desirable.
Received: from ietf.org by ietf.org id aa13799; 18 Mar 97 3:57 EST
Received: from ecover.globecom.net by ietf.org id aa13447; 18 Mar 97 3:47 EST
Received: from via.globecom.net (metalfan at via.globecom.net [195.100.77.1])
by ecover.globecom.net (8.8.5/8.8.5) with SMTP id JAA01408;
Tue, 18 Mar 1997 09:44:47 +0100
Date: Tue, 18 Mar 1997 09:44:46 +0100 (MET)
Sender:ietf-request at ietf.org
From: Henrik Johansson <hj at globecom.net>
Reply-To: Henrik Johansson <hj at globecom.net>
To: "Blythe, Thomas G." <blythe at geeeffpee.mitre.org>
cc: ietf at ietf.org
Subject: Re: Up-to-date RFC site?
In-Reply-To: <c=US%a=_%p=The_MITRE_Corpor%l=GEEEFFPEE-970317194059Z-163 at geeeffpee.mitre.org>
Message-ID: <Pine.OSF.3.95.970318094323.878C-100000 at via.globecom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997, Blythe, Thomas G. wrote:
> Is there an up-to-date, reliable, web site providing current status of
> RFCs in the standards track? I just visited the RFC Editor page
> (http://www.isi.edu/rfc-editor/status.html) which states that it was
> last modified in June 1996. Are OSPF v2 and POP 3 really still draft
> standards and HTML 2 still a Proposed Standard?
We have made a nice WWW page for all drafts, std's and rfc's. Its
searchable, updated every day from internic. Please check it out at:
http://globecom.net/ietf/
Henrik
-----=<->=-----=</>=-----=<->=-----=<|>=-----=<->=-----=<\>=-----=<->=-----
Henrik Johansson email: hj at globecom.net tel: +46 (0)31-727 37 00
Systems Manager mobile: +46 (0)706-26 15 45 fax: +46 (0)31-727 37 37
GlobeCom Network PGP-Key: http://www.one.se/~hj/pgp/ http://globecom.net/
-----=<->=-----=<\>=-----=<->=-----=<|>=-----=<->=-----=</>=-----=<->=-----
Received: from cnri by ietf.org id aa14544; 18 Mar 97 4:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05211;
18 Mar 97 4:15 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <HAA27005 at pad-thai.cam.ov.com>; Tue, 18 Mar 1997 07:51:53 GMT
Date: Tue, 18 Mar 1997 02:51:48 -0500
Message-Id: <9703180751.AA13003 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Sam Hartman <hartmans at mit.edu>
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>, cat-ietf at mit.edu
In-Reply-To: Sam Hartman's message of 18 Mar 1997 01:26:23 -0500,
<tslybblsokw.fsf at luminous.MIT.EDU>
Subject: Re: gss_export_sec_context()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Sam,
I believe you misunderstood the proposal, which is to change the
context *handle* to GSS_**C**_NO_CONTEXT if gss_export_context needs to
free the context handle. The proposal is *NOT* to return
GSS_S_NO_CONTEXT, which is a status code.
(The symbolic constants GSS_S_NO_CONTEXT -- status code meaning error no
context was passed in, and one was required, and GSS_C_NO_CONTEXT -- a
null pointer meaning no context are unfortunately easy to confuse.)
- Ted
Received: from ietf.org by ietf.org id aa18340; 18 Mar 97 8:39 EST
Received: from ietf.ietf.org by ietf.org id aa18158; 18 Mar 97 8:33 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-slp-01.txt
Date: Tue, 18 Mar 1997 08:33:41 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180833.aa18158 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : DHCP Options for Service Location Protocol
Author(s) : C. Perkins
Filename : draft-ietf-dhc-slp-01.txt
Pages : 3
Date : 03/14/1997
The Dynamic Host Configuration Protocol provides a framework for passing
configuration information to hosts on a TCP/IP network. Entities using the
Service Location Protocol need to find out the address of Directory Agents
in order to transact messages. In certain other instances they may need to
discover the correct scope to be used in conjunction with the service
attributes and URLS which are exchanged using the Service Location
Protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-slp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-slp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-slp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162718.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-slp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-slp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162718.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18964; 18 Mar 97 8:50 EST
Received: from ietf.ietf.org by ietf.org id aa18842; 18 Mar 97 8:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-vpn-00.txt
Date: Tue, 18 Mar 1997 08:49:48 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180849.aa18842 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Implementation of Virtual Private Network (VPNs) with IP
Security
Author(s) : N. Doraswamy
Filename : draft-ietf-ipsec-vpn-00.txt
Pages : 5
Date : 03/14/1997
This document discusses methods for implementing Virtural Private Networks
(VPN) with IP Security (IPSec). We discuss different scenarios in which VPN
is implemented and the security implications for each of these scenarios.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-vpn-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-vpn-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162735.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-vpn-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162735.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18965; 18 Mar 97 8:50 EST
Received: from ietf.ietf.org by ietf.org id aa18822; 18 Mar 97 8:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-01.txt
Date: Tue, 18 Mar 1997 08:49:43 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180849.aa18822 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPNG Working Group of the
IETF.
Title : IP Version 6 over PPP
Author(s) : D. Haskin, E. Allen
Filename : draft-ietf-ipngwg-ipv6-over-ppp-01.txt
Pages : 10
Date : 03/14/1997
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point links.
PPP also defines an extensible Link Control Protocol, and proposes a family
of Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols. This
document defines the method for transmission of IP Version 6 [2] packets
over PPP links as well as the Network Control Protocol (NCP) for
establishing and configuring the IPv6 over PPP. It also specifies the
method of forming IPv6 link-local addresses on PPP links.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipngwg-ipv6-over-ppp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162728.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-over-ppp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162728.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19089; 18 Mar 97 8:50 EST
Received: from ietf.ietf.org by ietf.org id aa18974; 18 Mar 97 8:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-mixer at innosoft.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mixer-directory-01.txt
Date: Tue, 18 Mar 1997 08:50:29 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180850.aa18974 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME - X.400 Gateway Working
Group of the IETF.
Title : Use of an X.500/LDAP directory to support MIXER address
mapping
Author(s) : S. Kille
Filename : draft-ietf-mixer-directory-01.txt
Pages : 9
Date : 03/14/1997
This document defines how to use an X.500 or LDAP directory to support the
mapping between X.400 OR Addresses and mailboxes defined in MIXER (RFC
1327bis) [5].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mixer-directory-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mixer-directory-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mixer-directory-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162748.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mixer-directory-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mixer-directory-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162748.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19254; 18 Mar 97 8:51 EST
Received: from ietf.ietf.org by ietf.org id aa19130; 18 Mar 97 8:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-scm-00.txt
Date: Tue, 18 Mar 1997 08:51:14 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180851.aa19130 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Semi Connected Mode for PPP links
Author(s) : M. Latvala, G. Liu
Filename : draft-ietf-pppext-scm-00.txt
Pages : 15
Date : 03/14/1997
The configuration of a Point-to-Point Protocol (PPP) [1] link requires a
considerable amount of time which makes it impractical to establish a new
PPP link every time an end-user wants to send or is about to receive data.
This document proposes an LCP extension called Semi Connected Mode.
When both sides agree to use Semi Connected Mode they can terminate and
quickly re-establish the bearer service without having to reconfigure the
PPP link.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-scm-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-scm-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-scm-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162802.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-scm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-scm-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162802.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19281; 18 Mar 97 8:51 EST
Received: from ietf.ietf.org by ietf.org id aa19172; 18 Mar 97 8:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: stdguide at midnight.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-stdguide-ops-02.txt
Date: Tue, 18 Mar 1997 08:51:18 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180851.aa19172 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Guide for Internet Standards
Writers Working Group of the IETF.
Title : Guide for Internet Standards Writers
Author(s) : G. Scott
Filename : draft-ietf-stdguide-ops-02.txt
Pages : 19
Date : 03/14/1997
This document is a guide for Internet standard writers. It defines those
characteristics that make standards coherent, unambiguous, and easy to
interpret. Also, it singles out usage believed to have led to unclear
specifications, resulting in non-interoperable interpretations in the past.
These guidelines are to be used with RFC 1543, "Instructions to RFC
Authors."
This version of the document is a draft. It is intended to generate
further discussion and addition by the STDGUIDE working group. Please send
comments to stdguide at midnight.com.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-stdguide-ops-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-stdguide-ops-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-stdguide-ops-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162809.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-stdguide-ops-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-stdguide-ops-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162809.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19372; 18 Mar 97 8:52 EST
Received: from ietf.ietf.org by ietf.org id aa18953; 18 Mar 97 8:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mboned at ns.uoregon.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mboned-intro-multicast-01.txt
Date: Tue, 18 Mar 1997 08:50:25 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180850.aa18953 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MBONE Deployment Working
Group of the IETF.
Title : Introduction to IP Multicast Routing
Author(s) : T. Maufer, C. Semeria
Filename : draft-ietf-mboned-intro-multicast-01.txt
Pages : 54
Date : 03/14/1997
The first part of this paper describes the benefits of multicasting, the
MBone, Class D addressing, and the operation of the Internet Group
Management Protocol (IGMP). The second section explores a number of
different techniques that may potentially be employed by multicast routing
protocols: o Flooding o Spanning Trees o Reverse Path Broadcasting (RPB)
o Truncated Reverse Path Broadcasting (TRPB) o Reverse Path Multicasting
(RPM) o "Shared-Tree" Techniques The third
part contains the main body of the paper. It describes how the previous
techniques are implemented in multicast routing protocols available today
(or under development). o Distance Vector Multicast Routing Protocol
(DVMRP) o Multicast Extensions to OSPF (MOSPF) o Protocol-Independent
Multicast - Dense Mode (PIM-DM) o Protocol-Independent Multicast - Sparse
Mode (PIM-SM) o Core-Based Trees (CBT)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-intro-multicast-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-intro-multicast-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-intro-multicast-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162742.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-intro-multicast-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-intro-multicast-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162742.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab19372; 18 Mar 97 8:52 EST
Received: from ietf.ietf.org by ietf.org id aa19041; 18 Mar 97 8:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-rfced-info-kim-00.txt
Date: Tue, 18 Mar 1997 08:50:35 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703180850.aa19041 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Update of Korean Character Encoding for Internet
Messages
Author(s) : J. Kim, S. Choi, I. Choi, S. Park, S. Chi
Filename : draft-rfced-info-kim-00.txt
Pages : 4
Date : 03/14/1997
Since RFC 1557, which is a Korean character encoding for internet messages,
was distributed in 1993, most mailers have been implemented using it.
However, it's been reported many occurrences of incompatible transfer of
Korean mail messages such as broken mail messages. Therefore certain
features are need to be extended, and ambiguous contents must be clarified.
This document updates RFC 1557 to resolve above matters. This memo
provides information for the Internet community. This memo does not specify
an Internet standard of any kind. Distribution of this memo is unlimited.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rfced-info-kim-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-kim-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-kim-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970317162755.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-kim-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-kim-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970317162755.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19643; 18 Mar 97 8:55 EST
Received: from quackerjack.cc.vt.edu by ietf.org id aa19040; 18 Mar 97 8:50 EST
Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30])
by quackerjack.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id IAA20494 for <ietf at ietf.org>; Tue, 18 Mar 1997 08:47:39 -0500 (EST)
Received: from [128.173.12.232] (sears.cns.vt.edu [128.173.12.232])
by sable.cc.vt.edu (8.8.4/8.8.4) with SMTP
id IAA20641 for <ietf at ietf.org>; Tue, 18 Mar 1997 08:47:38 -0500 (EST)
X-Sender: sears at mail.vt.edu
Message-Id: <v02140b02af544cf424e2 at [128.173.12.232]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Mar 1997 08:48:10 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: pris sears <sears at vt.edu>
Subject: Re: Yet another off-topic IETF mail message!
Source-Info: From (or Sender) name not authenticated.
john j. kilfoil said:
>Greetings,
>
>I represent Intel at the IETF as part of my job. As a result, I *need* to
>subscribe to the IETF mailing lists. A lot of the recent e-mail messages
>addressed to the IETF at large have been interesting, but off topic (read
>'SPAM'). And while they may provoke thought and stir interesting debate,
>is anything
>really being accomplished?
what's the possibility of moving discussion to the spam-list mailing list?
Specifically for looking for technical answers to spam, they are already
monitoring this thread on ietf list with interest....
send mail to "majordomo at mailer.psc.edu" with the following command
in the body of your email message:
subscribe spam-list you at your.net
_____________________________________________________________
Thanks for your kind attention - I'm outta here!
Pris Sears | sears at vt.edu | http://sears.cns.vt.edu/ | 231-2305
Received: from cnri by ietf.org id aa21272; 18 Mar 97 9:13 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10226;
18 Mar 97 9:13 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <MAA04524 at pad-thai.cam.ov.com>; Tue, 18 Mar 1997 12:34:20 GMT
Message-Id: <332F0A5A.11BB at frcl.bull.fr>
Date: Tue, 18 Mar 1997 13:34:18 -0800
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: Peter Brundrett <petebr at microsoft.com>
Cc: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>
Subject: Re: optimistic snego for performance
References: <640796DB4262D0118D3300805FD4EFCF93DC78 at RED-32-MSG.dns.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
> The main purpose for optimistic snego is the performance advantage of
> eliminating extra network round trips.
> The specific protocol change is to add one optional field to the
> NegTokenReq, containing the initial security token for the desired
> mechanism of the Initiator.
> It seems to me that not all targets must be able to support the
> optimistic desiredToken. The target could simply ignore the
> desiredToken and complete the negotiation handshake as described in
> snego-02. Implementations that can piggyback the initial token should
> be rewarded by faster connection setup.
Peter,
Thanks for the explanations. I am also in favour of this proposal and
plan to update the current draft accordingly (unless some one objects).
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa24931; 18 Mar 97 10:22 EST
Received: from callandor.cybercash.com by ietf.org id aa24799;
18 Mar 97 10:18 EST
Received: by callandor.cybercash.com; id KAA10388; Tue, 18 Mar 1997 10:08:24 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma010369; Tue, 18 Mar 97 10:07:57 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA11652; Tue, 18 Mar 97 10:11:19 EST
Date: Tue, 18 Mar 1997 10:11:19 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: ietf at ietf.org
Subject: Re: Yet another off-topic IETF mail message!
In-Reply-To: <01BC32F8.5CE63440 at generic.jf.intel.com>
Message-Id: <Pine.SUN.3.91.970318093642.9486B-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Mon, 17 Mar 1997, John J. Kilfoil wrote:
> Date: Mon, 17 Mar 1997 17:26:30 -0800
> From: John J. Kilfoil <jk at ibeam.jf.intel.com>
>
> Greetings,
>
> I represent Intel at the IETF as part of my job. As a result, I *need* to
> subscribe to the IETF mailing lists. A lot of the recent e-mail messages
This is not true in any sense official to the IETF. IETF members, from the
IETF point of view, represent only themselves as individuals. If you choose
as an individual to act in the interests on the Intel corporation, because
they pay you or for any other reason, that is your choice.
> addressed to the IETF at large have been interesting, but off topic (read
> 'SPAM'). And while they may provoke thought and stir interesting debate,
is anything
> really being accomplished? Beyond generating lots of other off topic e-mail,
> probably not. I would argue that merely having what you consider
> to be a new, different, brilliant, etc. insight is not reason enough
to burden
> the IETF subscribers. In my opinion, most of the recent off-topic
messages would be
> more suitable for submission to a relevant discussion in a news group.
What off-topic messages? If you are talking about the endless announcements
of and calls for papers in connection with non-IETF meetings, that's off
topic. If you are talking about get rich quick and religious book store and
other commercial advertisements, that's off topic. If you are talking about
messages related to the exponentionally increasing volume of network abuse in
the form of auotmated mass unsolicted email and similar stuff, that is a
critical topic which threatens to destroy much of the utility of the Internet
and is 100% on topic. Already Internet connectivity is cracking, damaging
the conecept of universal connectivity, as whole blocks of addresses are
blockaded at the IP level to try to contain the abuse. While it might be
better for such mail to be on a somewhat narrower mailing list, I believe
that much more action has to be taken in this area by the IETF. I hope that
the leadership of the IETF will be more proactive in this area.
> A simple request...Before adding your two cents to an off-topic message,
please
> consider the purpose of the IETF mailing lists and what if anything sending
> your e-mail message will really accomplish in the IETF. If your purpose is
> merely to inform, why not submit your thoughts to an appropriate news
> discussion group?
The utility of network news has been deciminated by SPAM. It limps along
only due to the massive effort of many who maintain autocancel daemons.
These daemons cancel many *hundreds of thousands* of postings every month.
And most of those postings cancelled are criminal chain letters and pryamid
schemes. In vast parts of the newsgroup hierarchy, cancelling has been
abandoned and the vast majority of postings are clearly off topic commercial
messages. I and many others are extremely reluctant to post to any newsgroup
because I know that they are a prime target for address harvesting by
spammers.
If this blizzard of messages on email abuse does nothing more than impress on
the members of the IAB and IESG what a major problem this is and how
seriously people take it, it will have been more than worthwhile.
> ...
>
> John Kilfoil
> Systems Manageability Group
> Intel Platform Architecture Lab
> --
> My opinions are my own and do not necessarily represent the position of
> Intel, the Platform Architecture Lab, or the Systems Manageability group.
[They why all this guff about how you represent Intel?]
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa29007; 18 Mar 97 13:38 EST
Received: from www.atr.net by ietf.org id aa28714; 18 Mar 97 13:26 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id fa000395 for <ietf at ietf.org>; Tue, 18 Mar 1997 13:24:21 +0000
Message-ID: <332EDDD4.221 at atr.net>
Date: Tue, 18 Mar 1997 13:24:20 -0500
Sender:ietf-request at ietf.org
From: "Turner W Rentz , III" <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advanced Technology and Research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
CC: ietf at ietf.org
Subject: Re: Yet another off-topic IETF mail message!
References: <Pine.SUN.3.91.970318093642.9486B-100000 at cybercash.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at warp.atr.net
Source-Info: From (or Sender) name not authenticated.
Donald E. Eastlake 3rd wrote:
> Already Internet connectivity is cracking, damaging
> the conecept of universal connectivity, as whole blocks of addresses are
> blockaded at the IP level to try to contain the abuse.
> The utility of network news has been deciminated by SPAM. It limps along
> only due to the massive effort of many who maintain autocancel daemons.
Wow! That's true!
Let's get the lightweight "remove spam" off this list.
I'll help if needed. Are there any "micro requirements" for this list?
Where I should send source?
--
T. Rentz, III "The Internet is the Garden of Eden."
Software Engineer
http://www.atr.net/people/treyr
Received: from ietf.org by ietf.org id aa00040; 18 Mar 97 14:04 EST
Received: from cnri by ietf.org id aa29683; 18 Mar 97 13:58 EST
Received: from sirius.ctr.columbia.edu by CNRI.Reston.VA.US id aa17158;
18 Mar 97 13:57 EST
Received: from nebula.ctr.columbia.edu (koonseng at nebula.ctr.columbia.edu [128.59.68.18]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with ESMTP id NAA06382; Tue, 18 Mar 1997 13:54:29 -0500 (EST)
Sender:ietf-request at ietf.org
From: Koon-Seng Lim <koonseng at ctr.columbia.edu>
Received: (koonseng at localhost) by nebula.ctr.columbia.edu (8.8.5/8.6.4.788743) id NAA25118; Tue, 18 Mar 1997 13:54:28 -0500 (EST)
Date: Tue, 18 Mar 1997 13:54:28 -0500 (EST)
Message-Id: <199703181854.NAA25118 at nebula.ctr.columbia.edu>
To: arpanet-bboard at mc.lcs.mit.edu, cabernet-events at ncl.ac.uk,
commsoft at cc.bellcore.com, comsoc.tac at tab.ieee.org, comswtc at gmu.edu,
cost237-transport at comp.lancs.ac.uk, ctc-members at redbank.tinac.com,
end2end-interest at isi.edu, ftroup at codex.cis.upenn.edu, giga at tele.pitt.edu,
gtroup at dworkin.wustl.edu, hipparch at sophia.inria.fr,
ieee.announce at bellcore.com, ietf at CNRI.Reston.VA.US, ifip-nm at bbn.com,
itc at fokus.gmd.de, multicomm at cc.bellcore.com, osimcast at bbn.com,
rem-conf-request at es.net, sigmedia at bellcore.com, tccc at cs.umass.edu,
xtp-relay at cs.concordia.ca
Source-Info: From (or Sender) name not authenticated.
My apologies for those who have already recevied this more than once.
------------------------------------------------------------------------------
IEEE CONFERENCE on OPEN ARCHITECTURES AND NETWORK PROGRAMMING
"OPENARCH '98"
C A L L F O R P A R T I C I P A T I O N
San Francisco, CA, USA
April 3-4, 1998
http://comet.ctr.columbia.edu/openarch
The First IEEE Conference on Open Architectures and Network Programming
(OPENARCH'98) will be held on April 3-4, 1998 in San Francisco, CA, USA,
at the Hotel Nikko. The conference is sponsored by the IEEE Communications
Society and will be co-located and organized in conjunction with INFOCOM'98.
Recent advances in distributed systems and transportable software together
with increasing demand for better control of quality of service in
multiservices networks are driving a reexamination of network software
architectures. There is a new opportunity to reconcile the perspectives
of the computing and communication communities in new network architectures
that support service creation, QoS control, and the joint allocation of
computing and communications resources.
OPENARCH will offer a forum for the communication of experimental as well
as theoretical results aimed at a better understanding of the overall
networking architecture and its realization in software. It will encourage
a shift of the processes of service creation, resource allocation and control
from ad-hoc solutions to a discipline of network programming.
AUTHORS ARE INVITED to submit unpublished papers, as well as proposals for
tutorials and panel discussions that address these and other questions
with a focus on the following topical areas:
- Scalable Networking Architectures
- Broadband Kernels
- Open Signalling
- Active Networks
- Intelligent Agents and Trading
- Integrated Control, Management and Service and generic APIs
- Models for Managing Complexity and Fault Recovery
- Performance of Control Architectures
- Experimental Architectures and Efficient Implementation Techniques
- Enabling Technologies, Platforms and Languages (Corba, WWW, Java, etc.)
- Information Representation, Modeling and Abstractions
- Multiple Viewpoint Modeling
- Distributed Computing Models and Algorithms
- High Performance Transport Protocols
- QOS Control Frameworks and End-to-End Programming
- Resource Allocation and Networking Games
- Programming for Mobility
- Modeling of Network Services
- Service Creation, Deployment and Management across ATM, Internet, and
Mobile Networks
- Interactive Multimedia, Multi-party Cooperation and Groupware
- Pricing and Billing
- Secure Transactions Processing and Electronic Commerce
The cover page of each submitted paper should include paper title, brief
abstract, list of key-words, author(s) full name(s), affiliation(s) and
complete address(es), telephone number(s) and electronic mail address(es).
ELECTRONIC SUBMISSION IS ADVISABLE. Authors are requested to submit
papers in postscript format. Instructions for electronic submissions
are available at <http://comet.ctr.columbia.edu/openarch/submit.html>.
In addition, for ALL submissions the cover page of the paper should
be submitted separately.
If electronic submission is not possible, mail six (6) copies of your
paper to:
Prof. Aurel A. Lazar, OPENARCH'98 Program Chair
Department of Electrical Engineering
500 West 120th Street
Columbia University, New York, NY 10027-6699, USA
Email: aurel at ctr.columbia.edu
All submissions will be carefully reviewed by international experts and
returned to the author(s) with comments to ensure high quality. Accepted
papers will be published in a hard-bound Conference Proceedings. A CD-ROM
version is also being considered. The final camera-ready manuscript
should be no longer than 12 single-spaced pages, including figures.
Deadline for Receipt of Papers: June 30, 1997
Notification of Acceptance Mailed: October 1, 1997
Final Camera Ready Papers Due: December 1, 1997
A limited number of stipends are available to those unable to obtain funding
to attend the conference. Students whose papers are accepted and who will
present the paper themselves are encouraged to apply if such assistance is
needed. Requests for stipends should be addressed to the Program Chair or a
Program Committee member in the requestor's region. A limited number of IEEE
Student Travel Grants may be available for student authors from outside North
America.
--------------------------------------------------------
ORGANIZING COMMITTEE:
General Chair: Steve Weinstein, NEC
Program Chair: Aurel A. Lazar, Columbia University, USA
Treasurer: Chuck Kalmanek, AT&T Labs
Publicity: Srinivasan Keshav, Cornell University
Local Arrangements: Raphi Rom, Sun Microsystems
IEEE ComSoc Coordinator: Steve Weinstein, NEC
Webmaster: Koon-Seng Lim, Columbia University
PROGRAM COMMITTEE:
Ken Birman, Cornell University
Piergiorgio Bosco, CSELT
Andrew T. Campbell, Columbia University
Paul Chang, CISCO
Jon Crowcroft, University College London
Emanuel Darmois, TINA-C and Alcatel
Shri Goyal, GTE
Per Gunningberg, Uppsala University
David Hutchison, Lancaster University
Masaichi Kajiwara, OMRON
Kenichi Kitami, NTT
Timothy Kwok, Microsoft
Tom LaPorta, Bell Labs
Ian Leslie, University of Cambridge
Olli Martikainen, Telecom Finnland
Luis de Moraes, Federal University of Rio de Janeiro
Peter Newman, Ipsilon
Max Ott, NEC C&C Labs
Giovanni Pacifici, IBM T.J.Watson Research Center
Ian Roos, University of Pretoria
Douglas Schmidt, University of Washington in St. Louis
Henning G. Schulzrinne, Columbia University
Jonathan M. Smith, University of Pennsylvania
Rolf Stadler, Columbia University
Andrew Thomas, HP Labs
Michael To, Nortel
Weiguo Wang, Institute of Systems Science
Martina Zitterbart, Technische Universitaet Braunschweig
Members of the Organizing Committee
are also members of the Program Committee.
Received: from ietf.org by ietf.org id aa00242; 18 Mar 97 14:08 EST
Received: from paladin.demon.co.uk by ietf.org id aa00062; 18 Mar 97 14:04 EST
Received: from athena (john at localhost [127.0.0.1]) by paladin.demon.co.uk (8.8.3/8.6.9) with ESMTP id TAA08814 for <ietf at ietf.org>; Tue, 18 Mar 1997 19:01:40 GMT
Message-Id: <199703181901.TAA08814 at paladin.demon.co.uk>
X-Mailer: exmh version 1.6.9 8/22/96
To: ietf at ietf.org
Subject: A consumer driven model for internet commerce (a technical band aid
for UCE)
Reply-to: john at paladin.demon.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 18 Mar 1997 19:01:40 +0000
Sender:ietf-request at ietf.org
From: John Lines <john at paladin.demon.co.uk>
Source-Info: From (or Sender) name not authenticated.
The whole advertising industry at present is highly inefficient, including
junk mail, junk email etc. Companies spend a large amount of money to send
information to consumers, many of whom are not interested - hence the
information end up in the bin, or procmail filter.
Paradoxically if a consumer actually wishes to buy, say double glazing, you
can be almost certain that junk mail and phone calls from double glazing
sales people will mysteriously cease, and the prospective purchaser will
have to chase round trying to find someone to sell them something.
At present the whole junk email model is based around an old system where
the producers know what they want to sell you, but dont know what you want
to buy, however the Internet is a two way medium, and permits a new
arrangement.
Suppose the purchaser had a way of advertising what they do (and dont) wish
to buy at the present time, for example by means of a specially formatted
file on a web server. The producer organisations scan these files using
a web crawler (in practice it would probably be a broker organisation which
would do this - probably one or more of the present web indexing companies)
They see if the requirements of the consumer (which could be an individual or
a large company) match their product, and then they can make contact via
email with a specific offer.
The specification for such a file seems a valid role for the IETF.
Ideally it should cover such things as
64Mb memory for a Sparcstation
A pine dresser between 1.5 and 1.7m long, with half glazed top
An opportunity to purchase magazines at less than street prices
There should probably also be a way specify exclusions, e.g.
An opportunity to make money fast, but not schemes X,Y or Z - to which they
have already sent their money with no return
(UCE mail senders please note that none of the above match my current
requirements - although if anyone meets someone who falls into the last
catagory please put them in touch with me - I am sure I could think of a
scheme to interest them :-) )
Looking at the present economics which drive UCE, the market seems to be
driven by relative newbies, who approach small companies as 'consultants'
or write books called 'How to make a fast buck on the internet'
They are not making huge amounts of money because they prey on people who
know less about the internet than they do, so they must constantly seek new
business.
A system where large well organised, internet aware organisations, such as
Alta Vista are competing in a similar market to the senders of UCE should
result in spam drying up due to lack of demand. (dry spam is not very
palatable)
John Lines
Received: from ietf.org by ietf.org id aa01505; 18 Mar 97 14:21 EST
Received: from apt.usa.globalnews.com by ietf.org id aa01327;
18 Mar 97 14:16 EST
Received: from [204.254.77.141] by apt (5.x/SMI-SVR4)
id AA18210; Tue, 18 Mar 1997 14:09:05 -0500
Date: Tue, 18 Mar 1997 14:09:04 -0500
Message-Id: <v03007800af5454000185 at [204.254.77.141]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Nick Patience - Online Reporter <nick at apt.computerwire.com>
Source-Info: From (or Sender) name not authenticated.
unsubscribe
_______________________________________________
Nick Patience Editor - Online Reporter
Computerwire Inc nick at computerwire.com
928 Broadway Ph: (212) 677 0409
Suite 800 Fx: (212) 677 0463
New York NY 10010 http://www.computerwire.com
Received: from cnri by ietf.org id aa02042; 18 Mar 97 14:29 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18241;
18 Mar 97 14:28 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA16743 at pad-thai.cam.ov.com>; Tue, 18 Mar 1997 17:40:31 GMT
Message-Id: <640796DB4262D0118D3300805FD4EFCFBD0448 at RED-32-MSG.dns.microsoft.com>
From: Peter Brundrett <petebr at microsoft.com>
To: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'D.Pinkas at frcl.bull.fr'" <D.Pinkas at frcl.bull.fr>
Subject: Re: optimistic snego for performance
Date: Tue, 18 Mar 1997 09:39:48 -0800
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1457.3)
Precedence: bulk
Denis,
Thank you for reviewing the proposal and determining it is appropriate
to add to SNEGO. Thanks also to those on the CAT list who supported the
idea.
Peter
> -----Original Message-----
> From: Denis Pinkas [SMTP:D.Pinkas at frcl.bull.fr]
> Sent: Tuesday, March 18, 1997 1:34 PM
> To: Peter Brundrett
> Cc: 'cat-ietf at mit.edu'
> Subject: Re: optimistic snego for performance
>
> > The main purpose for optimistic snego is the performance advantage
> of
> > eliminating extra network round trips.
>
> > The specific protocol change is to add one optional field to the
> > NegTokenReq, containing the initial security token for the desired
> > mechanism of the Initiator.
>
> > It seems to me that not all targets must be able to support the
> > optimistic desiredToken. The target could simply ignore the
> > desiredToken and complete the negotiation handshake as described in
> > snego-02. Implementations that can piggyback the initial token
> should
> > be rewarded by faster connection setup.
>
> Peter,
>
> Thanks for the explanations. I am also in favour of this proposal and
> plan to update the current draft accordingly (unless some one
> objects).
>
> Denis
>
>
>
>
>
> --
>
> Denis Pinkas Bull S.A. E-mail :
> D.Pinkas at frcl.bull.fr
> Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa02987; 18 Mar 97 14:38 EST
Received: from ietf.ietf.org by ietf.org id aa02758; 18 Mar 97 14:35 EST
To: IETF-Announce: ;
Subject: WG ACTION: Internet Printing Protocol (ipp)
Date: Tue, 18 Mar 1997 14:35:51 -0500
Sender:ietf-announce-request at ietf.org
From: Steve Coya <scoya at ietf.org>
Message-ID: <9703181435.aa02758 at ietf.org>
A new working group has been formed in the Applications Area of the
IETF. For additional information, contact the Area Directors or the WG
Chair.
Internet Printing Protocol (ipp)
--------------------------------
Chair(s):
Carl-Uno Manros <cmanros at cplo.es.xerox.com>
Steve Zilles <szilles at adobe.com>
Applications Area Director(s):
Keith Moore <moore+iesg at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Area Advisor
Keith Moore <moore+iesg at cs.utk.edu>
Mailing lists:
General Discussion:ipp at pwg.org
To Subscribe: ipp-request at pwg.org
Archive: ftp://ftp.pwg.org/pub/pwg/ipp/
Description of Working Group:
There is currently no universal standard for printing. Several
protocols are in use, but each has limited applicability and none can
be considered the prevalent one. This means that printer vendors have
to implement and support a number of different protocols and protocol
variants. There is a need to define a protocol which can cover the
most common situations for printing on the Internet.
The goal of this working group is to develop requirements for Internet
Printing and to describe a model and semantics for Internet Printing.
The further goal is to define a new application level Internet Printing
Protocol for the following core functions:
- for a user to find out about a printer's capabilities
- for a user to submit print jobs to a printer
- for a user to find out the status of a printer or a print job
- for a user to cancel a previously submitted job
The Internet Print Protocol is a client-server type protocol which
should allow the server side to be either a separate print server or a
printer with embedded networking capabilities. The focus of this effort
is optimized for printers, but might be applied to other output
devices. These are outside the scope of this working group.
The working group will also define a set of directory attributes that
can be used to ease finding printers on the network.
The Internet Print Protocol will include mechanisms to ensure adequate
security protection for materials to be printed, including at a minimum
mechanisms for mutual authentication of client and server and
mechanisms to protect the confidentiality of communications between
client and server.
Finally, the IPP working group will produce recommendations for
interoperation of LPR clients with IPP servers, and IPP clients with
LPR servers. These recommendations will include instructions for both
the translation of the LPR protocol onto IPP and the translation of the
IPP protocol onto LPR. However, there is no expectation to provide new
IPP features to LPR clients, nor is there an explicit requirement to
translate LPR extensions to IPP, beyond those features available in the
4.2BSD UNIX implementation of LPR, and which are still useful today.
Other capabilities that will be examined for future versions include:
- security features for authentication, authorization, and policies
- notifications from the server to the client
- accounting
Subjects currently out of scope for this working group are:
- protection of intellectual property rights
- fax input
- scanning
The working group shall strive to coordinate its activities with other
printing-related standards bodies, without the need to be strictly
bound by their standards definitions. These groups are:
- ISO/IEC JTC 1/SC 18/WG 4 on Document Printing Application (ISO/IEC
10175 parts 1 - 3)
- The Object Management Group (OMG) on OMG Printing Facility (in
development)
- IEEE (POSIX System Administration - Part 4: Printing Interfaces)
- X/Open (Printing Systems Interoperabilty Specification)
- The Printer Working Group
Goals and Milestones:
Mar 97 Submit Internet Printing Protocol: Requirements and Scenarios
as an Internet-Draft.
Mar 97 Submit Internet Printing Protoco/1.0: Model and Semantics as an
Internet-Draft.
Mar 97 Submit Internet Printing Protoco/1.0: Protocol as an
Internet-Draft.
Mar 97 Submit Internet Printing Protoco/1.0: Directory Schema as an
Internet-Draft.
Apr 97 Review of specification in IETF meeting in Memphis, TN, USA
May 97 Produce At least 2 implemented prototypes
Aug 97 Submit Internet Printing Protocol: Requirements and Scenarios
I-D to IESG for publication as an Informational RFC.
Aug 97 Submit other Internet-Drafts to IESG for consideration as
Proposed Standards.
Received: from ietf.org by ietf.org id aa03996; 18 Mar 97 15:00 EST
Received: from aleve.media.mit.edu by ietf.org id aa03729; 18 Mar 97 14:54 EST
Received: from ml.media.mit.edu (ml.media.mit.edu [18.85.13.107]) by media.mit.edu (8.7.5/ML961206) with SMTP id OAA19491; Tue, 18 Mar 1997 14:51:31 -0500 (EST)
Received: from bad-taste.media.mit.edu by ml.media.mit.edu; (5.65v3.2/1.1.8.2/12Apr96-0443PM)
id AA29091; Tue, 18 Mar 1997 14:51:28 -0500
Date: Tue, 18 Mar 1997 14:51:22 -0500 (EST)
Sender:ietf-request at ietf.org
From: Roger WOJA Kermode <woja at media.mit.edu>
To: John Lines <john at paladin.demon.co.uk>
Cc: ietf at ietf.org
Subject: Re: A consumer driven model for internet commerce (a technical band aid for UCE)
In-Reply-To: <199703181901.TAA08814 at paladin.demon.co.uk>
Message-Id: <Pine.OSF.3.91.970318143616.31708B-100000 at bad-taste.media.mit.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
John,
Your point below is a valid one.
> At present the whole junk email model is based around an old system where
> the producers know what they want to sell you, but dont know what you want
> to buy, however the Internet is a two way medium, and permits a new
> arrangement.
and the ability to specify things you are particularly interested in or
not interested in would no doubt help significantly to reduce netwrok
traffic.
However, I suspect that many advertizers will argue that the
resulting filter may not be their best interests as their job is to
identify or create a need where one did not exist or was not known to exist
before.
Furthermore, it may not be in your best interest either as you may
inadvertently filter out something which you may have been truly
interested in.
Maybe advertizing should be something that is delivered via an agent
that looks at the preference list you describe and selectively pulls in
ads of interest and perhaps some others occaisonally just to make sure
that you haven't changed your mind. Each successive rejection of a piece
of junk email could raise a threshold so that eventually one never
recevies particularly loathsome/boring ads.
Roger (just playing devils adovcate)
Roger Kermode Research Assistant
woja at media.mit.edu tel : +1 617 253 0341
Entertainment & Information Systems Group fax : +1 617 258 6264
MIT Media Lab, 20 Ames St, RmE15-354, Cambridge, MA 02139 USA
Received: from ietf.org by ietf.org id aa04398; 18 Mar 97 15:03 EST
Received: from sjf-mail20.sjf.novell.com by ietf.org id aa04181;
18 Mar 97 15:00 EST
Received: from INET-SJF-Message_Server by novell.com
with Novell_GroupWise; Tue, 18 Mar 1997 11:42:22 -0800
Message-Id: <s32e7f9e.087 at novell.com>
X-Mailer: Novell GroupWise 4.1
Date: Tue, 18 Mar 1997 11:41:50 -0800
Sender:ietf-request at ietf.org
From: Fred Ou <FOU at novell.com>
To: ietf at ietf.org, smime-dev at rsa.com, ietf-pkix at tandem.com
Subject: Looking for random number testing tools
Source-Info: From (or Sender) name not authenticated.
Hi,
I have implemented a random number generator based on mouse movement. I am looking for
tools that will test randomness of the number generated by my software.
Your help is very much appreciated !
-Fred
Received: from ietf.org by ietf.org id aa04922; 18 Mar 97 15:09 EST
Received: from stccmail.stcc.mass.edu by ietf.org id aa04526;
18 Mar 97 15:05 EST
Received: from mail.stcc.mass.edu (mail.stcc.mass.edu [134.241.96.29]) by stccmail.stcc.mass.edu (AIX4.2/UCB 8.7/8.7) with ESMTP id OAA31194 for <ietf at ietf.org>; Tue, 18 Mar 1997 14:38:04 -0500 (EST)
Received: from MAIL/SpoolDir by mail.stcc.mass.edu (Mercury 1.21);
18 Mar 97 15:41:57 -0500
Received: from SpoolDir by MAIL (Mercury 1.21); 18 Mar 97 15:41:51 -0500
Received: from rstewart.ne.3com.com by mail.stcc.mass.edu (Mercury 1.21);
18 Mar 97 15:41:43 -0500
Comments: Authenticated sender is <stewart at mail.stcc.mass.edu>
Sender:ietf-request at ietf.org
From: Richard Stewart <stewart at mail.stcc.mass.edu>
To: ietf at ietf.org
Date: Tue, 18 Mar 1997 14:57:37 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Reply-to: stewart at mail.stcc.mass.edu
Return-receipt-to: stewart at mail.stcc.mass.edu
Priority: normal
X-mailer: Pegasus Mail for Win32 (v2.52)
Message-ID: <19C712130A at mail.stcc.mass.edu>
Source-Info: From (or Sender) name not authenticated.
UNSUBSCRIBE
Received: from ietf.org by ietf.org id aa14883; 18 Mar 97 18:46 EST
Received: from online.tmx.com.au by ietf.org id aa14608; 18 Mar 97 18:32 EST
Received: (daemon at localhost) by online.tmx.com.au (8.8.4/8.6.5) id KAA19994; Wed, 19 Mar 1997 10:29:46 +1100 (EST)
Received: from unknown(203.24.179.91) by online.tmx.com.au via smap (V1.3mjr)
id sma019958; Wed Mar 19 10:29:25 1997
Received: by rayk.netlab.com.au with Microsoft Mail
id <01BC3450.561B77C0 at rayk.netlab.com.au>; Wed, 19 Mar 1997 10:28:50 +1000
Message-ID: <01BC3450.561B77C0 at rayk.netlab.com.au>
Sender:ietf-request at ietf.org
From: Ray King <rayk at atp.com.au>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Unsubcribe
Date: Wed, 19 Mar 1997 10:28:49 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Received: from cnri by ietf.org id aa16268; 18 Mar 97 19:22 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25146;
18 Mar 97 19:22 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA26886 at pad-thai.cam.ov.com>; Tue, 18 Mar 1997 21:59:55 GMT
Message-Id: <199703182159.AA11928 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
To: John Linn <linn at cam.ov.com>
Date: Tue, 18 Mar 1997 22:59:00 +0100 (MEZ)
Cc: cat-ietf at mit.edu, wray at tuxedo.enet.dec.com
In-Reply-To: <199703071737.MAA04437 at gza-client1.cam.ov.com> from "John Linn" at Mar 7, 97 12:37:53 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
> John writes, excerpting:
>
> >The textual description of the GSSAPI specs could perhaps be
> >more negotiation-friendly (for example, the routine description for
> >gss_init_sec_context() could explicitly say that the actual_mech
> >parameter doesn't have to be the same as the input mech_type
> >parameter, and use a negotiation mechanism mech_type as an example,
> >where the eventual actual_mech parameter would indicate the chosen
> >mechanism, not the negotiation mechanism).
>
> I thought that RFC-2078 explicitly covered this; I checked and it
> does. On page 39 (deep into the discussion of
> GSS_Init_sec_context()), is the following text:
>
> The returned mech_type value indicates the specific mechanism
> employed on the context, is valid only along with major_status
> GSS_S_COMPLETE, and will never indicate the value for "default".
> Note that, for the case of certain mechanisms which themselves
> perform negotiation, the returned mech_type result may indicate
> selection of a mechanism identified by an OID different than that
> passed in the input mech_type argument.
While this may sound good at first reading, it bears a lot of danger.
As long as there are official "negotiation mechanisms" and an application
asks for it, everything should work fine. But when a multi-mechanism
implementation decides to chose Mech-A when the application actually
has asked for Mech-B, then this will cause severe problems with ACLs
based on exported names, because an exported name was defined to
contain the mech_oid. I think it should rather fail than choose
Mech-A when "true" Mech-B is requested but unavailable, and this error
should always show up on the initiator side, not the acceptor side.
Mechanism negotiation will become especially messy and error prone
when the different mechanism use different native/canonical namespaces.
It should definitely possible for an application to tell its gssapi
mechanism to behave deterministic and skip all fancy mechanism negotiation,
and I think this should definitely happen when an application *REQUESTS*
a specific mechanism (behaviour) by using explicit mechanism OIDs for
init_sec_context() on the initiator side and/or acquire_cred() on the
acceptor side.
-Martin
Received: from ietf.org by ietf.org id aa00910; 19 Mar 97 4:58 EST
Received: from nebula.online.ee by ietf.org id aa00475; 19 Mar 97 4:46 EST
Received: from localhost (jk at localhost) by nebula.online.ee (8.8.3/8.8.3) with SMTP id LAA06414; Wed, 19 Mar 1997 11:39:49 +0200 (EET)
Date: Wed, 19 Mar 1997 11:39:46 +0200 (EET)
Sender:ietf-request at ietf.org
From: Jyri Kaljundi <jk at stallion.ee>
X-Sender: jk at nebula
To: Fred Ou <FOU at novell.com>
cc: ietf at ietf.org, smime-dev at rsa.com, ietf-pkix at tandem.com
Subject: Re: Looking for random number testing tools
In-Reply-To: <s32e7f9e.089 at novell.com>
Message-ID: <Pine.GSO.3.95.970319113723.5761B-100000 at nebula>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Tue, 18 Mar 1997, Fred Ou wrote:
> I have implemented a random number generator based on mouse movement. I am looking for
> tools that will test randomness of the number generated by my software.
Look at the following page, especially "Source code for testing
randomness" section :
http://www.cs.berkeley.edu/~daw/netscape-randomness.html
Juri Kaljundi
jk at stallion.ee
Received: from ietf.org by ietf.org id aa09369; 19 Mar 97 11:13 EST
Received: from quicklink.com by ietf.org id aa09170; 19 Mar 97 11:06 EST
Received: from SMESSER (bus218-97.gsb.columbia.edu) by www (5.x/SMI-SVR4)
id AA22963; Wed, 19 Mar 1997 11:03:09 -0500
Message-Id: <33303841.C39 at columbia.edu>
Date: Wed, 19 Mar 1997 11:02:25 -0800
Sender:ietf-request at ietf.org
From: Stephen Messer <sdm28 at columbia.edu>
Reply-To: sdm28 at columbia.edu
Organization: The Columbia Institute for Tele-Information
X-Mailer: Mozilla 3.0 (Win95; U; 16bit)
Mime-Version: 1.0
To: jspira at basex.com
Subject: WTO on-line event
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Join the Virtual Institute of Information [www.ctr.columbia.edu/vii/]
and
Georgetown University's Communication, Culture, and Technology Program
[www.georgetown.edu/grad/CCT/] for an on-line conference discussing the
World Trade Organizations deal on basic telecommunications on Thursday,
March 20, 1997, 10-12pm eastern time [www.ctr.columbia.edu/vii/wto/].
Moderated by Dr. William J. Drake
Associate Director, Communication, Culture, and Technology Program,
Georgetown University
A short introduction appears below, but if you have any questions,
please contact the Virtual Institute of Information: (tel) 212 854 4222,
(fax) 212 932 7816, (e-mail) vii at ctr.columbia.edu
The World Trade Organization Deal on Basic
Telecommunications Services:
Implications for National Markets and the Global Information
Infrastructure
On February 15, 1997, an historic agreement to liberalize foreign entry
into basic telecommunications services markets was reached under the
auspices of the Geneva-based World Trade Organization (WTO).
According to the WTO, the sixty eight countries involved account for
ninety percent of the revenues of a market worth well over half a
trillion
dollars per year world-wide.
In a narrow sense, the recent deal is the product of a negotiation
launched in 1994 by members of the WTO's Group on Basic
Telecommunications (GBT) . But in a broader sense, the GBT agreement
is the continuation of a process set underway during the Uruguay Round
trade negotiations that lasted from 1986 to 1994. In addition to
covering
traditional sectors like manufacturing and new issues like intellectual
property, the Uruguay Round negotiations produced the world's first
multilateral arrangement liberalizing trade in services----the General
Agreement on Trade in Services (GATS). The GATS accord comprised
three elements: a framework agreement that for the first time applies
trade principles like Most Favored Nation treatment, Market Access, and
National Treatment to a wide variety of services industries; sectoral
annexes that clarified the scope of application of trade principles to a
few select sectors; and national schedules of commitments---over two
thousand pages---in which signatories bound themselves to allow
foreign competition in services via designated modes of supply. One of
the sectoral annexes covered telecommunications services, although the
sensitive question of foreign competition in basic telecommunications
was left to a future negotiation. The GBT agreement, then, essentially
seals the deal with respect to bringing telecommunications services
fully
under the global trade policy framework.
The GBT deal on basic telecommunications could have a profound impact
on the shape of national markets and, by extension, the Global
Information Infrastructure. But press coverage of the agreement has
been rather limited, and many analysts of and stakeholders in the global
telecommunications industry are just beginning to find out what the
agreement covers, much less to debate what its effects could be. There
are many outstanding issues that need to be addressed. For example, to
what extent will implementation of the agreement affect: National
regulatory policies and institutions? Objectives like interconnection
and
universal service? Local and long-distance competition in telephone
services and other services deemed basic in the national schedules?
The strategies of the major international carriers, and the prospects of
smaller competitors? The Internet and other advanced networks and
services? The possibilities for developing countries in the global
information economy? Other regional or global telecommunications
organizations and regimes?
To address these and other questions, CITI [www.ctr.columbia.edu/citi/]
and CCT [www.georgetown.edu/grad/CCT] have created a special area
on the Virtual Institute of Information to address issues regarding the
World Trade Organization Agreement. This page includes links to
biblographical information both on-line and off-line. The on-line chat
on
March 20 will be the first event in the series.
Virtual panelists to lead off the discussion will include:
Cynthia A. Beltz, The American Enterprise Institute
Carlos Primo Braga, The World Bank
Diana Lady Dougan, Center for Strategic and International Studies
Timothy C. Finton, The U.S. Department of State
Robert M. Frieden, Pennsylvania State University
Gary Hufbauer, Institute for International Economics
Tim Kelly, International Telecommunication Union
Bruno Lanvin, United Nations Conference on Trade and Development
Christophe Leclercq, Commission of the European Union
Jamie Love, Consumer Project on Technology
Allen Miller, Electronic Data Systems
Eli M. Noam, Columbia University
Ben A. Petrazzini, International Telecommunication Union
Lee Tuthill, World Trade Organization
Anthony Rutkowski, General Magic
Shalini Venturelli, American University
The on-line seminar will consist of a web-based chat program. To
utilize
this, you should be using Netscape 2.0 or higher. For the first half
hour,
the panelists will discuss their viewpoints on the issues. From 10:30am
EST on, the discussion will be open to the public, with Dr. Drake
moderating. If you wish to follow the discussion without participating,
there will be an option to read the transcript as the discussion
proceeds.
There will also be a forum available to post ideas and continue
longer-term discussions. If anyone has working papers on this topic
that
they would like to submit to be part of the bibliography, please send
email
to vii at ctr.columbia.edu.
--
____________________________________________________________________
Stephen Messer
The Columbia Institute for Tele-Information,
http://www.ctr.columbia.edu/citi
The Virtual Institute of Informaiton, http://www.ctr.columbia.edu/vii
smesser at claven.gsb.columbia.edu sdm28 at columbia.edu
Phone: 212-854-4222 Fax: 212-932-7816
Received: from cnri by ietf.org id aa09855; 19 Mar 97 11:19 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13860;
19 Mar 97 11:19 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA28356 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 14:52:02 GMT
Message-Id: <199703191451.AA12999 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
To: John Linn <linn at cam.ov.com>, wray at tuxedo.enet.dec.com
Date: Wed, 19 Mar 1997 09:50:54 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703191423.JAA20558 at gza-client1.cam.ov.com> from "John Linn" at Mar 19, 97 09:23:39 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
> Martin Rex wrote:
> > While this may sound good at first reading, it bears a lot of danger.
> >
> > As long as there are official "negotiation mechanisms" and an application
> > asks for it, everything should work fine. But when a multi-mechanism
> > implementation decides to chose Mech-A when the application actually
> > has asked for Mech-B, then this will cause severe problems with ACLs
> > based on exported names, because an exported name was defined to
> > contain the mech_oid. I think it should rather fail than choose
> > Mech-A when "true" Mech-B is requested but unavailable, and this error
> > should always show up on the initiator side, not the acceptor side.
> >
> > Mechanism negotiation will become especially messy and error prone
> > when the different mechanism use different native/canonical namespaces.
> >
>
> I'll note two points which bear on the question:
>
> (1) there's no separate means for distinguishing a negotiating mechanism
> from a non-negotiating mechanism other than by checking its OID and tracing
> to the corresponding description; further,
>
> (1a) no one specifying the OID of a non-negotiating mechanism should ever
> receive a different OID as output, and
>
> (1b) the actual OID is always available to the initiator, as an output
> from GSS_Init_sec_context().
>
> (2) it's possible that negotiation within a "mechanism family" where
> different OIDs were used, e.g., to represent different cryptographic
> choices under a particular technology would be fully safe in terms of
> yielding compatible name forms
compatible name forms in which respect. How does the mechanism family
interact with canonicalize_name() and export_name() ? It's not obvious
how to create an application-transparent mechanism family for GSS-API v2
in the way canonicalize_name() and export_name() are currently defined.
Hmmm, this looks like a backwards compatibility problem to me...
-Martin
Received: from cnri by ietf.org id aa12042; 19 Mar 97 12:21 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15643;
19 Mar 97 12:21 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <PAA28850 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 15:05:42 GMT
Message-Id: <9703191450.AA18088 at us1rmc.bb.dec.com>
Date: Wed, 19 Mar 97 09:50:49 EST
From: "John Wray, Digital DPE, 508/486-5210 19-Mar-1997 0945" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Comments solicited re negotiated mechanism action
Precedence: bulk
>I think this is true today, but (as noted above) there's no distinguished,
>architected means to differentiate the OID of a negotiating mechanism from
>a non-negotiating mechanism.
I don't think that's a problem. You wouldn't ask for a mechanism by name (OID)
if you didn't know something about the characteristics of that mechanism.
However, the top-level spec should perhaps include some text to explicitly
divide mechanisms into "negotiation mechanisms" and "true mechanisms"; the
former may select from mechanisms that support different (and possibly
non-intersecting) sets of name types, while the latter will always support the
set of name types defined in the corresponding mechanism spec. Also, you don't
have credential elements for negotiation mechanisms, only for true mechanisms.
This brings up an interesting question - what does gss_inquire_names_for_mech
return if presented with a negotiation mechanism OID?
John
Received: from cnri by ietf.org id aa12318; 19 Mar 97 12:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15961;
19 Mar 97 12:37 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA27399 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 14:26:18 GMT
Message-Id: <199703191423.JAA20558 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Martin.Rex at sap-ag.de
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, wray at tuxedo.enet.dec.com,
linn at cam.ov.com
Subject: Re: Comments solicited re negotiated mechanism action
In-Reply-To: Your message of "Tue, 18 Mar 1997 22:59:00 +0100."
<199703182159.AA11928 at sap-ag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 19 Mar 1997 09:23:39 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Martin, all, re:
> While this may sound good at first reading, it bears a lot of danger.
>
> As long as there are official "negotiation mechanisms" and an application
> asks for it, everything should work fine. But when a multi-mechanism
> implementation decides to chose Mech-A when the application actually
> has asked for Mech-B, then this will cause severe problems with ACLs
> based on exported names, because an exported name was defined to
> contain the mech_oid. I think it should rather fail than choose
> Mech-A when "true" Mech-B is requested but unavailable, and this error
> should always show up on the initiator side, not the acceptor side.
>
> Mechanism negotiation will become especially messy and error prone
> when the different mechanism use different native/canonical namespaces.
>
I'll note two points which bear on the question:
(1) there's no separate means for distinguishing a negotiating mechanism
from a non-negotiating mechanism other than by checking its OID and tracing
to the corresponding description; further,
(1a) no one specifying the OID of a non-negotiating mechanism should ever
receive a different OID as output, and
(1b) the actual OID is always available to the initiator, as an output
from GSS_Init_sec_context().
(2) it's possible that negotiation within a "mechanism family" where
different OIDs were used, e.g., to represent different cryptographic
choices under a particular technology would be fully safe in terms of
yielding compatible name forms
> It should definitely possible for an application to tell its gssapi
> mechanism to behave deterministic and skip all fancy mechanism negotiation,
> and I think this should definitely happen when an application *REQUESTS*
> a specific mechanism (behaviour) by using explicit mechanism OIDs for
> init_sec_context() on the initiator side and/or acquire_cred() on the
> acceptor side.
I think this is true today, but (as noted above) there's no distinguished,
architected means to differentiate the OID of a negotiating mechanism from
a non-negotiating mechanism.
>
> -Martin
>
--jl
Received: from cnri by ietf.org id aa15563; 19 Mar 97 14:37 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19141;
19 Mar 97 14:37 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA03797 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 17:03:21 GMT
Date: Wed, 19 Mar 1997 12:03:04 -0500
Message-Id: <9703191703.AA18049 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: linn at cam.ov.com, cat-ietf at mit.edu, wray at tuxedo.enet.dec.com
In-Reply-To: Martin Rex's message of Tue, 18 Mar 1997 22:59:00 +0100 (MEZ),
<199703182159.AA11928 at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Tue, 18 Mar 1997 22:59:00 +0100 (MEZ)
It should definitely possible for an application to tell its gssapi
mechanism to behave deterministic and skip all fancy mechanism negotiation,
and I think this should definitely happen when an application *REQUESTS*
a specific mechanism (behaviour) by using explicit mechanism OIDs for
init_sec_context() on the initiator side and/or acquire_cred() on the
acceptor side.
What do you mean by this? If the application requests negotiation, it
will be doing this by specifying a specific negotiation mechaism OID.
If what you mean is a statement to the effect that if an application
requests a specific mechanism, it MUST get that mechanism unless it is
specifically stated in its mechanism specification that this mechanism
engages in negotiation and therefore init_sec_context and
accept_sec_context may return a different mechanism than the one so
specified, I think that's a reasonable.
- Ted
Received: from cnri by ietf.org id aa16426; 19 Mar 97 15:19 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20010;
19 Mar 97 15:19 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA04289 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 17:16:22 GMT
Date: Wed, 19 Mar 1997 12:16:15 -0500
Message-Id: <9703191716.AA18085 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: linn at cam.ov.com, wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Wed, 19 Mar 1997 09:50:54 -0500 (EST),
<199703191451.AA12999 at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 19 Mar 1997 09:50:54 -0500 (EST)
compatible name forms in which respect. How does the mechanism family
interact with canonicalize_name() and export_name() ? It's not obvious
how to create an application-transparent mechanism family for GSS-API v2
in the way canonicalize_name() and export_name() are currently defined.
Hmmm, this looks like a backwards compatibility problem to me...
I don't think we have a problem with the concept of mechanism families
and canonicalize_name.
We do potentially have a problem with export_name(), but it's solvable
with the appropriate formal definition of mechanism families. I think
what we'd do is to indicate that a specific OID is considered the "head"
of the mechanism family, and further make the restriction that all
variants within a particular mechanism family are implemented using the
same implementation. This would then allow us to specify that in the
case of export_name(), the mechanim OID specified for export_name would
be the OID for the "head" of the mechanism family.
- Ted
Received: from cnri by ietf.org id aa17326; 19 Mar 97 15:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20646;
19 Mar 97 15:47 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA04548 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 17:22:34 GMT
Message-Id: <3.0.32.19970319092220.00a1f800 at comm.tandem.com>
X-Sender: kurn_david\comm at comm.tandem.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 19 Mar 1997 09:22:23 -0800
To: cat-ietf at mit.edu
From: David Kurn <kurn_david at tandem.com>
Subject: GSS API and Static Storage Redux
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
Folks
SOme time ago, I raised a question about the wisdom of having any GSS call
that returns a pointer to static storage. It appears that this issue
continues to haunt us. In a model where the implementation GSS involves a
static set of mechanisms, a built-in list is OK. It can be compiled in, or
alternately, can be dynamically built on first need and never changed.
However, as we look not very far down the road, it is easy to see any or
all of the following situations:
a) Memory models which do not permit (or where it would be unwise) to
return pointers into "protected" storage;
b) GSS mechanisms where the set of mechanisms is derived by a dynamic
inquiry of some other resource (such as asking a smart-card for a list of
its mechanisms, conversing with a crypto-engine to see what it can do ...)
c) Implementations where the mechanisms advertised are a function of the
user's permissions, the time of day, prior negotiations, or the severity of
the administrator's argument with her spouse that morning (READ: Humor).
I suggest that the designers of the GSS-API treat the return of a static
pointer (in version 1) as a definite BUG that needs fixing. For
compatibility, the following idea might work:
gss_indicate_mechs()
Continue to return a pointer to static storage. When your implementation
can no longer implement this honestly, one might produce a diagnostic and
abort the process. This, at least, would alert the developers that they
need to fix their program. (I expect to get flamed on this one).
Add a new procedure:
gss_show_mechs() or gss_indicate_dynamic_mechs()
which returns an OID-set which must be returned via
gss_release_oid_set
This new procedure should have extra return codes which allow the return of
errors such as:
- Some or all of the available mechanisms were temporarily unavailable
due to reasons in the Minor Status Code
- No storage available to build the list
- and so on
David Kurn
Tandem Computers Inc
Received: from cnri by ietf.org id aa18890; 19 Mar 97 16:45 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21953;
19 Mar 97 16:45 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA09256 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 19:22:07 GMT
Message-Id: <199703191921.OAA21843 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com, mbeaulie at ietf.org
Subject: CAT WG Memphis agenda, DRAFT 1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 19 Mar 1997 14:21:56 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT WG Memphis agenda, DRAFT 1 as of 19 March 1997
Agenda topics for (single) Memphis CAT session, Tuesday, 8 April 1997,
1300-1500.
1300-1305: Opening discussion
1305-1315: Ari Medvinsky: discussion re draft-ietf-cat-pktapp-00.txt
1315-1330: IDUP discussion
1330-1340: Discussion (if needed) to reconcile/resolve SNEGO WG
Last-Call results
1340-1350: Discussion (if needed) re FTPsec IETF Last-Call
1350-1400: Follow-up and advancement plans for current RFCs:
- RFC-1510 [Kerberos]
- RFC-1964 [Kerberos V5 GSS-API Mechanism]
- RFC-2025 [SPKM]
- RFC-2078 [GSS-V2]
1400-1430: GSS-V2 C Bindings discussion
1430-1500: [Additional discussion, as needed.]
--jl
Received: from cnri by ietf.org id aa20484; 19 Mar 97 17:35 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23227;
19 Mar 97 17:35 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <UAA11884 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 20:25:36 GMT
Date: Wed, 19 Mar 1997 15:25:03 -0500
Message-Id: <9703192025.AA18297 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin Rex <martin.rex at sap-ag.de>
Cc: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Wed, 19 Mar 1997 20:57:41 +0100,
<199703191957.UAA09895 at p18509.wdf.sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 19 Mar 1997 20:57:41 +0100
From: Martin Rex <martin.rex at sap-ag.de>
If different vendors build (different) Kerberos5 mechanism families,
which "head" should they use? AFAIK there are different solutions
to export control today). Which mechanism OID should be passed
to canonicalize_name() to populate an ACL? What else has to be defined
so that one can replace Kerberos5 from Vendor A with the version
from Vendor B without having to repopulate ACLs or having to disable
mech-family negotiation?
This is something which has to be standardized and specified in a
mechanism specification, just as mechanism OID are specified in a
mechanism specification. It can't be a per-vendor thing. So if we
wanted to do this with Kerberos (for example), we'd have to issue a
follow-on document to RFC-1964 which defined a new head mechanism OID
for Kerberos as
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5-head-mech(3)}
And then we might define Kerberos with single DES to be:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5-head-mech(3) krb5-des-md5(1)}
... and Kerberos with triple DES to be:
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5-head-mech(3) krb5-3des-md5(2)}
etc.
We could then specify that the head mechanism would do its own simple
negotiation when passed to init_sec_context_context and
accept_sec_context; perhaps based on snego, but constraining the result
of the negotiation to be a descendent of the Kerberos mechanism.
(Note: this is something that obviously need further design; what I've
just sketched out I've done completely off the top of my head. If we're
serious about proceeding on this front, a much more careful and formal
design would need to be done.)
Whatever you work out, how does this affect the negotiation of
mechanisms from non-intersecting namespaces, where each mechanism
refers to an independent user management? If someone implements a
Kerberos5 + SPKM mechanism with negotiation, how will you treat this
negotiation OID in respect to canonicalize_name() to populate ACLs?
You shouldn't call the negotiation OID to canonicalize_name. Presumably
canonalize_name would return GSS_S_BAD_NAMETYPE, since you can't
canonicalize any name type with respect to the negotiation OID. The
administrator would have to pass either the Kerberos 5 or SPKM mechanism
ID to to canoncalize_name in order to get a usable name, which will be
in the correct namespace at that point.
- Ted
Received: from cnri by ietf.org id aa21747; 19 Mar 97 18:20 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24300;
19 Mar 97 18:20 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA10711 at pad-thai.cam.ov.com>; Wed, 19 Mar 1997 19:58:23 GMT
Date: Wed, 19 Mar 1997 20:57:41 +0100
Message-Id: <199703191957.UAA09895 at p18509.wdf.sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
To: tytso at mit.edu
Cc: cat-ietf at mit.edu
Subject: Re: Comments solicited re negotiated mechanism action
Precedence: bulk
Theodore Ts'o wrote:
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Tue, 18 Mar 1997 22:59:00 +0100 (MEZ)
>
> It should definitely possible for an application to tell its gssapi
> mechanism to behave deterministic and skip all fancy mechanism negotiation,
> and I think this should definitely happen when an application *REQUESTS*
> a specific mechanism (behaviour) by using explicit mechanism OIDs for
> init_sec_context() on the initiator side and/or acquire_cred() on the
> acceptor side.
>
> What do you mean by this? If the application requests negotiation, it
> will be doing this by specifying a specific negotiation mechanism OID.
I would assume that negotiating multi-mech implementors will want to
use the negotiation mechanism as their default mechanism; which is
what "portable" applications are supposed to use.
>
> If what you mean is a statement to the effect that if an application
> requests a specific mechanism, it MUST get that mechanism unless it is
> specifically stated in its mechanism specification that this mechanism
> engages in negotiation and therefore init_sec_context and
> accept_sec_context may return a different mechanism than the one so
> specified, I think that's a reasonable.
That's what I meant.
Theodore Ts'o wrote:
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Wed, 19 Mar 1997 09:50:54 -0500 (EST)
>
> compatible name forms in which respect. How does the mechanism family
> interact with canonicalize_name() and export_name() ? It's not obvious
> how to create an application-transparent mechanism family for GSS-API v2
> in the way canonicalize_name() and export_name() are currently defined.
> Hmmm, this looks like a backwards compatibility problem to me...
>
> I don't think we have a problem with the concept of mechanism families
> and canonicalize_name.
>
> We do potentially have a problem with export_name(), but it's solvable
> with the appropriate formal definition of mechanism families. I think
> what we'd do is to indicate that a specific OID is considered the "head"
> of the mechanism family, and further make the restriction that all
> variants within a particular mechanism family are implemented using the
> same implementation. This would then allow us to specify that in the
> case of export_name(), the mechanim OID specified for export_name would
> be the OID for the "head" of the mechanism family.
The basic idea sounds good to me.
If this proposal is accepted, it will need to be added to the
RFC2078 update, Section 3.2.
If different vendors build (different) Kerberos5 mechanism families,
which "head" should they use? AFAIK there are different solutions
to export control today). Which mechanism OID should be passed
to canonicalize_name() to populate an ACL? What else has to be defined
so that one can replace Kerberos5 from Vendor A with the version
from Vendor B without having to repopulate ACLs or having to disable
mech-family negotiation?
What about the usage of the "negotiation" mech-OID for other calls
like canonicalize_name(), acquire_cred(), add_cred(), etc. ?
Must it be included in the returned oid_set from indicate_mechs()?
IMO, the concept of only-partly-usable mechanism OIDs isn't backed
by the current spec.
Whatever you work out, how does this affect the negotiation of
mechanisms from non-intersecting namespaces, where each mechanism
refers to an independent user management? If someone implements a
Kerberos5 + SPKM mechanism with negotiation, how will you treat this
negotiation OID in respect to canonicalize_name() to populate ACLs?
-Martin
Received: from ietf.org by ietf.org id aa14785; 20 Mar 97 10:15 EST
Received: from ietf.ietf.org by ietf.org id aa13666; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-run at mailbag.intel.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-run-spew-00.txt
Date: Thu, 20 Mar 1997 09:56:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13666 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Responsible Use of the
Network Working Group of the IETF.
Title : DON'T SPEW
A Set of Guidelines for Mass Unsolicited Mailings
and Postings
Author(s) : S. Hambridge
Filename : draft-ietf-run-spew-00.txt
Pages : 6
Date : 03/19/1997
This document provides explains why mass unsolicited electronic mail
messages are not useful in the Internetworking community. It gives a set
of guidelines for dealing with unsolicited mail for users, for system
administrators, news administrators, and mailing list managers. It also
makes suggestions Internet Service Providers might follow.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-run-spew-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-run-spew-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-run-spew-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319133345.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-run-spew-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-run-spew-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319133345.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15230; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13847; 20 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-masinter-url-data-03.txt
Date: Thu, 20 Mar 1997 09:57:07 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200957.aa13847 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The "data" URL scheme
Author(s) : L. Masinter
Filename : draft-masinter-url-data-03.txt
Pages : 3
Date : 03/19/1997
A new URL scheme, "data", is defined. It allows inclusion of small data
items as "immediate" data, as if it had been included externally.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-masinter-url-data-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-masinter-url-data-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-masinter-url-data-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319171107.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-masinter-url-data-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-masinter-url-data-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319171107.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15229; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13665; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-otp at bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-otp-01.txt
Date: Thu, 20 Mar 1997 09:56:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13665 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the One Time Password
Authentication Working Group of the IETF.
Title : A One-Time Password System
Author(s) : N. Haller, C. Metz, P. Nesser, M. Straw
Filename : draft-ietf-otp-01.txt
Pages : 22
Date : 03/19/1997
This document describes a one-time password authentication system (OTP).
The system provides authentication for system access (login) and other
applications requiring authentication that is secure against passive
attacks based on replaying captured reusable passwords. OTP evolved from
the S/KEY* One-Time Password System that was released by Bellcore and is
described in references [3] and [5].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-otp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-otp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-otp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319115323.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-otp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-otp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319115323.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15244; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13724; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-fax at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-fax-tiffplus-00.txt
Date: Thu, 20 Mar 1997 09:56:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13724 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Fax Working Group
of the IETF.
Title : File Format for Internet Fax
Author(s) : L. McIntyre, S. Zilles
Filename : draft-ietf-fax-tiffplus-00.txt
Pages : 43
Date : 03/19/1997
This Internet Draft describes the TIFF representation of the image data
specified by the ITU-T Recommendations and proposals for black-and-white
and color facsimile. For the most part, existing TIFF constructs and fields
are used; new TIFF fields are introduced only when necessary.
Black-and-white facsimile is already described by TIFF Class F, and this
Draft builds on that to add color fax capability and to establish a
structure for future enhancements.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-fax-tiffplus-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-fax-tiffplus-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-fax-tiffplus-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319142823.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-fax-tiffplus-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fax-tiffplus-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319142823.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15237; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13623; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: spki at c2.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-spki-cert-req-00.txt
Date: Thu, 20 Mar 1997 09:56:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13623 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Public Key
Infrastructure Working Group of the IETF.
Title : SPKI Requirements
Author(s) : C. Ellison
Filename : draft-ietf-spki-cert-req-00.txt
Pages : 17
Date : 03/19/1997
The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked
with producing a certificate structure and operating procedure to meet the
needs of the Internet community for trust management in as easy, simple and
extensible a way as possible.
The SPKI WG first established a list of things one might want to do with
certificates (attached at the end of this document), and then summarized
that list of desires into requirements. This document presents that
summary of requirements.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-spki-cert-req-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-req-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-spki-cert-req-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319114219.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-spki-cert-req-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-spki-cert-req-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319114219.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15242; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13795; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-state-man-mec-00.txt, .ps
Date: Thu, 20 Mar 1997 09:56:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13795 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : HTTP State Management Mechanism (Rev1)
Author(s) : D. Kristol, L. Montulli
Filename : draft-ietf-http-state-man-mec-00.txt, .ps
Pages : 21
Date : 03/19/1997
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and
Set-Cookie2, which carry state information between participating origin
servers and user agents. The method described here differs from Netscape's
Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use
Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109
and obsoletes it.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-state-man-mec-00.txt".
Or
"get draft-ietf-http-state-man-mec-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-man-mec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-state-man-mec-00.txt".
Or
"FILE /internet-drafts/draft-ietf-http-state-man-mec-00.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319163926.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-state-man-mec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-state-man-mec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319163926.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15236; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13691; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-avt-rtp-payload-03.txt
Date: Thu, 20 Mar 1997 09:56:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13691 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Audio/Video Transport
Working Group of the IETF.
Title : RTP Payload Format for H.263 Video Streams
Author(s) : C. Zhu
Filename : draft-ietf-avt-rtp-payload-03.txt
Pages : 10
Date : 03/19/1997
This document specifies the payload format for encapsulating an H.263
bitstream in the Real-Time Transport Protocol (RTP). Three modes are
defined for the H.263 payload header. An RTP packet can use one of the
three modes for H.263 video streams depending on the desired network packet
size and H.263 encoding options employed. The shortest H.263 payload
header (mode A) supports fragmentation at Group of Block (GOB) boundaries.
The long H.263 payload headers (mode B and C) support fragmentation at
Macroblock (MB) boundaries.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-avt-rtp-payload-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-payload-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-avt-rtp-payload-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319134105.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-payload-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-rtp-payload-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319134105.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15254; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13568; 20 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-carpenter-ipng-6over4-01.txt
Date: Thu, 20 Mar 1997 09:55:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200955.aa13568 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels
Author(s) : B. Carpenter, C. Jung
Filename : draft-carpenter-ipng-6over4-01.txt
Pages : 11
Date : 03/19/1997
This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over IPv4
"domains". For the purposes of this document, an IPv4 domain is a fully
interconnected set of IPv4 subnets on which there is at least one IPv6
router and at least one IPv6 host conforming to this specification. This
IPv4 domain could form part of the globally unique IPv4 address space, or
could form part of a private IPv4 network [RFC 1918].
This memo also specifies the content of the Source/Target Link-layer
Address option used in the Router Solicitation, Router Advertisement,
Neighbor Solicitation, and Neighbor Advertisement messages described in
[DISC], when those messages are transmitted on an IPv4 domain.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-carpenter-ipng-6over4-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-carpenter-ipng-6over4-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-carpenter-ipng-6over4-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319103359.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-carpenter-ipng-6over4-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-carpenter-ipng-6over4-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319103359.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15243; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13761; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-berger-rsvp-ext-07.txt
Date: Thu, 20 Mar 1997 09:56:43 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13761 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RSVP Extensions for IPSEC Data Flows
Author(s) : L. Berger, T. O'Malley
Filename : draft-berger-rsvp-ext-07.txt
Pages : 16
Date : 03/19/1997
This document presents extensions to Version 1 of RSVP. These extensions
permit support of individual data flows using RFC 1826 IP Authentication
Header (AH) or RFC 1827 IP Encapsulating Security Payload (ESP). RSVP
Version 1 as currently specified can support the IPSEC protocols, but only
on a per address, per protocol basis not on a per flow basis. The
presented extensions can be used with both IPv4 and IPv6.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-berger-rsvp-ext-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-berger-rsvp-ext-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-berger-rsvp-ext-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319163109.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-berger-rsvp-ext-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-berger-rsvp-ext-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319163109.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15248; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13811; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-shiroshita-rmtp-spec-00.txt
Date: Thu, 20 Mar 1997 09:56:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13811 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Reliable Multicast Transport Protocol
Author(s) : T. Shiroshita, T. Sano, O. Takahashi, N. Yamanouchi
Filename : draft-shiroshita-rmtp-spec-00.txt
Pages : 45
Date : 03/19/1997
This draft presents the specifications of the "Reliable Multicast
Transport Protocol," which is used for information delivery such as
newspaper delivery and software updates. The protocol aims to realize
a full reliable multicast of bulk data from a server to thousands of
receivers. Scalability of the protocol, flow/congestion control
extension, and security issues are described as an addendum for
the protocol specifications.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-shiroshita-rmtp-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-shiroshita-rmtp-spec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-shiroshita-rmtp-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319170225.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-shiroshita-rmtp-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-shiroshita-rmtp-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319170225.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15256; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13622; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: spki at c2.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-spki-cert-structure-00.txt
Date: Thu, 20 Mar 1997 09:56:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13622 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Public Key
Infrastructure Working Group of the IETF.
Title : Simple Public Key Certificate
Author(s) : C. Ellison, W. Frantz, B. Thomas
Filename : draft-ietf-spki-cert-structure-00.txt
Pages : 52
Date : 03/19/1997
With the proliferation of public key cryptography on the Internet, there
arises a need for certification of keys. In the literature, the word
"certificate" is generally taken to mean "identity certificate" -- a signed
statement which binds a key to the name of an individual and has the
intended meaning of delegating authority from that named individual to the
public key. (See, for example, RFC 1422).
Establishing identity is not the problem of interest. A process
using public key authentication (telnet, ftp, an electronic
commerce server, etc.), and verifying a public key certificate
in the process, needs to check that the indicated key
(i.e., the key holder) has authority to access the controlled data or
perform the requested function.
An SPKI certificate is an authorization certificate. It grants
a specific authority to a public key rather than binding
an "identity" (such as a person's name) to that key. For example,
one SPKI certificate might grant permission for a given public key to
authenticate logins over TELNET as user CME on host CYBERCASH.COM for some
period of time.
For completeness, SPKI certificates are defined below which grant
"all authority of the indicated person" to a key -- and are therefore
identity certificates -- but it is not clear that those will be needed.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-spki-cert-structure-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-structure-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-spki-cert-structure-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319113647.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-spki-cert-structure-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-spki-cert-structure-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319113647.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15258; 20 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa13779; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bates-bgp4-multiprotocol-01.txt
Date: Thu, 20 Mar 1997 09:56:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13779 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Multiprotocol Extensions for BGP-4
Author(s) : T. Bates, R. Chandra, D. Katz, Y. Rekhter
Filename : draft-bates-bgp4-multiprotocol-01.txt
Pages : 9
Date : 03/19/1997
Currently BGP-4 [BGP-4] is capable of carrying routing information only for
IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to
carry routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, etc...). The extensions are backward compatible - a router that
supports the extensions can interoperate with a router that doesn't support
the extensions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-bates-bgp4-multiprotocol-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bates-bgp4-multiprotocol-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bates-bgp4-multiprotocol-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319163414.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bates-bgp4-multiprotocol-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bates-bgp4-multiprotocol-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319163414.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15266; 20 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa13552; 20 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-idmr-pim-sm-spec-10.txt, .ps
Date: Thu, 20 Mar 1997 09:55:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200955.aa13552 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification
Author(s) : D. Estrin, D. Farinacci, A. Helmy , D. Thaler,
S. Deering, M. Handley, V. Jacobson, C. Liu,
P. Sharma , L. Wei
Filename : draft-ietf-idmr-pim-sm-spec-10.txt, .ps
Pages : 73
Date : 03/19/1997
This document describes a protocol for efficiently routing to multicast
groups that may span wide-area (and inter-domain) internets. We refer to
the approach as Protocol Independent Multicast--Sparse Mode (PIM-SM)
because it is not dependent on any particular unicast routing protocol, and
because it is designed to support sparse groups as defined in [1][2].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-idmr-pim-sm-spec-10.txt".
Or
"get draft-ietf-idmr-pim-sm-spec-10.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-sm-spec-10.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-10.txt".
Or
"FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-10.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319095831.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-sm-spec-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-sm-spec-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319095831.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15263; 20 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa13898; 20 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-dirnaming-01.txt
Date: Thu, 20 Mar 1997 09:57:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200958.aa13898 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Directory
Services Working Group of the IETF.
Title : Naming Plan for an Internet Directory Service
Author(s) : A. Grimstad, R. Huber, S. Sataluri,
S. Kille, M. Wahl
Filename : draft-ietf-ids-dirnaming-01.txt
Pages : 15
Date : 03/19/1997
Application of the conventional X.500 approach to naming has, in the
experience of the authors, proven to be an obstacle to the creation of
directory services. We propose a new directory naming plan that leverages
the strengths of the most popular and successful Internet naming schemes
for naming objects in a hierarchical directory. This plan can, we believe,
facilitate the creation of an Internet White Pages Service (IWPS) and other
directory-enabled applications by overcoming the problems encountered by
those using the conventional recommended X.500 approach to naming.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ids-dirnaming-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dirnaming-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-dirnaming-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319173839.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-dirnaming-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-dirnaming-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319173839.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15270; 20 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa13745; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-warning-00.txt
Date: Thu, 20 Mar 1997 09:56:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13745 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Problem with HTTP/1.1 Warning header, and proposed fix
Author(s) : J. Mogul, A. Luotonen
Filename : draft-ietf-http-warning-00.txt
Pages : 13
Date : 03/19/1997
The current HTTP/1.1 (RFC2068) specification introduces a new "Warning"
header, meant to carry status information about a request that cannot or
should not be carried by the response status code. The existing
specification for the interaction between Warning and HTTP caches is
faulty, in that it may allow incorrect results after cache validation
operations. This document identifies two separate (but related) problems,
and proposes revisions of the HTTP/1.1 specification to solve these
problems.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-warning-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-warning-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-warning-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319145459.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-warning-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-warning-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319145459.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15249; 20 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa13621; 20 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-uahint-00.txt
Date: Thu, 20 Mar 1997 09:55:55 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200956.aa13621 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : The User Agent Hint Response Header
Author(s) : D. Morris
Filename : draft-ietf-http-uahint-00.txt
Pages : 10
Date : 03/19/1997
This document proposes a HTTP response header called UA-Hint, which can be
used by applications (servers) to describe handling hints which will allow
user agents to more accurately reflect the intent of the web application
designer for the handling and presentation of the response entity. The
UA-Hint header is intended to be an extensible general mechanism by which
the application can suggest user agent behaviors which alter or extend the
behaviors specified in HTTP/1.1 (RFC 2068) with the express purpose of
improving the usability of the resulting application. Intended
considerations include enablement of safe POST and refined handling of the
traditional history buffer.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-uahint-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-uahint-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-uahint-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319105500.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-uahint-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-uahint-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319105500.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15261; 20 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa13827; 20 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-masinter-form-data-00.txt
Date: Thu, 20 Mar 1997 09:57:04 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703200957.aa13827 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Returning Values from Forms: multipart/form-data
Author(s) : L. Masinter
Filename : draft-masinter-form-data-00.txt
Pages : 3
Date : 03/19/1997
This specification defines an Internet Media Type, multipart/form-data,
which can be used by a wide variety of applications and transported by a
wide variety of protocols as a way of returning a set of values as the
result of a user filling out a form. Typical applications include form
values generated by HTML forms and submitted by HTTP post or by electronic
mail, but the format is independent of those contexts. The definition of
multipart/form-data is derived from its original definition in RFC 1867.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-masinter-form-data-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-masinter-form-data-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-masinter-form-data-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970319170758.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-masinter-form-data-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-masinter-form-data-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970319170758.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa20029; 20 Mar 97 11:18 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12491;
20 Mar 97 11:18 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <OAA15761 at pad-thai.cam.ov.com>; Thu, 20 Mar 1997 14:08:18 GMT
Message-Id: <9703201403.AA07682 at us1rmc.bb.dec.com>
Date: Thu, 20 Mar 97 09:03:50 EST
From: "John Wray, Digital DPE, 508/486-5210 20-Mar-1997 0858" <wray at tuxedo.enet.dec.com>
To: kurn_david at tandem.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, kurn_david at tandem.com
Subject: RE: GSS API and Static Storage Redux
Precedence: bulk
David Keurn writes:
>SOme time ago, I raised a question about the wisdom of having any GSS call
>that returns a pointer to static storage. It appears that this issue
>continues to haunt us. In a model where the implementation GSS involves a
>static set of mechanisms, a built-in list is OK. It can be compiled in, or
>alternately, can be dynamically built on first need and never changed.
>
>However, as we look not very far down the road, it is easy to see any or
>all of the following situations:
>
>a) Memory models which do not permit (or where it would be unwise) to
>return pointers into "protected" storage;
>
>b) GSS mechanisms where the set of mechanisms is derived by a dynamic
>inquiry of some other resource (such as asking a smart-card for a list of
>its mechanisms, conversing with a crypto-engine to see what it can do ...)
>
>c) Implementations where the mechanisms advertised are a function of the
>user's permissions, the time of day, prior negotiations, or the severity of
>the administrator's argument with her spouse that morning (READ: Humor).
>
>I suggest that the designers of the GSS-API treat the return of a static
>pointer (in version 1) as a definite BUG that needs fixing. For
>compatibility, the following idea might work:
>
>gss_indicate_mechs()
> Continue to return a pointer to static storage. When your implementation
>can no longer implement this honestly, one might produce a diagnostic and
>abort the process. This, at least, would alert the developers that they
>need to fix their program. (I expect to get flamed on this one).
>
>Add a new procedure:
>
>gss_show_mechs() or gss_indicate_dynamic_mechs()
> which returns an OID-set which must be returned via
>gss_release_oid_set
>
>This new procedure should have extra return codes which allow the return of
>errors such as:
>
> - Some or all of the available mechanisms were temporarily unavailable
>due to reasons in the Minor Status Code
> - No storage available to build the list
> - and so on
In the latest draft of the V2 C-bindings (submitted to the ID editor
yesterday), gss_indicate_mechs() returns a dynamic OID-set. Indeed, all
OID-sets returned by GSSAPI are now dynamic.
We discussed this on the list a few weeks ago, and decided that a typical V1
app is only going to invoke gss_indicate_mechs() once, so if we introduced a
memory leak for such an application it probably wouldn't be a problem for the
vast majority of applications, so we can live with this minor incompatibility.
As things stand, all OID-sets are dynamically allocated, while all stand-alone
OIDs are static objects. I'd like to make OIDs dynamic too, but that's likely
to break too many applications, and for the API calls that the V2 GSSAPI
provides, there's nothing that absolutely requires dynamic OIDs.
John
Received: from ietf.org by ietf.org id aa27111; 20 Mar 97 13:19 EST
Received: from ietf.ietf.org by ietf.org id aa26995; 20 Mar 97 13:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-clark-telnet-control-01.txt
Date: Thu, 20 Mar 1997 13:17:31 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703201317.aa26995 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Telnet Comport Control Option
Author(s) : G. Clark
Filename : draft-clark-telnet-control-01.txt
Pages : 10
Date : 03/19/1997
This memo proposes a protocol to allow greater use of modems attached to a
network. Increased needs for "off network" communications has increased the
need for modems. Increasing the functionality of Telnet increases the
functionality of network attached modems. For example, the ability to send
a FAX via a network attached modem. This memo addresses configuration of
the comport to which the modem is attached. It does not address the
internal configuration of the modem itself.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-clark-telnet-control-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-clark-telnet-control-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-clark-telnet-control-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320131631.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-clark-telnet-control-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-clark-telnet-control-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320131631.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa28297; 20 Mar 97 13:49 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15958;
20 Mar 97 13:49 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <QAA23121 at pad-thai.cam.ov.com>; Thu, 20 Mar 1997 16:55:37 GMT
Message-Id: <199703201655.AA05496 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Thu, 20 Mar 1997 11:55:08 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703192025.AA18297 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 19, 97 03:25:03 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
> Whatever you work out, how does this affect the negotiation of
> mechanisms from non-intersecting namespaces, where each mechanism
> refers to an independent user management? If someone implements a
> Kerberos5 + SPKM mechanism with negotiation, how will you treat this
> negotiation OID in respect to canonicalize_name() to populate ACLs?
>
> You shouldn't call the negotiation OID to canonicalize_name. Presumably
> canonalize_name would return GSS_S_BAD_NAMETYPE, since you can't
> canonicalize any name type with respect to the negotiation OID. The
> administrator would have to pass either the Kerberos 5 or SPKM mechanism
> ID to to canoncalize_name in order to get a usable name, which will be
> in the correct namespace at that point.
What I acutally wanted to ask for: How does a "portable" application
that wants to use ACLs based on exported names how to populate this ACL?
I.e. how many and which "true" mechanisms are available, and how
many entries need to go into the ACL for each user?
I currently only have provisions for exactly one "canonical" exported name;
so if a customer wants to replace a single-mechanism or mechanism family
with a multi-mechanism sort of like kerberos + spkm, I will have to supply
a mechanism OID to disable negotiation so that the existing ACL will
continue to work.
This makes the extra functionality of the negotiating multi-mechanism
effectively useless ...
I'm open for easy-to-implement and straigthforward proposals to
improve my usage. :-)
-Martin
Received: from cnri by ietf.org id aa00699; 20 Mar 97 15:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17593;
20 Mar 97 15:08 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <RAA25825 at pad-thai.cam.ov.com>; Thu, 20 Mar 1997 17:58:03 GMT
Message-Id: <9703201740.AA26943 at us1rmc.bb.dec.com>
Date: Thu, 20 Mar 97 12:40:37 EST
From: "John Wray, Digital DPE, 508/486-5210 20-Mar-1997 1130" <wray at tuxedo.enet.dec.com>
To: "cadams at entrust.com"@in.enet.dec.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, cadams at entrust.com
Subject: IDUP-GSS-API
Precedence: bulk
Carlisle,
I apologise for sending extensive comments at such a late stage, but I've
recently been doing some IDUP-related work and found the following issues with
the -06 draft of the IDUP spec.
1) Protection service complexity
There seems to be considerable complexity due to overloading the semantics
of the IDUP_Start_Protect call to deal with several distinct protection models:
a) Incremental protection (i.e. passing large data to IDUP_Protect() in chunks)
vs single-buffer protection (using IDUP_Start_Protect() to do everything in
a single call)
b) Encapsulation vs seperate data & signature-token.
c) Handling of data-protection, receipt-generation and receipt-solicitation
as variants of a basic "protect" service.
<META-COMMENT>
This is probably an effect of the heavy use of the parameter bundle
construct, which I find very programmer-unfriendly. I'd far rather
program to an interface that has more but simpler calls, compared to
an API that has a small number of highly overloaded functions, with
lots of parameters that are significant only for subsets of those
overloaded purposes (even if those many parameters are disguised
within bundles).
While the use of bundles may be merely descriptive within this
specification, and not necessarily intended to be reflected in
language bindings, the comment on page 23 implies that they are
intended to map more-or-less directly to programming language
constructs.
The use of parameter bundles gives me a real feeling of deja-vu: it
looks very like the OMG way of presenting arbitary object data to
a small set of overloaded APIs in the XOM and XDS APIs, and I don't
think that XOM/XDS is a precedent that we want to follow.
</META-COMMENT>
It would be make for a much simpler programming interface to provide distinct
entrypoints for these different protection functions. For example, use the
sequence "IDUP_Start_Protect(); N * IDUP_Protect_Chunk(); IDUP_End_Protect()"
to protect chunked data, and the sequence "IDUP_Protect()" to protect a datum
presented in a single chunk.
The encapsulation vs seperate data & token problem is more complicated, and I
don't understand from the current spec how this is supposed to be handled.
According to page 3, if the application is using a non-encapsulating mechanism,
then it's up to it how it combines the M-IDU and token to form a P-IDU, so long
as the receiving application knows how to split the M-IDU and token apart once
again. But according to the documentation for IDUP_Start_Unprotect(), the
M-IDU can be presented in the single_data_buffer parameter (assuming you're not
chunking on the receive side). and there's no place to present the token.
Example B.2 should illustrate what to do in this case, but it doesn't discuss
how the protection token would be handled if the receiver chooses not to chunk
the data. It might be that the receiver is supposed to concatentate the M-IDU
and the token, but if so this should be stated explicitly (there seems to be
some terminology confusion here, anyway - IDUP_End_Protect has an output
parameter "final_midu_buffer" for use only when not encapsulating, which I
presume this is where the protection token is delivered; however page 3 asserts
that the token and the M-IDU are different entities). Anyway, the receiver is
likely to want to be given the token up-front (as it'll probably contain
cryptographic initialization data that'll be needed in order to process the
M-IDUs).
Why not follow the example of GSSAPI here, and have two families of calls, one
to handle the encapsulating case, and one to handle the seperate data & token
scenario (like gss_wrap & gss_get_mic). If you use "_Protect_" to mean
the non-encapsulated family, and "_Wrap_" to mean the encapsulating family,
you'd have something like the following:
A) Encapsulating, non-chunked case
Transmitter:
IDUP_Wrap(IDU) -> token
Receiver:
IDUP_Unwrap(token) -> IDU
B) Non-encapsulating, non-chunked case
Transmitter:
IDUP_Protect(IDU) -> token, MIDU
Receiver:
IDUP_Unprotect(token, MIDU) -> IDU
C) Encapsulating, chunked case
Transmitter:
IDUP_Start_Wrap()
IDUP_Wrap_Chunk(IDU-chunk) -> token-chunk
IDUP_Wrap_Chunk(IDU-chunk) -> token-chunk
...
IDUP_End_Wrap() -> token-chunk
Receiver:
IDUP_Start_Unwrap(token-chunk)
IDUP_Unwrap_Chunk(token-chunk) -> IDU-chunk
IDUP_Unwrap_Chunk(token-chunk) -> IDU-chunk
...
IDUP_End_Unwrap() -> IDU-chunk
D) Non-encapsulating, chunked case
Transmitter:
IDUP_Start_Protect()
IDUP_Protect_Chunk(IDU-chunk) -> MIDU-chunk
IDUP_Protect_Chunk(IDU-chunk) -> MIDU-chunk
...
IDUP_End_Protect() -> token, MIDU-chunk
Receiver:
IDUP_Start_Unprotect(token)
IDUP_Unprotect_Chunk(MIDU-chunk) -> IDU-chunk
IDUP_Unprotect_Chunk(MIDU-chunk) -> IDU-chunk
...
IDUP_End_Unprotect() -> IDU-chunk
(As per the current ID, chunking at transmitter doesn't have
to imply chunking at receiver - Receiver and transmitter can
each decide independently whether or not to chunk data, and
even if both decide to chunk, they can break up the stream of
token data into chunks independently. This implies that
not every chunk presented to, say, IDUP_Wrap_Chunk need
result in a token-chunk, since if confidentiality protection
is being applied, token-chnks will presumably be emitted in
multiples of the underlying crypt block-size, and the input
chunk may be smaller than that size. The comment on page
29 about a zero-length output_buffer being permitted only
when data is being encapsulated should be broadened to allow
for this case during non-encapsulating protection too).
The asymmetry in the handling of the token (i.e. generated by End_Protect but
consumed by Start_Unprotect) in the last above example is a bit bothersome. In
general, the token's going to be needed by the Start_Unprotect() call, as it
probably includes crypto keying and other initialization data that will be
needed in order to make any sense of the MIDU chunks, but it will also probably
contain a MIC that won't be calculable by the transmitter until End_Protect()
completes). This means that the token has to logically "overtake" the data,
which may be difficult in some applications. For example, say I'm building a
file encryption program using IDUP. If I want to use a non-encapsulating
method, it seems like I have to either know the maximum size that the token
could possibly take up (so I can reserve space for it at the start of my target
file), or append it after the MIDU data and reserve space for a pointer at the
start of my file to say where the MIDU ends and the token begins (so that the
decrypt program can process the token first). I guess I could dump my MIDU
chunks into a temp file, and then append this file to the target file, after
having written the token into the target file, but this seems very messy.
I can't think of a better way to do things, although perhaps an output from
IDUP_Start_Protect (or obtainable by an environment inquiry after this call)
that gives the maximum size of the final token would allow me to reserve the
correct amount of space in front of the MIDU chunks.
Incidentally, the -06 draft mentions a couple of file
protection/unprotection routines on page 11, but never defines
them. I think the chunked variants on the regular protect calls
should be good enough to handle file encryption, and would like to
see these file-specific routines removed completely (which might have
been the intent anyway).
The above has so far only addressed type-1 protection services (services that a
data originator would invoke to protect that data). Verifying a receipt and
generating a solicited receipt should probably use a different API.
Overloading IDUP_Protect just seems to confuse things.
_Requesting_ a receipt has to be included in the Protect() families, e.g.
something like:
IDUP_Start_Protect(
Targets: SET OF target-info,
[various other mandatory parameters including environment],
Receipts-requested: OPTIONAL SET OF receipt-info)
where receipt-info is a parameter bundle that indentifies the recipient from
whom a recipt is requested, and possibly other information pertaining to the
desired format or properties of the receipt. Omitting the parameter would
imply no receipts are desired. This seems easier to program to than hiding
the recipients within the services_to_perform bundle.
Generation and verifiation of receipts could be performed by new routines:
IDUP_Generate_Receipt(environment) -> token
IDUP_Verify_Receipt(environment, token)
(although in the above calls, "environment" should really be a
"protection-context" - see below).
I'm not sure quite what model you're assuming for receipts. The
current spec doesn't seem to handle third-party generated receipts,
nor does it seem to support (much) later verification of receipts
(other than perhaps by re-processing the original protected data).
Perhaps a Protect operation for which receipts are requested should
also generate a local token, which is supposed to be stored by the
transmitter so that at a later date it can be used to verify a receipt.
The SE family of calls take an approach more like the above, although they
still seem slightly more complex than they need to be (see below - *). I don't
really see the advantage of having the lower-level complex API as well. It's
possible to add routines (like the Generate/Verify_Receipt calls above) to
fill-in the missing functionality of the current SE calls, and (I believe) make
them close enough in functionality to the current low-level API without the
complexity.
* - One place where the SE family still seems more complex than necessary is
in the use of parameter bundles to specify the target info. The
IDUP_SE_SingleBuffer_Protect call, for example, takes a single parameter
bundle that indicates both the input set of desired target names, and
also contains space for a returned set of status parameters to receive
errors about any names that were invalid, or for which the data couldn't
be protected. While I realise that this is a high-level spec, and that
an actual bindings document could probably seperate these into two
distinct parameters, I think it's far better even at this level to keep
input parameters seperate from output parameters rather than grouping
them in a single parameter bundle just because they are both related
to target names.
If option (i) below is adopted, then detailed error information
doesn't have to be returned by a Protect family routines, but could
be extracted later by an explicit inquiry call against the protection
context.
2) Environments and multiple protection operations
In addition to the environment object, I think you also need a state object
that links together multi-buffer (chunked) Protect/Unprotect operations. The
environment object seems to be fairly heavy-weight, and it seems to be intended
to span multiple protect operations (it's sort-of analagous to a GSSAPI
credential).
However, if I want to perform multiple multi-buffer (chunked) protect
operations (perhaps in different threads, or perhaps simply interleaved within
a single thread) it looks like I have to establish a distinct environment for
each series of operations. If so, this is a problem, and we need either:
i) A seperate "protection-context" object that describes an ongoing
Protect/Unprotect (or Wrap/Unwrap) operation (which would be the thing that's
queried about the results of such an operation, and which could also link a
Protect or Wrap operation with any receipts for the protected data), or
ii) An assertion that an environment is a lightweight object that should in
general span only a single protection operation, and a routine to clone an
environment so that multiple Protection operations can be performed
simultaneously without interfering with one another.
I'd much prefer the first solution, as it leaves the environment as a
relatively static and potentially expensive object that a typical application
would create only one of, and puts the transient per-operation stuff into a new
lightweight object. Since the protection-context would be the thing that
describes any errors encountered in performing a protect or unprotect
operation, and would have to remain valid until any expected receipts have been
verified, there would have to be an explicit call to release it.
John
Received: from cnri by ietf.org id aa06035; 20 Mar 97 17:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20865;
20 Mar 97 17:07 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <TAA29930 at pad-thai.cam.ov.com>; Thu, 20 Mar 1997 19:28:25 GMT
Message-Id: <3.0.32.19970320112427.00916ca0 at adm.loc201.tandem.com>
X-Sender: dkurn at adm.loc201.tandem.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 20 Mar 1997 11:25:37 -0800
To: cat-ietf at mit.edu
From: David Kurn <dkurn at tandem.com>
Subject: Re: IDUP-GSS-API
Cc: "John Wray, Digital DPE, 508/486-5210 20-Mar-1997 1130" <wray at tuxedo.enet.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk
John.
I agree with your observations about the complexity of the interface.
In my opinion, the idea ought to be that the basic functionality is
provided as:
start-protect (gets things going)
protect-a-chunk (moves a data buffer), repeated as needed.
end-protect (finishes things up.)
Now, if someone wants to write a one-procedure surrounding function, it can
be done in a truly mechanism-independent manner. I don't think that the
single-procedure vs multiple-precedure call decision should be intertwined
with the basic functionality.
Alternately, I think that the multitude of options that are passed in the
current "start-protect" function should be removed to some auxiliary calls.
If this model is adopted, then we could get a calling model that looks
like this:
Prepare-to-protect
Resets options to defaults; allocates a context buffer; could set some
oft-set options.
Modify-protection-options
Called only if you are unhappy with the defaults; we should try to
avoid requiring this for common cases.
Add Recipient
Repeat as needed, one per recipient, if you're encrypting.
Protect-a-buffer
Repeat as needed; the interface might be returning result-buffers here
if the mechanism allows one-pass processing
Finish-Protect
Some mechanisms cannot return anything until the end, so this call has
to have an repeatable nature to retrieve all the pieces of the answer.
This nicely avoids most of the parameter bundles, and especially the
complex target-list structure.
I do not claim to have a thoroughly worked out proposal for the procedures,
but rather the above should be viewed as a sketch of how I'd try to
structure the calls.
I regret that I will not be attending the Memphis IETF.
David Kurn
Tandem Computers Inc
At 12:40 PM 3/20/97 EST, you wrote:
>Carlisle,
>
>I apologise for sending extensive comments at such a late stage, but I've
>recently been doing some IDUP-related work and found the following issues
with
>the -06 draft of the IDUP spec.
>
>
>1) Protection service complexity
>
>
>There seems to be considerable complexity due to overloading the semantics
>of the IDUP_Start_Protect call to deal with several distinct protection
models:
>
>a) Incremental protection (i.e. passing large data to IDUP_Protect() in
chunks)
> vs single-buffer protection (using IDUP_Start_Protect() to do
everything in
> a single call)
>
>b) Encapsulation vs seperate data & signature-token.
>
>c) Handling of data-protection, receipt-generation and receipt-solicitation
> as variants of a basic "protect" service.
>
>
><META-COMMENT>
> This is probably an effect of the heavy use of the parameter bundle
> construct, which I find very programmer-unfriendly. I'd far rather
> program to an interface that has more but simpler calls, compared to
> an API that has a small number of highly overloaded functions, with
> lots of parameters that are significant only for subsets of those
> overloaded purposes (even if those many parameters are disguised
> within bundles).
>
> While the use of bundles may be merely descriptive within this
> specification, and not necessarily intended to be reflected in
> language bindings, the comment on page 23 implies that they are
> intended to map more-or-less directly to programming language
> constructs.
>
> The use of parameter bundles gives me a real feeling of deja-vu: it
> looks very like the OMG way of presenting arbitary object data to
> a small set of overloaded APIs in the XOM and XDS APIs, and I don't
> think that XOM/XDS is a precedent that we want to follow.
></META-COMMENT>
>
>
>It would be make for a much simpler programming interface to provide distinct
>entrypoints for these different protection functions. For example, use the
>sequence "IDUP_Start_Protect(); N * IDUP_Protect_Chunk();
IDUP_End_Protect()"
>to protect chunked data, and the sequence "IDUP_Protect()" to protect a datum
>presented in a single chunk.
>
>The encapsulation vs seperate data & token problem is more complicated, and I
>don't understand from the current spec how this is supposed to be handled.
>According to page 3, if the application is using a non-encapsulating
mechanism,
>then it's up to it how it combines the M-IDU and token to form a P-IDU, so
long
>as the receiving application knows how to split the M-IDU and token apart
once
>again. But according to the documentation for IDUP_Start_Unprotect(), the
>M-IDU can be presented in the single_data_buffer parameter (assuming
you're not
>chunking on the receive side). and there's no place to present the token.
>Example B.2 should illustrate what to do in this case, but it doesn't discuss
>how the protection token would be handled if the receiver chooses not to
chunk
>the data. It might be that the receiver is supposed to concatentate the
M-IDU
>and the token, but if so this should be stated explicitly (there seems to be
>some terminology confusion here, anyway - IDUP_End_Protect has an output
>parameter "final_midu_buffer" for use only when not encapsulating, which I
>presume this is where the protection token is delivered; however page 3
asserts
>that the token and the M-IDU are different entities). Anyway, the
receiver is
>likely to want to be given the token up-front (as it'll probably contain
>cryptographic initialization data that'll be needed in order to process the
>M-IDUs).
>
>Why not follow the example of GSSAPI here, and have two families of calls,
one
>to handle the encapsulating case, and one to handle the seperate data & token
>scenario (like gss_wrap & gss_get_mic). If you use "_Protect_" to mean
>the non-encapsulated family, and "_Wrap_" to mean the encapsulating family,
>you'd have something like the following:
>
>A) Encapsulating, non-chunked case
>
> Transmitter:
> IDUP_Wrap(IDU) -> token
>
> Receiver:
> IDUP_Unwrap(token) -> IDU
>
>B) Non-encapsulating, non-chunked case
>
> Transmitter:
> IDUP_Protect(IDU) -> token, MIDU
>
> Receiver:
> IDUP_Unprotect(token, MIDU) -> IDU
>
>
>C) Encapsulating, chunked case
>
> Transmitter:
> IDUP_Start_Wrap()
> IDUP_Wrap_Chunk(IDU-chunk) -> token-chunk
> IDUP_Wrap_Chunk(IDU-chunk) -> token-chunk
> ...
> IDUP_End_Wrap() -> token-chunk
>
> Receiver:
> IDUP_Start_Unwrap(token-chunk)
> IDUP_Unwrap_Chunk(token-chunk) -> IDU-chunk
> IDUP_Unwrap_Chunk(token-chunk) -> IDU-chunk
> ...
> IDUP_End_Unwrap() -> IDU-chunk
>
>
>D) Non-encapsulating, chunked case
>
> Transmitter:
> IDUP_Start_Protect()
> IDUP_Protect_Chunk(IDU-chunk) -> MIDU-chunk
> IDUP_Protect_Chunk(IDU-chunk) -> MIDU-chunk
> ...
> IDUP_End_Protect() -> token, MIDU-chunk
>
>
> Receiver:
> IDUP_Start_Unprotect(token)
> IDUP_Unprotect_Chunk(MIDU-chunk) -> IDU-chunk
> IDUP_Unprotect_Chunk(MIDU-chunk) -> IDU-chunk
> ...
> IDUP_End_Unprotect() -> IDU-chunk
>
> (As per the current ID, chunking at transmitter doesn't have
> to imply chunking at receiver - Receiver and transmitter can
> each decide independently whether or not to chunk data, and
> even if both decide to chunk, they can break up the stream of
> token data into chunks independently. This implies that
> not every chunk presented to, say, IDUP_Wrap_Chunk need
> result in a token-chunk, since if confidentiality protection
> is being applied, token-chnks will presumably be emitted in
> multiples of the underlying crypt block-size, and the input
> chunk may be smaller than that size. The comment on page
> 29 about a zero-length output_buffer being permitted only
> when data is being encapsulated should be broadened to allow
> for this case during non-encapsulating protection too).
>
>The asymmetry in the handling of the token (i.e. generated by End_Protect but
>consumed by Start_Unprotect) in the last above example is a bit
bothersome. In
>general, the token's going to be needed by the Start_Unprotect() call, as it
>probably includes crypto keying and other initialization data that will be
>needed in order to make any sense of the MIDU chunks, but it will also
probably
>contain a MIC that won't be calculable by the transmitter until End_Protect()
>completes). This means that the token has to logically "overtake" the data,
>which may be difficult in some applications. For example, say I'm building a
>file encryption program using IDUP. If I want to use a non-encapsulating
>method, it seems like I have to either know the maximum size that the token
>could possibly take up (so I can reserve space for it at the start of my
target
>file), or append it after the MIDU data and reserve space for a pointer at
the
>start of my file to say where the MIDU ends and the token begins (so that the
>decrypt program can process the token first). I guess I could dump my MIDU
>chunks into a temp file, and then append this file to the target file, after
>having written the token into the target file, but this seems very messy.
>
>I can't think of a better way to do things, although perhaps an output from
>IDUP_Start_Protect (or obtainable by an environment inquiry after this call)
>that gives the maximum size of the final token would allow me to reserve the
>correct amount of space in front of the MIDU chunks.
>
> Incidentally, the -06 draft mentions a couple of file
> protection/unprotection routines on page 11, but never defines
> them. I think the chunked variants on the regular protect calls
> should be good enough to handle file encryption, and would like to
> see these file-specific routines removed completely (which might have
> been the intent anyway).
>
>The above has so far only addressed type-1 protection services (services
that a
>data originator would invoke to protect that data). Verifying a receipt and
>generating a solicited receipt should probably use a different API.
>Overloading IDUP_Protect just seems to confuse things.
>
>
>_Requesting_ a receipt has to be included in the Protect() families, e.g.
>something like:
>
> IDUP_Start_Protect(
> Targets: SET OF target-info,
> [various other mandatory parameters including environment],
> Receipts-requested: OPTIONAL SET OF receipt-info)
>
>where receipt-info is a parameter bundle that indentifies the recipient from
>whom a recipt is requested, and possibly other information pertaining to the
>desired format or properties of the receipt. Omitting the parameter would
>imply no receipts are desired. This seems easier to program to than hiding
>the recipients within the services_to_perform bundle.
>
>Generation and verifiation of receipts could be performed by new routines:
>
> IDUP_Generate_Receipt(environment) -> token
>
> IDUP_Verify_Receipt(environment, token)
>
> (although in the above calls, "environment" should really be a
> "protection-context" - see below).
>
>
> I'm not sure quite what model you're assuming for receipts. The
> current spec doesn't seem to handle third-party generated receipts,
> nor does it seem to support (much) later verification of receipts
> (other than perhaps by re-processing the original protected data).
> Perhaps a Protect operation for which receipts are requested should
> also generate a local token, which is supposed to be stored by the
> transmitter so that at a later date it can be used to verify a receipt.
>
>
>The SE family of calls take an approach more like the above, although they
>still seem slightly more complex than they need to be (see below - *). I
don't
>really see the advantage of having the lower-level complex API as well.
It's
>possible to add routines (like the Generate/Verify_Receipt calls above) to
>fill-in the missing functionality of the current SE calls, and (I believe)
make
>them close enough in functionality to the current low-level API without the
>complexity.
>
>* - One place where the SE family still seems more complex than necessary is
> in the use of parameter bundles to specify the target info. The
> IDUP_SE_SingleBuffer_Protect call, for example, takes a single parameter
> bundle that indicates both the input set of desired target names, and
> also contains space for a returned set of status parameters to receive
> errors about any names that were invalid, or for which the data couldn't
> be protected. While I realise that this is a high-level spec, and that
> an actual bindings document could probably seperate these into two
> distinct parameters, I think it's far better even at this level to keep
> input parameters seperate from output parameters rather than grouping
> them in a single parameter bundle just because they are both related
> to target names.
>
> If option (i) below is adopted, then detailed error information
> doesn't have to be returned by a Protect family routines, but could
> be extracted later by an explicit inquiry call against the protection
> context.
>
>
>2) Environments and multiple protection operations
>
>In addition to the environment object, I think you also need a state object
>that links together multi-buffer (chunked) Protect/Unprotect operations. The
>environment object seems to be fairly heavy-weight, and it seems to be
intended
>to span multiple protect operations (it's sort-of analagous to a GSSAPI
>credential).
>
>However, if I want to perform multiple multi-buffer (chunked) protect
>operations (perhaps in different threads, or perhaps simply interleaved
within
>a single thread) it looks like I have to establish a distinct environment for
>each series of operations. If so, this is a problem, and we need either:
>
>i) A seperate "protection-context" object that describes an ongoing
>Protect/Unprotect (or Wrap/Unwrap) operation (which would be the thing
that's
>queried about the results of such an operation, and which could also link a
>Protect or Wrap operation with any receipts for the protected data), or
>
>ii) An assertion that an environment is a lightweight object that should in
>general span only a single protection operation, and a routine to clone an
>environment so that multiple Protection operations can be performed
>simultaneously without interfering with one another.
>
>I'd much prefer the first solution, as it leaves the environment as a
>relatively static and potentially expensive object that a typical application
>would create only one of, and puts the transient per-operation stuff into
a new
>lightweight object. Since the protection-context would be the thing that
>describes any errors encountered in performing a protect or unprotect
>operation, and would have to remain valid until any expected receipts have
been
>verified, there would have to be an explicit call to release it.
>
>
>John
>
>
Received: from ietf.org by ietf.org id aa07855; 20 Mar 97 18:08 EST
Received: from zephyr.isi.edu by ietf.org id aa07703; 20 Mar 97 18:04 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA25541>; Thu, 20 Mar 1997 15:01:55 -0800
Message-Id: <199703202301.AA25541 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2118 on MPPC Protocol
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 20 Mar 97 15:01:55 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2118:
Title: Microsoft Point-To-Point Compression (MPPC)
Protocol
Author: G. Pall
Date: March 1997
Mailbox: gurdeep at microsoft.com
Pages: 9
Characters: 17443
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2118.txt
This document describes the use of the Microsoft Point to Point
Compression protocol (also referred to as MPPC in this document) for
compressing PPP encapsulated packets. This document is the product of
the Point-to-Point Protocol Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970320143434.RFC at ISI.EDU>
SEND /rfc/rfc2118.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2118.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970320143434.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa08571; 20 Mar 97 18:23 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22546;
20 Mar 97 18:23 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <VAA06386 at pad-thai.cam.ov.com>; Thu, 20 Mar 1997 21:57:24 GMT
Message-Id: <3331B02D.2687 at coastek.com>
Date: Thu, 20 Mar 1997 13:46:21 -0800
From: "Todd S. Glassey" <todd at gw.coastek.com>
Organization: Coastek Infosys
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: j.jones at unikix.com
Cc: cat-ietf at mit.edu, ssl-talk at netscape.com
Subject: Re: [Fwd: Re: GSS-API and SSL - their coexistence, and related issues]
References: <332DC75B.4C1E at unikix.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
John Jones wrote:
>
> What about the more complex SET protocol in which the data is intended
> for two independent entities but routed via one of the entities.
> Different pieces of the data being encoded under different secrets
> derived from different certs and multiply signed. This surely can only
> be done at the application level.
>
> > From: Bill Buffam <bjb at trsvr.tr.unisys.com>
> >
> > Okay, here's some real flame bait: <soapbox> I regard user level
> > authentication provided by IPSEC as a monumental kludge. It says to the
> > application layer "never mind this pretty layered structure, just assume
> > what's underneath and drive it." Application protocols should work over
> > any protocol stack - that's what the layered structure is all about.
> > This whole idea really pollutes the cleanliness of the layers. As
> > Abraham Maslow said, "When the only tool you have is a hammer,
> > everything looks like a nail." I could go on at length, but I won't.
> > </soapbox>
>
> You mean you believe that any form of application-layer security
> is a monumental kludge?
>
> If the application is security-aware, and requests security services
> using some API (say for example GSS-API, or some sockopt-based API),
> then why should the application know or care how those services are
> provided? The actual transport protection could in theory be provided
> anywhere in the stack, from layer 1 on up. And (again, in theory) each
> layer could have a well-defined interface to the adjacent layers so
> that the session-layer module, having received a request for a secure
> connection for a particular user, could either set it up using the
> (misnamed) TLS protocol, or merely maintain a mapping between the
> session/user ID and an SPI and rely on IPSEC to do the data transforms.
> The application doesn't have to know whether the data is protected
> by AH/ESP or by TLS Record Layer, it just knows that it's getting a
> specified Quality of Protection.
>
> Of course no current implementations are designed to do clean layering,
> (this is, after all, the I-Q&D-ETF :-), but there is no architectural
> reason that they couldn't be.
>
> ---------------------------------------------------------------
>
> Subject: Re: GSS-API and SSL - their coexistence, and related issues
> Resent-Date: Mon, 17 Mar 1997 06:22:25 -0800 (PST)
> Resent-From: ssl-talk at netscape.com
> Date: Mon, 17 Mar 1997 09:19:24 -0500
> From: dpkemp at missi.ncsc.mil (David P. Kemp)
> To: cat-ietf at mit.edu, ssl-talk at netscape.com
>
> > From: Bill Buffam <bjb at trsvr.tr.unisys.com>
> >
> > Okay, here's some real flame bait: <soapbox> I regard user level
> > authentication provided by IPSEC as a monumental kludge. It says to the
> > application layer "never mind this pretty layered structure, just assume
> > what's underneath and drive it." Application protocols should work over
> > any protocol stack - that's what the layered structure is all about.
> > This whole idea really pollutes the cleanliness of the layers. As
> > Abraham Maslow said, "When the only tool you have is a hammer,
> > everything looks like a nail." I could go on at length, but I won't.
> > </soapbox>
>
> You mean you believe that any form of application-layer security
> is a monumental kludge?
This is right on the money. Applications-Layer security is mandatory for
scaleable OLTP. In fact application layer networking is the obvious
answer to all of the issues besetting Electronic Commerce. Move the
connection into the applictaion and create a physical to virtual process
interface such that each context has it's own instantiation of the
networking model.
>
> If the application is security-aware, and requests security services
> using some API (say for example GSS-API, or some sockopt-based API),
> then why should the application know or care how those services are
> provided? The actual transport protection could in theory be provided
> anywhere in the stack, from layer 1 on up. And (again, in theory) each
> layer could have a well-defined interface to the adjacent layers so
> that the session-layer module, having received a request for a secure
> connection for a particular user, could either set it up using the
> (misnamed) TLS protocol, or merely maintain a mapping between the
> session/user ID and an SPI and rely on IPSEC to do the data transforms.
> The application doesn't have to know whether the data is protected
> by AH/ESP or by TLS Record Layer, it just knows that it's getting a
> specified Quality of Protection.
>
> Of course no current implementations are designed to do clean layering,
> (this is, after all, the I-Q&D-ETF :-), but there is no architectural
> reason that they couldn't be.
Received: from ietf.org by ietf.org id aa08940; 20 Mar 97 18:30 EST
Received: from cnri by ietf.org id aa08395; 20 Mar 97 18:18 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22461;
20 Mar 97 18:18 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA22656>; Thu, 20 Mar 1997 15:15:27 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id SAA27558; Thu, 20 Mar 1997 18:15:24 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
Newsgroups: ru.comp.dev.ietf
Subject: RFC 2118 on MPPC Protocol
Date: 20 Mar 1997 18:15:22 -0500
Organization: Rutgers University
Lines: 90
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gsgea$qt3$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2118:
Title: Microsoft Point-To-Point Compression (MPPC)
Protocol
Author: G. Pall
Date: March 1997
Mailbox: gurdeep at microsoft.com
Pages: 9
Characters: 17443
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2118.txt
This document describes the use of the Microsoft Point to Point
Compression protocol (also referred to as MPPC in this document) for
compressing PPP encapsulated packets. This document is the product of
the Point-to-Point Protocol Extensions Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970320143434.RFC at ISI.EDU>
SEND /rfc/rfc2118.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2118.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970320143434.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28153; 21 Mar 97 5:42 EST
Received: from wf10.wfa.digital.ie by ietf.org id aa27894; 21 Mar 97 5:32 EST
Received: by gateway.wfa.digital.ie; (8.7.3/1.3/10May95) id LAA22721; Fri, 21 Mar 1997 11:41:08 GMT
Sender:ietf-request at ietf.org
From: Dermot Tynan <dtynan at wfa.digital.ie>
Message-Id: <9703211029.AA22402 at karpov.wfa.digital.ie>
Subject: RFC 2118 - the start of a new era?
To: ietf at ietf.org
Date: Fri, 21 Mar 1997 10:29:48 +0000 (GMT)
Cc: RFC Editor <rfc-ed at isi.edu>
In-Reply-To: <5gsgea$qt3$1 at rutgers.rutgers.edu> from "RFC Editor" at Mar 20, 97 06:15:22 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
RFC Editor wrote:
>
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 2118:
>
> Title: Microsoft Point-To-Point Compression (MPPC)
> Protocol
Is this the first time that a company name has appeared in the title
of an RFC? I can't remember ever seeing this before (don't quote FTP
software, because we all know which came first :). Is this the start
of a new trend? I can't say I particularly like it...
- Der
--
Dermot Tynan +353 91 754608
dtynan at wfa.digital.ie DTN: 822-4608
AltaVista Internet Software, Galway, Ireland
Received: from ietf.org by ietf.org id aa28543; 21 Mar 97 5:51 EST
Received: from cnri by ietf.org id aa28454; 21 Mar 97 5:50 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06317;
21 Mar 97 5:50 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA22323>; Fri, 21 Mar 1997 02:47:33 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id FAA16869; Fri, 21 Mar 1997 05:47:32 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Dermot Tynan <dtynan at wfa.digital.ie>
Newsgroups: ru.comp.dev.ietf
Subject: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 05:47:31 -0500
Organization: Rutgers University
Lines: 19
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gtp03$gf2$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
RFC Editor wrote:
>
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 2118:
>
> Title: Microsoft Point-To-Point Compression (MPPC)
> Protocol
Is this the first time that a company name has appeared in the title
of an RFC? I can't remember ever seeing this before (don't quote FTP
software, because we all know which came first :). Is this the start
of a new trend? I can't say I particularly like it...
- Der
--
Dermot Tynan +353 91 754608
dtynan at wfa.digital.ie DTN: 822-4608
AltaVista Internet Software, Galway, Ireland
Received: from ietf.org by ietf.org id aa29691; 21 Mar 97 6:09 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa29602;
21 Mar 97 6:08 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199703211102.UAA12960 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id UAA12960; Fri, 21 Mar 1997 20:02:39 +0900
Subject: Re: RFC 2118 - the start of a new era?
To: Dermot Tynan <dtynan at wfa.digital.ie>
Date: Fri, 21 Mar 97 20:02:37 JST
Cc: ietf at ietf.org, rfc-ed at isi.edu
In-Reply-To: <9703211029.AA22402 at karpov.wfa.digital.ie>; from "Dermot Tynan" at Mar 21, 97 10:29 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
0047 W. Crowther, "BBN's comments on NWG/RFC #33", 04/20/1970.
(Pages=4) (Format=) (Updates RFC0033)
1953 I P. W. Edwards, R. E. Hoffman, F. Liaw, T. Lyon, G. Minshall, ,
"Ipsilon Flow Management Protocol Specification for IPv4 Version
1.0", 05/23/1996. (Pages=20) (Format=.txt)
Masataka Ohta
Received: from ietf.org by ietf.org id aa00102; 21 Mar 97 6:14 EST
Received: from office.demon.net by ietf.org id aa00022; 21 Mar 97 6:14 EST
Received: from pillar.turnpike.com ([194.70.55.2]) by office.demon.net
id aa28449; 21 Mar 97 11:06 GMT
Message-ID: <+VZwqrAxsmMzEACw at turnpike.com>
Date: Fri, 21 Mar 1997 11:04:17 +0000
To: Dermot Tynan <dtynan at wfa.digital.ie>
Cc: ietf at ietf.org, RFC Editor <rfc-ed at isi.edu>
Sender:ietf-request at ietf.org
From: Richard Clayton <richard at turnpike.com>
Subject: Re: RFC 2118 - the start of a new era?
In-Reply-To: <9703211029.AA22402 at karpov.wfa.digital.ie>
MIME-Version: 1.0
X-Mailer: Turnpike Version 3.04 beta 1a <U2yaxlNz9m7tpk5wwwfqeW1so7>
Source-Info: From (or Sender) name not authenticated.
In message <9703211029.AA22402 at karpov.wfa.digital.ie>, Dermot Tynan
<dtynan at wfa.digital.ie> writes
>RFC Editor wrote:
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>> RFC 2118:
>>
>> Title: Microsoft Point-To-Point Compression (MPPC)
>> Protocol
>
>Is this the first time that a company name has appeared in the title
>of an RFC?
there are dozens and dozens of examples of this...
starting from the bottom...
0047 W. Crowther, "BBN's comments on NWG/RFC #33", 04/20/1970.
(Pages=4) (Format=) (Updates RFC0033)
0190 L. Deutsch, "DEC PDP-10-IMLAC communications system", 07/13/1971.
(Pages=15) (Format=)
--
richard richard.clayton @ T U R N P I K E .com
tel: +44 1306 732300
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM
Received: from ietf.org by ietf.org id aa00685; 21 Mar 97 6:20 EST
Received: from ns2.harborcom.net by ietf.org id aa00387; 21 Mar 97 6:19 EST
Received: from localhost (bradley at localhost)
by ns2.harborcom.net (8.8.5/8.8.4) with SMTP
id GAA24243; Fri, 21 Mar 1997 06:16:52 -0500 (EST)
Date: Fri, 21 Mar 1997 06:16:52 -0500 (EST)
Sender:ietf-request at ietf.org
From: Bradley Dunn <bradley at dunn.org>
X-Sender: bradley at ns2.harborcom.net
Reply-To: Bradley Dunn <bradley at dunn.org>
To: Dermot Tynan <dtynan at wfa.digital.ie>
cc: ietf at ietf.org
Subject: Re: RFC 2118 - the start of a new era?
In-Reply-To: <5gtp03$gf2$1 at rutgers.rutgers.edu>
Message-ID: <Pine.BSF.3.95q.970321061410.23945A-100000 at ns2.harborcom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On 21 Mar 1997, Dermot Tynan wrote:
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
Just from a quick glance over the RFCs since 1900, I came up with the
following:
Ascend:
2107
1934
cisco:
2105
Toshiba:
2098
HP:
1988
Ipsilon:
1987
1954
1953
So, no, it's not the first. Not even close. :)
Bradley Dunn
Received: from ietf.org by ietf.org id aa00678; 21 Mar 97 6:20 EST
Received: from cnri by ietf.org id aa00550; 21 Mar 97 6:20 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06756;
21 Mar 97 6:20 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA23141>; Fri, 21 Mar 1997 03:17:07 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id GAA17658; Fri, 21 Mar 1997 06:17:06 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 06:17:05 -0500
Organization: Rutgers University
Lines: 22
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gtqnh$h7n$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
0047 W. Crowther, "BBN's comments on NWG/RFC #33", 04/20/1970.
(Pages=4) (Format=) (Updates RFC0033)
1953 I P. W. Edwards, R. E. Hoffman, F. Liaw, T. Lyon, G. Minshall, ,
"Ipsilon Flow Management Protocol Specification for IPv4 Version
1.0", 05/23/1996. (Pages=20) (Format=.txt)
Masataka Ohta
Received: from ietf.org by ietf.org id aa01407; 21 Mar 97 6:32 EST
Received: from cnri by ietf.org id aa01300; 21 Mar 97 6:30 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06898;
21 Mar 97 6:30 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA23861>; Fri, 21 Mar 1997 03:27:48 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id GAA17953; Fri, 21 Mar 1997 06:27:47 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Richard Clayton <richard at turnpike.com>
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 06:27:46 -0500
Organization: Rutgers University
Lines: 28
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gtrbi$hgu$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
In message <9703211029.AA22402 at karpov.wfa.digital.ie>, Dermot Tynan
<dtynan at wfa.digital.ie> writes
>RFC Editor wrote:
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>> RFC 2118:
>>
>> Title: Microsoft Point-To-Point Compression (MPPC)
>> Protocol
>
>Is this the first time that a company name has appeared in the title
>of an RFC?
there are dozens and dozens of examples of this...
starting from the bottom...
0047 W. Crowther, "BBN's comments on NWG/RFC #33", 04/20/1970.
(Pages=4) (Format=) (Updates RFC0033)
0190 L. Deutsch, "DEC PDP-10-IMLAC communications system", 07/13/1971.
(Pages=15) (Format=)
--
richard richard.clayton @ T U R N P I K E .com
tel: +44 1306 732300
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM
Received: from ietf.org by ietf.org id aa01773; 21 Mar 97 6:34 EST
Received: from www.atr.net by ietf.org id aa01431; 21 Mar 97 6:32 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id pa000431 for <ietf at ietf.org>; Fri, 21 Mar 1997 06:30:59 +0000
Message-ID: <33327172.928 at atr.net>
Date: Fri, 21 Mar 1997 06:30:58 -0500
Sender:ietf-request at ietf.org
From: "Turner W Rentz , III" <treyr at atr.net>
Reply-To: treyr at atr.net
Organization: Advanced Technology and Research, Inc.
X-Mailer: Mozilla 3.01 (WinNT; I)
MIME-Version: 1.0
To: Dermot Tynan <dtynan at wfa.digital.ie>
CC: ietf at ietf.org
Subject: Re: RFC 2118 - the start of a new era?
References: <9703211029.AA22402 at karpov.wfa.digital.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Info: Evaluation version at warp.atr.net
Source-Info: From (or Sender) name not authenticated.
Dermot Tynan wrote:
>
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
> - Der
Do company names inside three letter acronyms count? I think this isn't
the first if so.
--
T. Rentz, III "The Internet is the Garden of Eden."
Software Engineer
http://www.atr.net/people/treyr
Received: from ietf.org by ietf.org id aa02046; 21 Mar 97 6:36 EST
Received: from esprit.cpd.co.uk by ietf.org id aa01849; 21 Mar 97 6:35 EST
Received: (from rossg at localhost)
by esprit.cpd.co.uk (8.8.5/8.8.4)
id LAA12249; Fri, 21 Mar 1997 11:32:18 GMT
Sender:ietf-request at ietf.org
From: rossg at cpd.co.uk
Message-Id: <199703211132.LAA12249 at esprit.cpd.co.uk>
Date: Fri, 21 Mar 1997 11:32:18 +0000 (GMT)
To: dtynan at wfa.digital.ie
Cc: ietf at ietf.org, rfc-ed at isi.edu
Subject: Re: RFC 2118 - the start of a new era?
In-Reply-To: <9703211029.AA22402 at karpov.wfa.digital.ie>
X-Mailer: Ishmail 1.3.1-961106-linux <http://www.ishmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Source-Info: From (or Sender) name not authenticated.
Dermot Tynan <dtynan at wfa.digital.ie> wrote:
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>
> AltaVista Internet Software, Galway, Ireland
I agree. Microsoft get to plaster their name all over something else.
I am all for Microsoft helping develop standards to be used by _any
vendor_, but a protocol acronym _should_ reflect what the protocol does,
not who initiated it.
It's a kind of 'I'm not playing, unless you play with _my_ ball', if you
see what I mean.
--
Ross Golder
Technical Dept
CPD Ltd, Whetstone, London, N20 9LD.
Tel: +44 (0) 973 897671
mailto:rossg at cpd.co.uk (Work)
http://www.cpd.co.uk/~rossg
Received: from ietf.org by ietf.org id aa03492; 21 Mar 97 7:00 EST
Received: from cnri by ietf.org id aa03387; 21 Mar 97 6:59 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07368;
21 Mar 97 6:59 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA25218>; Fri, 21 Mar 1997 03:56:17 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id GAA18757; Fri, 21 Mar 1997 06:56:15 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Bradley Dunn <bradley at dunn.org>
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 06:56:14 -0500
Organization: Rutgers University
Lines: 32
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gtt0u$ia2$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
On 21 Mar 1997, Dermot Tynan wrote:
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
Just from a quick glance over the RFCs since 1900, I came up with the
following:
Ascend:
2107
1934
cisco:
2105
Toshiba:
2098
HP:
1988
Ipsilon:
1987
1954
1953
So, no, it's not the first. Not even close. :)
Bradley Dunn
Received: from ietf.org by ietf.org id aa04808; 21 Mar 97 7:20 EST
Received: from cnri by ietf.org id aa04714; 21 Mar 97 7:19 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07688;
21 Mar 97 7:19 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA25604>; Fri, 21 Mar 1997 04:16:30 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id HAA19318; Fri, 21 Mar 1997 07:16:29 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: "Turner W Rentz , III" <treyr at atr.net>
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 07:16:28 -0500
Organization: Rutgers University
Lines: 24
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gtu6s$irj$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
Dermot Tynan wrote:
>
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
> - Der
Do company names inside three letter acronyms count? I think this isn't
the first if so.
--
T. Rentz, III "The Internet is the Garden of Eden."
Software Engineer
http://www.atr.net/people/treyr
Received: from ietf.org by ietf.org id aa05386; 21 Mar 97 7:28 EST
Received: from tyholt.uninett.no by ietf.org id aa05292; 21 Mar 97 7:28 EST
Received: from munken.uninett.no (munken.uninett.no [129.241.131.10]) by tyholt.uninett.no (8.7.6/8.7.3) with SMTP id NAA23432; Fri, 21 Mar 1997 13:25:08 +0100 (MET)
X-Authentication-Warning: tyholt.uninett.no: Host munken.uninett.no [129.241.131.10] didn't use HELO protocol
X-Mailer: exmh version 1.6.7 5/3/96
Sender:ietf-request at ietf.org
From: Harald.T.Alvestrand at uninett.no
To: Dermot Tynan <dtynan at wfa.digital.ie>
cc: ietf at ietf.org, RFC Editor <rfc-ed at isi.edu>
Subject: Re: RFC 2118 - the start of a new era?
In-reply-to: Your message of "Fri, 21 Mar 1997 10:29:48 GMT."
<9703211029.AA22402 at karpov.wfa.digital.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 21 Mar 1997 13:25:08 +0100
Message-ID: <7806.858947108 at munken.uninett.no>
X-Orig-Sender: Harald.T.Alvestrand at uninett.no
Source-Info: From (or Sender) name not authenticated.
dtynan at wfa.digital.ie said:
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
Not the start, but it's definitively an era.
The IESG has seen an increase in documents being submitted for RFC
publication where it was unclear from the document itself whether this
was an Internet-standards thing or some vendor doing a good deed by
publishing his private protocol as an RFC.
Some time ago, we therefore decided that we would like to have the
name of the sponsoring company in the title of all RFCs that were the
product of a single company and not of the IETF.
So you will see more of these.
Harald A
Received: from ietf.org by ietf.org id aa05570; 21 Mar 97 7:32 EST
Received: from cnri by ietf.org id aa05474; 21 Mar 97 7:31 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07855;
21 Mar 97 7:31 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA25795>; Fri, 21 Mar 1997 04:28:43 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id HAA19598; Fri, 21 Mar 1997 07:28:42 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: rossg at cpd.co.uk
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 07:28:41 -0500
Organization: Rutgers University
Lines: 38
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gtutp$j4b$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
Dermot Tynan <dtynan at wfa.digital.ie> wrote:
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>
> AltaVista Internet Software, Galway, Ireland
I agree. Microsoft get to plaster their name all over something else.
I am all for Microsoft helping develop standards to be used by _any
vendor_, but a protocol acronym _should_ reflect what the protocol does,
not who initiated it.
It's a kind of 'I'm not playing, unless you play with _my_ ball', if you
see what I mean.
--
Ross Golder
Technical Dept
CPD Ltd, Whetstone, London, N20 9LD.
Tel: +44 (0) 973 897671
mailto:rossg at cpd.co.uk (Work)
http://www.cpd.co.uk/~rossg
Received: from ietf.org by ietf.org id aa08253; 21 Mar 97 8:08 EST
Received: from cnri by ietf.org id aa08147; 21 Mar 97 8:07 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08421;
21 Mar 97 8:07 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA26477>; Fri, 21 Mar 1997 05:04:44 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id IAA20521; Fri, 21 Mar 1997 08:04:25 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Harald.T.Alvestrand at uninett.no
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 08:04:24 -0500
Organization: Rutgers University
Lines: 22
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gu10o$k16$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
dtynan at wfa.digital.ie said:
> Is this the first time that a company name has appeared in the title
> of an RFC? I can't remember ever seeing this before (don't quote FTP
> software, because we all know which came first :). Is this the start
> of a new trend? I can't say I particularly like it...
Not the start, but it's definitively an era.
The IESG has seen an increase in documents being submitted for RFC
publication where it was unclear from the document itself whether this
was an Internet-standards thing or some vendor doing a good deed by
publishing his private protocol as an RFC.
Some time ago, we therefore decided that we would like to have the
name of the sponsoring company in the title of all RFCs that were the
product of a single company and not of the IETF.
So you will see more of these.
Harald A
Received: from ietf.org by ietf.org id aa11535; 21 Mar 97 9:04 EST
Received: from dot.netrex.net by ietf.org id aa11353; 21 Mar 97 9:00 EST
Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id IAA23325 for <ietf at ietf.org>; Fri, 21 Mar 1997 08:57:29 -0500 (EST)
Message-Id: <3.0.1.32.19970321085624.009e9570 at dilbert.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at dilbert.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 21 Mar 1997 08:56:24 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: RFC 2118 - the start of a new era?
In-Reply-To: <7806.858947108 at munken.uninett.no>
References: <Your message of "Fri, 21 Mar 1997 10:29:48 GMT." <9703211029.AA22402 at karpov.wfa.digital.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Every one responding to this thread, please delete RFC Editor
<rfc-ed at isi.edu> so we stop getting two copies.
At 01:25 PM 3/21/97 +0100, Harald.T.Alvestrand at uninett.no wrote:
>
>dtynan at wfa.digital.ie said:
>> Is this the first time that a company name has appeared in the title
>> of an RFC? I can't remember ever seeing this before (don't quote FTP
>> software, because we all know which came first :). Is this the start
>> of a new trend? I can't say I particularly like it...
>
>Not the start, but it's definitively an era.
>The IESG has seen an increase in documents being submitted for RFC
>publication where it was unclear from the document itself whether this
>was an Internet-standards thing or some vendor doing a good deed by
>publishing his private protocol as an RFC.
>
>Some time ago, we therefore decided that we would like to have the
>name of the sponsoring company in the title of all RFCs that were the
>product of a single company and not of the IETF.
>
>So you will see more of these.
>
> Harald A
>
>
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa12315; 21 Mar 97 9:16 EST
Received: from cnri by ietf.org id aa12211; 21 Mar 97 9:15 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa09736;
21 Mar 97 9:15 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA27713>; Fri, 21 Mar 1997 06:12:18 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id JAA22601; Fri, 21 Mar 1997 09:12:17 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 09:12:16 -0500
Organization: Rutgers University
Lines: 32
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gu500$m26$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
Every one responding to this thread, please delete RFC Editor
<rfc-ed at isi.edu> so we stop getting two copies.
At 01:25 PM 3/21/97 +0100, Harald.T.Alvestrand at uninett.no wrote:
>
>dtynan at wfa.digital.ie said:
>> Is this the first time that a company name has appeared in the title
>> of an RFC? I can't remember ever seeing this before (don't quote FTP
>> software, because we all know which came first :). Is this the start
>> of a new trend? I can't say I particularly like it...
>
>Not the start, but it's definitively an era.
>The IESG has seen an increase in documents being submitted for RFC
>publication where it was unclear from the document itself whether this
>was an Internet-standards thing or some vendor doing a good deed by
>publishing his private protocol as an RFC.
>
>Some time ago, we therefore decided that we would like to have the
>name of the sponsoring company in the title of all RFCs that were the
>product of a single company and not of the IETF.
>
>So you will see more of these.
>
> Harald A
>
>
>
>
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from cnri by ietf.org id aa12474; 21 Mar 97 9:16 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09783;
21 Mar 97 9:16 EST
Received: by pad-thai.cam.ov.com (8.8.5/)
id <MAA01421 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 12:41:56 GMT
Message-Id: <199703211241.HAA27725 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Name type issues
Date: Fri, 21 Mar 1997 07:41:44 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Some points re name types, triggered by a query I received from
Martin Rex:
(1) RFC-2078 contains definitions for three name types (User Name
form, Machine UID form, and String UID form) which were originally
included in RFC-1964. Unfortunately, the caveat paragraph which
accompanied them in 1964, recognizing their UNIX-specific lineage and
acknowledging the fact that additional or alternative types might be
needed to handle local user ID forms for other OSs, didn't survive the
editorial processing from one document to the other. This raises, to
me, the following thoughts:
(1a) We should record the intent to resurrect the caveat for RFC-2078.
(1b) QUESTION: What's current implementation practice, if any,
concerning support and anticipated structure for names of these types
on non-UNIX platforms?
(2) Specifically regarding the User Name form, it's described as
referring to a local user name with interpretation as defined by the
local OS. (While the name's structure is OS-defined, there's no
requirement that the set of names of this type which a mechanism can
import need have any correspondence with the set of users registered
on a local machine.) RFC-1964 describes, e.g., this name form's
likely processing within a Kerberos mechanism implementation as being
accomplished by postfixing a "@" separator and realm specifier to the
basic local username. The User Name form, therefore, isn't documented
as a means to import a distributed-level name in a manner which is
supportable across mechanisms, such as we have for target services in
the Host-Based Service name form. QUESTION: should we recommend or
require such a facility and, if so, do people have preferences among
the following possibilities:
(2a) Recommend that User Name implementations optionally accept local
names postfixed with some form of domain specifier; here, I'd be
concerned that we'd be implying that the input should comprise a
hard-to-describe hybrid form where some elements' structure is defined
by the local OS and others by the mechanism in question
(2b) Recommend that GSS_Import_name with a GSS_C_NO_OID tag act
equivalently to GSS_Import_name with the tag which corresponds to the
native name form of the importing mechanism
(2c) Define a new name type to indicate "native name form of importing
mechanism"
(2d) Explicitly preclude (2b) and (2c), and require that the native
name form be explicitly tagged with a non-generic value
Thoughts?
--jl
Received: from ietf.org by ietf.org id aa12822; 21 Mar 97 9:20 EST
Received: from ietf.ietf.org by ietf.org id aa12729; 21 Mar 97 9:19 EST
To: ietf at ietf.org
Subject: Not the first, won't be the last
Date: Fri, 21 Mar 1997 09:19:19 -0500
Sender:ietf-request at ietf.org
From: Steve Coya <scoya at ietf.org>
Message-ID: <9703210919.aa12729 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
>> Is this the first time that a company name has appeared in the title
>> of an RFC?
As has been noted by previous responses, this is not the first time.
Note that these are NOT standards track protocols. They are
INFORMATIONAL documents.
The reason for including the name is to let readers know the document
is proprietary or an organization's perspective/opinion/point of view.
In many instances, the IESG has suggested title changes for such RFC
submissions, essentially asking the RFC Editor to insert the company
name to clarify the origin as not being the product of an IETF effort.
Steve
Received: from ietf.org by ietf.org id aa14589; 21 Mar 97 9:43 EST
Received: from cnri by ietf.org id aa14433; 21 Mar 97 9:41 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10284;
21 Mar 97 9:41 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA28332>; Fri, 21 Mar 1997 06:38:20 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id JAA23534; Fri, 21 Mar 1997 09:38:13 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Steve Coya <scoya at ietf.org>
Newsgroups: ru.comp.dev.ietf
Subject: Not the first, won't be the last
Date: 21 Mar 1997 09:38:12 -0500
Organization: Rutgers University
Lines: 16
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gu6gk$mvb$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
>> Is this the first time that a company name has appeared in the title
>> of an RFC?
As has been noted by previous responses, this is not the first time.
Note that these are NOT standards track protocols. They are
INFORMATIONAL documents.
The reason for including the name is to let readers know the document
is proprietary or an organization's perspective/opinion/point of view.
In many instances, the IESG has suggested title changes for such RFC
submissions, essentially asking the RFC Editor to insert the company
name to clarify the origin as not being the product of an IETF effort.
Steve
Received: from ietf.org by ietf.org id aa15443; 21 Mar 97 9:48 EST
Received: from fnal.fnal.gov by ietf.org id aa15193; 21 Mar 97 9:48 EST
Received: from gungnir.fnal.gov ("port 39186"@gungnir.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IGRB52PF14000MA3 at FNAL.FNAL.GOV>;
Fri, 21 Mar 1997 08:45:00 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4)
id IAA06176; Fri, 21 Mar 1997 08:45:00 -0600
Date: Fri, 21 Mar 1997 08:44:59 -0600
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: RFC 2118 - the start of a new era?
In-reply-to: "21 Mar 1997 11:32:18 GMT."
<"199703211132.LAA12249"@esprit.cpd.co.uk>
X-Orig-Sender: crawdad at gungnir.fnal.gov
To: rossg at cpd.co.uk
Cc: dtynan at wfa.digital.ie, ietf at ietf.org
Message-id: <199703211445.IAA06176 at gungnir.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> > > RFC 2118:
> > > Title: Microsoft Point-To-Point Compression (MPPC)
> > > Protocol
>
> I am all for Microsoft helping develop standards to be used by _any
> vendor_, but a protocol acronym _should_ reflect what the protocol does,
> not who initiated it.
Oh, relax. I'm not Gates fan (unless you mean McFadden), but this
doesn't bother me at all. First of all, it's INFORMATIONAL, not
STANDARDS TRACK, right? In addition, is it GOOD or BAD for a big
company to do something to help interoperability? What message do
you want to send them when they do?
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
Received: from ietf.org by ietf.org id aa15801; 21 Mar 97 9:52 EST
Received: from cnri by ietf.org id aa15712; 21 Mar 97 9:52 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10540;
21 Mar 97 9:52 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA29064>; Fri, 21 Mar 1997 06:49:17 -0800
Received: from corpgate.rich.nt.com (pp at corpgate.nt.com [192.135.215.2]) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) with SMTP id JAA23817 for <ru-comp-dev-ietf at rutgers.edu>; Fri, 21 Mar 1997 09:49:05 -0500
Received: from nrchh57.rich1.nt.com by corpgate.rich.nt.com with SMTP (PP);
Fri, 21 Mar 1997 14:36:34 +0000
Received: from zrchb130.rich.nt.com by nrchh57.rich1.nt.com
with SMTP (1.38.193.5/16.2) id AA05254;
Fri, 21 Mar 1997 08:34:47 -0600
Received: by zrchb130.rich.nt.com
with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <01BC35D3.392C56F0 at zrchb130.rich.nt.com>;
Fri, 21 Mar 1997 08:38:17 -0600
Message-Id: <c=US%a=_%p=NT%l=ZRCHB129-970321143820Z-52307 at zrchb130.rich.nt.com>
Sender:ietf-request at ietf.org
From: "Dawkins, Spencer (P.S.)" <Spencer.Dawkins.sdawkins at nt.com>
To: "'ru-comp-dev-ietf at rutgers.edu'" <ru-comp-dev-ietf at rutgers.edu>,
"'ietf at ietf.org'" <ietf at ietf.org>
Cc: "'rossg at cpd.co.uk'" <rossg at cpd.co.uk>
Subject: RE: RFC 2118 - the start of a new era?
Date: Fri, 21 Mar 1997 08:38:20 -0600
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I'm getting at least double copies of postings from these two mailing
lists. As far as I know, I've never subscribed to, or even heard of,
ru-comp-dev-ietf at rutgers.edu.
Can someone fix this?
Spencer
----------
From: rossg at cpd.co.uk[SMTP:rossg at cpd.co.uk]
Sent: Friday, March 21, 1997 6:29 AM
To: ru-comp-dev-ietf at rutgers.edu
Subject: Re: RFC 2118 - the start of a new era?
----- E X T E R N A L L Y O R I G I N A T E D M E S S A G E
-----
Dermot Tynan <dtynan at wfa.digital.ie> wrote:
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC
libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the
title
> of an RFC? I can't remember ever seeing this before (don't quote
FTP
> software, because we all know which came first :). Is this the
start
> of a new trend? I can't say I particularly like it...
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>
> AltaVista Internet Software, Galway, Ireland
I agree. Microsoft get to plaster their name all over something else.
I am all for Microsoft helping develop standards to be used by _any
vendor_, but a protocol acronym _should_ reflect what the protocol
does,
not who initiated it.
It's a kind of 'I'm not playing, unless you play with _my_ ball', if
you
see what I mean.
--
Ross Golder
Technical Dept
CPD Ltd, Whetstone, London, N20 9LD.
Tel: +44 (0) 973 897671
mailto:rossg at cpd.co.uk (Work)
http://www.cpd.co.uk/~rossg
Received: from ietf.org by ietf.org id aa16838; 21 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa16075; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rip-mib-00.txt
Date: Fri, 21 Mar 1997 09:53:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16075 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing Information Protocol
Working Group of the IETF.
Title : RIP Version 2 MIB Extension
Author(s) : G. Malkin, F. Baker
Filename : draft-ietf-rip-mib-00.txt
Pages : 19
Date : 03/20/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing RIP Version 2.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rip-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rip-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rip-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320113901.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rip-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rip-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320113901.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab16838; 21 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa16081; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-oncrpc-rpcsec_gss-03.txt
Date: Fri, 21 Mar 1997 09:53:42 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16081 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : RPCSEC_GSS Protocol Specification
Author(s) : M. Eisler, A. Chiu, L. Ling
Filename : draft-ietf-oncrpc-rpcsec_gss-03.txt
Pages : 20
Date : 03/20/1997
This memo describes an ONC/RPC security flavor that allows RPC protocols to
access the Generic Security Services Application Programming Interface
(referred to henceforth as GSS-API).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-oncrpc-rpcsec_gss-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-oncrpc-rpcsec_gss-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320114814.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-oncrpc-rpcsec_gss-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-rpcsec_gss-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320114814.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac16838; 21 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa16406; 21 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: aft at unify.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-aft-socks-ssl-00.txt
Date: Fri, 21 Mar 1997 09:54:08 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210954.aa16406 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Authenticated Firewall
Traversal Working Group of the IETF.
Title : Secure Sockets Layer for SOCKS Version 5
Author(s) : M. VanHeyningen
Filename : draft-ietf-aft-socks-ssl-00.txt
Pages : 4
Date : 03/20/1997
This document specifies the use of SSL 3.0 and possible successor protocols
as an authentication method for SOCKS Version 5. The design is similar to,
and largely derived from, the integration of GSS-API into SOCKS5 [RFC
1961]. A framework is provided for future extensions, and the use of other
"subauthentication" methods inside SSL is supported.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-aft-socks-ssl-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-aft-socks-ssl-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-aft-socks-ssl-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320143703.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-aft-socks-ssl-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-aft-socks-ssl-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320143703.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ad16838; 21 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa16422; 21 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-multopt-00.txt
Date: Fri, 21 Mar 1997 09:54:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210954.aa16422 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Multicast address allocation extensions options
Author(s) : B. Patel, M. Shah
Filename : draft-ietf-dhc-multopt-00.txt
Pages : 5
Date : 03/20/1997
This document describes host configuration options that may be used by
multicast address allocation protocols[3]. The options include critical
information such as the IP address (unicast or multicast) of the multicast
address allocation server(s) and a list of multicast scopes supported by
respective servers. These options are designed to work with the extensions
to DHCP [1] servers to support multicast address allocation (described in a
separate draft), however, their use may not be limited to the above
protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-multopt-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-multopt-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-multopt-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320144726.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-multopt-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-multopt-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320144726.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17285; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa15907; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-policy-ext-02.txt, .ps
Date: Fri, 21 Mar 1997 09:53:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa15907 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : RSVP Extensions for Policy Control
Author(s) : S. Herzog
Filename : draft-ietf-rsvp-policy-ext-02.txt, .ps
Pages : 16
Date : 03/20/1997
This memo describes a set of extensions for supporting generic policy
based admission control in RSVP. [Note 1]
These extensions include the standard format of POLICY_DATA objects,
a generic RSVP/Policy-Control interface, and a description of
RSVP's handling of policy events.
This document does not advocate particular policy control mechanisms;
however, a Router/Server Policy Protocol description for these
extensions can be found in [LPM].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-policy-ext-02.txt".
Or
"get draft-ietf-rsvp-policy-ext-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-ext-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-policy-ext-02.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-policy-ext-02.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320104156.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-policy-ext-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-policy-ext-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320104156.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17288; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16235; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-crowcroft-rmfp-01.txt
Date: Fri, 21 Mar 1997 09:53:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16235 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RMFP: A Reliable Multicast Framing Protocol
Author(s) : J. Crowcroft, Z. Wang, A. Ghosh, C. Diot
Filename : draft-crowcroft-rmfp-01.txt
Pages : 5
Date : 03/20/1997
There has been considerable interest in reliable multicast, and a number of
reliable multicast transport applications and systems have been built in
the past years.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-crowcroft-rmfp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-crowcroft-rmfp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-crowcroft-rmfp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320141855.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-crowcroft-rmfp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-crowcroft-rmfp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320141855.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17296; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16286; 21 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: aft at unify.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-aft-socks-cram-00.txt
Date: Fri, 21 Mar 1997 09:54:01 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210954.aa16286 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Authenticated Firewall
Traversal Working Group of the IETF.
Title : Challenge-Response Authentication Method for SOCKS V5
Author(s) : M. VanHeyningen
Filename : draft-ietf-aft-socks-cram-00.txt
Pages : 4
Date : 03/20/1997
This document specifies a general Challenge-Response Authentication Method
(CRAM) for use with SOCKS Version 5 [RFC 1928]. It is intended to support
various challenge-response mechanisms, such as S/KEY and OTP [RFC 1938] as
well as authentication tokens.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-aft-socks-cram-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-aft-socks-cram-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-aft-socks-cram-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320143429.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-aft-socks-cram-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-aft-socks-cram-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320143429.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17253; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa15832; 21 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ediint at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ediint-req-02.txt
Date: Fri, 21 Mar 1997 09:52:56 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210952.aa15832 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Electronic Data
Interchange-Internet Integration Working Group of the IETF.
Title : Requirements for Inter-operable Internet EDI
Author(s) : C. Shih, M. Jansson, R. Drummond
Filename : draft-ietf-ediint-req-02.txt
Pages : 39
Date : 03/20/1997
This document is a functional specification, discussing the
requirements for inter-operable EDI, with sufficient background
material to give an explanation for the EDI community of the
Internet, and security related issues.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ediint-req-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-req-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ediint-req-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320100042.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ediint-req-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ediint-req-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320100042.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17259; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16196; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-hit-metering-01.txt
Date: Fri, 21 Mar 1997 09:53:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16196 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Simple Hit-Metering and Usage-Limiting for HTTP
Author(s) : J. Mogul, P. Leach
Filename : draft-ietf-http-hit-metering-01.txt
Pages : 37
Date : 03/20/1997
This document proposes a simple extension to HTTP, using a new ``Meter''
header, which permits a limited form of demographic information
(colloquially called ``hit-counts'') to be reported by caches to origin
servers, in a more efficient manner than the ``cache-busting'' techniques
currently used. It also permits an origin server to control the number of
times a cache uses a cached response, and outlines a technique that origin
servers can use to capture referral information without ``cache-busting.''
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-hit-metering-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-hit-metering-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-hit-metering-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320140610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-hit-metering-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-hit-metering-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320140610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17309; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16264; 21 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: aft at unify.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-aft-socks-chap-00.txt
Date: Fri, 21 Mar 1997 09:54:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210954.aa16264 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Authenticated Firewall
Traversal Working Group of the IETF.
Title : Challenge-Handshake Authentication Protocol for SOCKS V5
Author(s) : M. VanHeyningen
Filename : draft-ietf-aft-socks-chap-00.txt
Pages : 5
Date : 03/20/1997
This document specifies the integration of the Challenge-Handshake
Authenticaton Protocol (CHAP) [RFC 1994] into SOCKS Version 5 [RFC 1928].
It is intended to provide a simple, lightweight authentication method which
is more secure than cleartext passwords but simpler than GSSAPI-based
methods. This document describes the message formats and protocol details
of incorporating CHAP into the SOCKS V5 authentication "subnegotiation."
Support is included for authentication of server to client as well as
client to server.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-aft-socks-chap-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-aft-socks-chap-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-aft-socks-chap-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320143212.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-aft-socks-chap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-aft-socks-chap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320143212.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17303; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16091; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: srv-location at tgv.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-svrloc-protocol-16.txt
Date: Fri, 21 Mar 1997 09:53:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16091 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Service Location Protocol
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Service Location Protocol
Author(s) : J. Veizades, E. Guttman, C. Perkins, S. Kaplan
Filename : draft-ietf-svrloc-protocol-16.txt
Pages : 72
Date : 03/20/1997
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet no longer need so much static configuration of
network services for network based applications. This is especially
important as computers become more portable, and users less tolerant or
able to fulfill the demands of network system administration.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-protocol-16.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-protocol-16.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-protocol-16.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320131943.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-protocol-16.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-protocol-16.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320131943.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17292; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16461; 21 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-mdhcp-00.txt
Date: Fri, 21 Mar 1997 09:54:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210954.aa16461 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : Multicast address allocation extensions to the Dynamic
Host Configuration Protocol
Author(s) : B. Patel, M. Shah
Filename : draft-ietf-dhc-mdhcp-00.txt
Pages : 17
Date : 03/20/1997
The Dynamic Host Configuration Protocol (DHCP) provides a framework for
passing configuration information to hosts on a TCP/IP network. The
multicast extensions to DHCP add additional capability of dynamic
allocation of the multicast addresses and additional configuration options.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-mdhcp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-mdhcp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-mdhcp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320145259.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-mdhcp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-mdhcp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320145259.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17348; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa15865; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-pkix at tandem.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-00.txt
Date: Fri, 21 Mar 1997 09:53:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa15865 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.
Title : Internet Public Key Infrastructure
Part 2: Operational Protocols
Author(s) : S. Boeyen, R. Housley, T. Howes,
M. Myers, P. Richard
Filename : draft-ietf-pkix-ipki2opp-00.txt
Pages : 16
Date : 03/20/1997
This is the first draft of the Internet Public Key Infrastructure X.509
Operational Protocols. This document identifies candidate protocols for
retrieval of X.509 v3 certificates and v2 CRLs as well as a candidate
protocol for online status checking of X.509 v3 certificates. It is
proposed that this document serve as the basis for the PKIX Part 2
standardization effort. Please send comments on this document to the
ietf-pkix at tandem.com mail list.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-ipki2opp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ipki2opp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320102756.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki2opp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ipki2opp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320102756.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17305; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa15958; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-holtman-http-wildcards-00.txt
Date: Fri, 21 Mar 1997 09:53:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa15958 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Wildcards in the Accept-Charset Header
Author(s) : K. Holtman
Filename : draft-holtman-http-wildcards-00.txt
Pages : 2
Date : 03/20/1997
The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset header, but
fails to define a wildcard "*" which could be used in this header to match
all character sets. This proposal corrects this omission.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-holtman-http-wildcards-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-holtman-http-wildcards-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-holtman-http-wildcards-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320111102.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-holtman-http-wildcards-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-holtman-http-wildcards-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320111102.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17276; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa15941; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-policy-oops-00.txt
Date: Fri, 21 Mar 1997 09:53:25 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa15941 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Open Outsourcing Policy Service (OOPS) for RSVP
Author(s) : S. Herzog, D. Pendarakis, R. Rajan, R. Guerin
Filename : draft-ietf-rsvp-policy-oops-00.txt
Pages : 29
Date : 03/20/1997
This document describes a protocol for exchanging policy information and
decisions between an RSVP-capable router (client) and a policy server. The
OOPS protocol supports a wide range of router configurations and RSVP
implementations, and is compatible with the RSVP Extensions for Policy
Control [Ext].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-policy-oops-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-oops-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-policy-oops-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320104544.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-policy-oops-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-policy-oops-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320104544.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17287; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16061; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: frs-mib at newbridge.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-frnetmib-frs-mib-01.txt
Date: Fri, 21 Mar 1997 09:53:40 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16061 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Frame Relay Service MIB
Working Group of the IETF.
Title : Definitions of Managed Objects for Frame Relay Service
Author(s) : D. Fowler
Filename : draft-ietf-frnetmib-frs-mib-01.txt
Pages : 64
Date : 03/20/1997
This memo defines an extension to the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Frame Relay Service.
This memo does not specify a standard for the Internet community.
This document entirely replaces RFC 1604.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-frnetmib-frs-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-frs-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-frnetmib-frs-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320114453.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-frnetmib-frs-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-frs-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320114453.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17315; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa15974; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mboned at ns.uoregon.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mboned-intro-multicast-02.txt
Date: Fri, 21 Mar 1997 09:53:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa15974 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MBONE Deployment Working
Group of the IETF.
Title : Introduction to IP Multicast Routing
Author(s) : T. Maufer, C. Semeria
Filename : draft-ietf-mboned-intro-multicast-02.txt
Pages : 54
Date : 03/20/1997
The first part of this paper describes the benefits of multicasting, the
MBone, Class D addressing, and the operation of the Internet Group
Management Protocol (IGMP). The second section explores a number of
different techniques that may potentially be employed by multicast routing
protocols:
o Flooding
o Spanning Trees
o Reverse Path Broadcasting (RPB)
o Truncated Reverse Path Broadcasting (TRPB)
o Reverse Path Multicasting (RPM)
o "Shared-Tree" Techniques
The third part contains the main body of the paper. It describes how
the previous techniques are implemented in multicast routing protocols
available today (or under development).
o Distance Vector Multicast Routing Protocol (DVMRP)
o Multicast Extensions to OSPF (MOSPF)
o Protocol-Independent Multicast - Dense Mode (PIM-DM)
o Protocol-Independent Multicast - Sparse Mode (PIM-SM)
o Core-Based Trees (CBT)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-intro-multicast-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-intro-multicast-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-intro-multicast-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320112041.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-intro-multicast-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-intro-multicast-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320112041.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17332; 21 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa16190; 21 Mar 97 9:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-radius at livingston.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-radius-servmib-00.txt
Date: Fri, 21 Mar 1997 09:53:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703210953.aa16190 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : RADIUS Server MIB
Author(s) : G. Zorn, B. Aboba
Filename : draft-ietf-radius-servmib-00.txt
Pages : 8
Date : 03/20/1997
This memo defines a set of extensions which instrument RADIUS server
functions. These extensions represent a portion of the Management
Information Base (MIB) for use with network management protocols in the
Internet community. Using these extensions IP-based management stations
can manage RADIUS servers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-servmib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-servmib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-servmib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320140001.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-servmib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-servmib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320140001.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18470; 21 Mar 97 10:07 EST
Received: from esprit.cpd.co.uk by ietf.org id aa17986; 21 Mar 97 10:03 EST
Received: (from rossg at localhost)
by esprit.cpd.co.uk (8.8.5/8.8.4)
id PAA13881; Fri, 21 Mar 1997 15:00:08 GMT
Sender:ietf-request at ietf.org
From: rossg at cpd.co.uk
Message-Id: <199703211500.PAA13881 at esprit.cpd.co.uk>
Date: Fri, 21 Mar 1997 15:00:06 +0000 (GMT)
To: crawdad at fnal.gov
Cc: rossg at cpd.co.uk, dtynan at wfa.digital.ie, ietf at ietf.org
Subject: Re[2]: RFC 2118 - the start of a new era?
In-Reply-To: <199703211445.IAA06176 at gungnir.fnal.gov>
X-Mailer: Ishmail 1.3.1-961106-linux <http://www.ishmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Source-Info: From (or Sender) name not authenticated.
Matt Crawford <crawdad at FNAL.GOV> wrote:
> > > > RFC 2118:
> > > > Title: Microsoft Point-To-Point Compression (MPPC)
> > > > Protocol
> >
> > I am all for Microsoft helping develop standards to be used by _any
> > vendor_, but a protocol acronym _should_ reflect what the protocol
> does,
> > not who initiated it.
>
> Oh, relax. I'm not Gates fan (unless you mean McFadden), but this
> doesn't bother me at all. First of all, it's INFORMATIONAL, not
> STANDARDS TRACK, right? In addition, is it GOOD or BAD for a big
> company to do something to help interoperability? What message do
> you want to send them when they do?
Yep, I was shocked because I thought it was to be a STANDARDS TRACK.
I'll refrain from pressing the 'send' button whilst in panic mode in the
future :-).
It is GOOD when any company, not just Micro$oft, promote
inter-operability between competing products like this. When will I be
able to use MS Word for Unix :-)?
--
Ross Golder
Technical Dept
CPD Ltd, Whetstone, London, N20 9LD.
Tel: +44 (0) 973 897671
mailto:rossg at cpd.co.uk (Work)
http://www.cpd.co.uk/~rossg
Received: from ietf.org by ietf.org id aa19562; 21 Mar 97 10:20 EST
Received: from cnri by ietf.org id aa19409; 21 Mar 97 10:18 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11495;
21 Mar 97 10:18 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA29943>; Fri, 21 Mar 1997 07:15:49 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id KAA24948; Fri, 21 Mar 1997 10:15:46 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Newsgroups: ru.comp.dev.ietf
Subject: Re: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 10:15:43 -0500
Organization: Rutgers University
Lines: 15
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gu8mv$obh$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
> > > RFC 2118:
> > > Title: Microsoft Point-To-Point Compression (MPPC)
> > > Protocol
>
> I am all for Microsoft helping develop standards to be used by _any
> vendor_, but a protocol acronym _should_ reflect what the protocol does,
> not who initiated it.
Oh, relax. I'm not Gates fan (unless you mean McFadden), but this
doesn't bother me at all. First of all, it's INFORMATIONAL, not
STANDARDS TRACK, right? In addition, is it GOOD or BAD for a big
company to do something to help interoperability? What message do
you want to send them when they do?
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
Received: from ietf.org by ietf.org id aa21576; 21 Mar 97 10:46 EST
Received: from hudutilf01.ml.com by ietf.org id aa21412; 21 Mar 97 10:44 EST
Received: from mail1.ml.com ([199.201.57.137])
by hudutilgw.ml.com (8.8.5/8.8.5/MLgw-3.03) with ESMTP id KAA21668;
Fri, 21 Mar 1997 10:39:54 -0500 (EST)
Sender:ietf-request at ietf.org
From: Carl_Mattocks at pcmailgw.ml.com
Received: from unixgtwy01.pcmailgw.ml.com (unixgtwy01.pcmailgw.ml.com [146.125.155.208])
by mail1.ml.com (8.8.4/8.8.4/MLmail-3.0) with SMTP
id KAA14161; Fri, 21 Mar 1997 10:42:05 -0500 (EST)
Received: from ccMail by unixgtwy01.pcmailgw.ml.com
(IMA Internet Exchange 2.1 Enterprise) id 0000FADB; Fri, 21 Mar 97 10:43:00 -0500
Mime-Version: 1.0
Date: Fri, 21 Mar 1997 10:19:01 -0500
Message-ID: <0000FADB.3453 at pcmailgw.ml.com>
Subject: The start of a new era?
To: rossg at cpd.co.uk, Matt Crawford <crawdad at fnal.gov>
Cc: dtynan at wfa.digital.ie, ietf at ietf.org
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Source-Info: From (or Sender) name not authenticated.
The participation of Corporations in standards is not NEW. The
contents of ANSI & ISO standards are always shaped by the people who
particpate. Other than government supported bodies, most participants
are the representatives of corporations. It has been noted in many
forums that Microsoft has not been an obvious contributor to OPEN
standards.... I welcome their participation, even if it means they get
to call the 'proposals' whatever they want .
Carl Mattocks
Lissom Inc.
______________________________ Reply Separator _________________________________
Subject: Re: RFC 2118 - the start of a new era?
Author: Matt Crawford <crawdad at fnal.gov> at UNIXGTWY
Date: 3/21/97 8:44 AM
> > > RFC 2118:
> > > Title: Microsoft Point-To-Point Compression (MPPC)
> > > Protocol
>
> I am all for Microsoft helping develop standards to be used by _any
> vendor_, but a protocol acronym _should_ reflect what the protocol does,
> not who initiated it.
Oh, relax. I'm not Gates fan (unless you mean McFadden), but this
doesn't bother me at all. First of all, it's INFORMATIONAL, not
STANDARDS TRACK, right? In addition, is it GOOD or BAD for a big
company to do something to help interoperability? What message do
you want to send them when they do?
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
Received: from ietf.org by ietf.org id aa22913; 21 Mar 97 11:00 EST
Received: from cnri by ietf.org id aa22669; 21 Mar 97 10:58 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12358;
21 Mar 97 10:58 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA01608>; Fri, 21 Mar 1997 07:55:53 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id KAA27230; Fri, 21 Mar 1997 10:55:50 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: "\"Dawkins, Spencer (P.S." <Spencer.Dawkins.sdawkins at nt.com>
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Newsgroups: ru.comp.dev.ietf
Subject: RE: RFC 2118 - the start of a new era?
Date: 21 Mar 1997 10:55:46 -0500
Organization: Rutgers University
Lines: 62
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gub22$qir$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
I'm getting at least double copies of postings from these two mailing
lists. As far as I know, I've never subscribed to, or even heard of,
ru-comp-dev-ietf at rutgers.edu.
Can someone fix this?
Spencer
----------
From: rossg at cpd.co.uk[SMTP:rossg at cpd.co.uk]
Sent: Friday, March 21, 1997 6:29 AM
To: ru-comp-dev-ietf at rutgers.edu
Subject: Re: RFC 2118 - the start of a new era?
----- E X T E R N A L L Y O R I G I N A T E D M E S S A G E
-----
Dermot Tynan <dtynan at wfa.digital.ie> wrote:
> RFC Editor wrote:
> >
> > A new Request for Comments is now available in online RFC
libraries.
> >
> > RFC 2118:
> >
> > Title: Microsoft Point-To-Point Compression (MPPC)
> > Protocol
>
> Is this the first time that a company name has appeared in the
title
> of an RFC? I can't remember ever seeing this before (don't quote
FTP
> software, because we all know which came first :). Is this the
start
> of a new trend? I can't say I particularly like it...
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>
> AltaVista Internet Software, Galway, Ireland
I agree. Microsoft get to plaster their name all over something else.
I am all for Microsoft helping develop standards to be used by _any
vendor_, but a protocol acronym _should_ reflect what the protocol
does,
not who initiated it.
It's a kind of 'I'm not playing, unless you play with _my_ ball', if
you
see what I mean.
--
Ross Golder
Technical Dept
CPD Ltd, Whetstone, London, N20 9LD.
Tel: +44 (0) 973 897671
mailto:rossg at cpd.co.uk (Work)
http://www.cpd.co.uk/~rossg
Received: from ietf.org by ietf.org id aa24043; 21 Mar 97 11:18 EST
Received: from cnri by ietf.org id aa23847; 21 Mar 97 11:14 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12773;
21 Mar 97 11:14 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA02296>; Fri, 21 Mar 1997 08:11:18 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id LAA27856; Fri, 21 Mar 1997 11:11:16 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Carl_Mattocks at pcmailgw.ml.com
Newsgroups: ru.comp.dev.ietf
Subject: The start of a new era?
Date: 21 Mar 1997 11:11:13 -0500
Organization: Rutgers University
Lines: 35
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gubv1$r6d$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
The participation of Corporations in standards is not NEW. The
contents of ANSI & ISO standards are always shaped by the people who
particpate. Other than government supported bodies, most participants
are the representatives of corporations. It has been noted in many
forums that Microsoft has not been an obvious contributor to OPEN
standards.... I welcome their participation, even if it means they get
to call the 'proposals' whatever they want .
Carl Mattocks
Lissom Inc.
______________________________ Reply Separator _________________________________
Subject: Re: RFC 2118 - the start of a new era?
Author: Matt Crawford <crawdad at fnal.gov> at UNIXGTWY
Date: 3/21/97 8:44 AM
> > > RFC 2118:
> > > Title: Microsoft Point-To-Point Compression (MPPC)
> > > Protocol
>
> I am all for Microsoft helping develop standards to be used by _any
> vendor_, but a protocol acronym _should_ reflect what the protocol does,
> not who initiated it.
Oh, relax. I'm not Gates fan (unless you mean McFadden), but this
doesn't bother me at all. First of all, it's INFORMATIONAL, not
STANDARDS TRACK, right? In addition, is it GOOD or BAD for a big
company to do something to help interoperability? What message do
you want to send them when they do?
_________________________________________________________
Matt Crawford crawdad at fnal.gov Fermilab
Received: from ietf.org by ietf.org id aa28202; 21 Mar 97 12:20 EST
Received: from WLV.IIPO.GTEGSC.COM by ietf.org id aa27846; 21 Mar 97 12:16 EST
Received: from SPIELZEUG.IIPO.GTEGSC.COM (SPIELZEUG.IIPO.GTEGSC.COM [199.107.242.241]) by wlv.iipo.gtegsc.com (8.8.5/8.7.3) with SMTP id JAA02280; Fri, 21 Mar 1997 09:06:41 -0800 (PST)
Message-Id: <199703211706.JAA02280 at wlv.iipo.gtegsc.com>
X-MAPI-MessageClass: IPM
Priority: Normal
To: rossg at cpd.co.uk, crawdad at fnal.gov
Cc: rossg at cpd.co.uk, dtynan at wfa.digital.ie, ietf at ietf.org
X-Mailer: FTP Software Internet Mail 2.0
MIME-Version: 1.0
Sender:ietf-request at ietf.org
From: Merton Campbell Crockett <mcc at gtegsc.com>
X-Orig-Sender: Merton Campbell Crockett <mcc at gtegsc.com>
Subject: RE: Re[2]: RFC 2118 - the start of a new era?
Date: Fri, 21 Mar 1997 17:00:55 +0000
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
>>Reply to your message of 21/03/97 16:10
|
| It is GOOD when any company, not just Micro$oft, promote
| inter-operability between competing products like this. When will I be
| able to use MS Word for Unix :-)?
|
When development of GNU Word is get to the Alpha release stage.
Don't want to give Unix an advantage over Windows users. :-)
Merton Campbell Crockett
GTE Government Systems, ESD/IOO
Telephone: 001(805)497-5045 Facsimile: 001(805)497-5787
Internet Mait: Merton.C.Crockett at GSC.GTE.COM
mcc at GTEGSC.COM
Received: from ietf.org by ietf.org id aa29525; 21 Mar 97 12:39 EST
Received: from cnri by ietf.org id aa29362; 21 Mar 97 12:38 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14529;
21 Mar 97 12:38 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA09619>; Fri, 21 Mar 1997 09:35:12 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA00505; Fri, 21 Mar 1997 12:35:11 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-cat-gssv2-cbind-04.txt
Date: 21 Mar 1997 12:35:07 -0500
Organization: Rutgers University
Lines: 99
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gugsb$fi$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : Generic Security Service API Version 2 : C-bindings
Author(s) : J. Wray
Filename : draft-ietf-cat-gssv2-cbind-04.txt
Pages : 94
Date : 03/20/1997
This draft document specifies C language bindings for Version 2 of the
Generic Security Service Application Program Interface (GSSAPI), which is
described at a language-independent conceptual level in other drafts
[GSSAPI]. It revises RFC-1509, making specific incremental changes in
response to implementation experience and liaison requests. It is
intended, therefore, that this draft or a successor version thereof will
become the basis for subsequent progression of the GSS-API specification on
the standards track.
The Generic Security Service Application Programming Interface provides
security services to its callers, and is intended for implementation atop a
variety of underlying cryptographic mechanisms. Typically, GSSAPI callers
will be application protocols into which security enhancements are
integrated through invocation of services provided by the GSSAPI. The
GSSAPI allows a caller application to authenticate a principal identity
associated with a peer application, to delegate rights to a peer, and to
apply security services such as confidentiality and integrity on a
per-message basis.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-gssv2-cbind-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-cbind-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320103307.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-gssv2-cbind-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320103307.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29687; 21 Mar 97 12:40 EST
Received: from cnri by ietf.org id aa29573; 21 Mar 97 12:39 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14579;
21 Mar 97 12:39 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA10750>; Fri, 21 Mar 1997 09:36:54 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA00556; Fri, 21 Mar 1997 12:36:52 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-mboned-intro-multicast-02.txt
Date: 21 Mar 1997 12:36:48 -0500
Organization: Rutgers University
Lines: 103
X-Orig-Sender: news at rutgers.edu
Message-Id: <5gugvg$h6$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MBONE Deployment Working
Group of the IETF.
Title : Introduction to IP Multicast Routing
Author(s) : T. Maufer, C. Semeria
Filename : draft-ietf-mboned-intro-multicast-02.txt
Pages : 54
Date : 03/20/1997
The first part of this paper describes the benefits of multicasting, the
MBone, Class D addressing, and the operation of the Internet Group
Management Protocol (IGMP). The second section explores a number of
different techniques that may potentially be employed by multicast routing
protocols:
o Flooding
o Spanning Trees
o Reverse Path Broadcasting (RPB)
o Truncated Reverse Path Broadcasting (TRPB)
o Reverse Path Multicasting (RPM)
o "Shared-Tree" Techniques
The third part contains the main body of the paper. It describes how
the previous techniques are implemented in multicast routing protocols
available today (or under development).
o Distance Vector Multicast Routing Protocol (DVMRP)
o Multicast Extensions to OSPF (MOSPF)
o Protocol-Independent Multicast - Dense Mode (PIM-DM)
o Protocol-Independent Multicast - Sparse Mode (PIM-SM)
o Core-Based Trees (CBT)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-intro-multicast-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-intro-multicast-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-intro-multicast-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320112041.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-intro-multicast-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-intro-multicast-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320112041.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29857; 21 Mar 97 12:42 EST
Received: from cnri by ietf.org id aa29781; 21 Mar 97 12:42 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14638;
21 Mar 97 12:42 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA12177>; Fri, 21 Mar 1997 09:39:19 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA00688; Fri, 21 Mar 1997 12:39:17 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-pkix-ipki2opp-00.txt
Date: 21 Mar 1997 12:39:15 -0500
Organization: Rutgers University
Lines: 90
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guh43$ld$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.
Title : Internet Public Key Infrastructure
Part 2: Operational Protocols
Author(s) : S. Boeyen, R. Housley, T. Howes,
M. Myers, P. Richard
Filename : draft-ietf-pkix-ipki2opp-00.txt
Pages : 16
Date : 03/20/1997
This is the first draft of the Internet Public Key Infrastructure X.509
Operational Protocols. This document identifies candidate protocols for
retrieval of X.509 v3 certificates and v2 CRLs as well as a candidate
protocol for online status checking of X.509 v3 certificates. It is
proposed that this document serve as the basis for the PKIX Part 2
standardization effort. Please send comments on this document to the
ietf-pkix at tandem.com mail list.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-ipki2opp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ipki2opp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320102756.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki2opp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ipki2opp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320102756.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29947; 21 Mar 97 12:43 EST
Received: from cnri by ietf.org id aa29874; 21 Mar 97 12:42 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14652;
21 Mar 97 12:42 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA12560>; Fri, 21 Mar 1997 09:39:55 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA00725; Fri, 21 Mar 1997 12:39:53 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-kille-mixer-rfc1327bis-05.txt
Date: 21 Mar 1997 12:39:49 -0500
Organization: Rutgers University
Lines: 93
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guh55$mi$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME - X.400 Gateway Working
Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME
Author(s) : S. Kille
Filename : draft-kille-mixer-rfc1327bis-05.txt
Pages : 172
Date : 03/20/1997
This document relates primarily to the ITU-T 1988 and 1992 X.400 Series
Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T
standard is referred to in this document as "X.400", which is a convenient
shorthand. Any reference to the 1984 Recommendations will be explicit.
Any mappings relating to elements which are in the 1992 version and not in
the 1988 version will be noted explicitly. X.400 defines an Interpersonal
Messaging System (IPMS), making use of a store and forward Message Transfer
System. This document relates to the IPMS, and not to wider application of
X.400, such as EDI as defined in X.435.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kille-mixer-rfc1327bis-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kille-mixer-rfc1327bis-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kille-mixer-rfc1327bis-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320101700.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kille-mixer-rfc1327bis-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kille-mixer-rfc1327bis-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320101700.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00205; 21 Mar 97 12:43 EST
Received: from cnri by ietf.org id aa29967; 21 Mar 97 12:43 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14677;
21 Mar 97 12:43 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA12899>; Fri, 21 Mar 1997 09:40:26 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA00809; Fri, 21 Mar 1997 12:40:24 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-holtman-http-wildcards-00.txt
Date: 21 Mar 1997 12:40:20 -0500
Organization: Rutgers University
Lines: 83
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guh64$nv$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Wildcards in the Accept-Charset Header
Author(s) : K. Holtman
Filename : draft-holtman-http-wildcards-00.txt
Pages : 2
Date : 03/20/1997
The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset header, but
fails to define a wildcard "*" which could be used in this header to match
all character sets. This proposal corrects this omission.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-holtman-http-wildcards-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-holtman-http-wildcards-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-holtman-http-wildcards-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320111102.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-holtman-http-wildcards-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-holtman-http-wildcards-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320111102.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03219; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02244; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15017;
21 Mar 97 12:56 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17012>; Fri, 21 Mar 1997 09:53:55 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01235; Fri, 21 Mar 1997 12:49:09 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-aft-socks-cram-00.txt
Date: 21 Mar 1997 12:49:06 -0500
Organization: Rutgers University
Lines: 86
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhmi$140$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Authenticated Firewall
Traversal Working Group of the IETF.
Title : Challenge-Response Authentication Method for SOCKS V5
Author(s) : M. VanHeyningen
Filename : draft-ietf-aft-socks-cram-00.txt
Pages : 4
Date : 03/20/1997
This document specifies a general Challenge-Response Authentication Method
(CRAM) for use with SOCKS Version 5 [RFC 1928]. It is intended to support
various challenge-response mechanisms, such as S/KEY and OTP [RFC 1938] as
well as authentication tokens.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-aft-socks-cram-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-aft-socks-cram-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-aft-socks-cram-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320143429.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-aft-socks-cram-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-aft-socks-cram-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320143429.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03188; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02242; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15015;
21 Mar 97 12:56 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17020>; Fri, 21 Mar 1997 09:53:55 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01240; Fri, 21 Mar 1997 12:49:10 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-http-hit-metering-01.txt
Date: 21 Mar 1997 12:49:07 -0500
Organization: Rutgers University
Lines: 88
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhmj$12u$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Simple Hit-Metering and Usage-Limiting for HTTP
Author(s) : J. Mogul, P. Leach
Filename : draft-ietf-http-hit-metering-01.txt
Pages : 37
Date : 03/20/1997
This document proposes a simple extension to HTTP, using a new ``Meter''
header, which permits a limited form of demographic information
(colloquially called ``hit-counts'') to be reported by caches to origin
servers, in a more efficient manner than the ``cache-busting'' techniques
currently used. It also permits an origin server to control the number of
times a cache uses a cached response, and outlines a technique that origin
servers can use to capture referral information without ``cache-busting.''
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-hit-metering-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-hit-metering-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-hit-metering-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320140610.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-hit-metering-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-hit-metering-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320140610.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03195; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02208; 21 Mar 97 12:56 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15007;
21 Mar 97 12:56 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA16993>; Fri, 21 Mar 1997 09:53:50 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01295; Fri, 21 Mar 1997 12:49:54 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-radius-servmib-00.txt
Date: 21 Mar 1997 12:49:53 -0500
Organization: Rutgers University
Lines: 86
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guho1$18a$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote Authentication
Dial-In User Service Working Group of the IETF.
Title : RADIUS Server MIB
Author(s) : G. Zorn, B. Aboba
Filename : draft-ietf-radius-servmib-00.txt
Pages : 8
Date : 03/20/1997
This memo defines a set of extensions which instrument RADIUS server
functions. These extensions represent a portion of the Management
Information Base (MIB) for use with network management protocols in the
Internet community. Using these extensions IP-based management stations
can manage RADIUS servers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-servmib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-servmib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-servmib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320140001.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-servmib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-servmib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320140001.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03237; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02327; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15055;
21 Mar 97 12:57 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17076>; Fri, 21 Mar 1997 09:54:08 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01336; Fri, 21 Mar 1997 12:50:13 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-aft-socks-chap-00.txt
Date: 21 Mar 1997 12:50:11 -0500
Organization: Rutgers University
Lines: 90
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhoj$19k$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Authenticated Firewall
Traversal Working Group of the IETF.
Title : Challenge-Handshake Authentication Protocol for SOCKS V5
Author(s) : M. VanHeyningen
Filename : draft-ietf-aft-socks-chap-00.txt
Pages : 5
Date : 03/20/1997
This document specifies the integration of the Challenge-Handshake
Authenticaton Protocol (CHAP) [RFC 1994] into SOCKS Version 5 [RFC 1928].
It is intended to provide a simple, lightweight authentication method which
is more secure than cleartext passwords but simpler than GSSAPI-based
methods. This document describes the message formats and protocol details
of incorporating CHAP into the SOCKS V5 authentication "subnegotiation."
Support is included for authentication of server to client as well as
client to server.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-aft-socks-chap-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-aft-socks-chap-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-aft-socks-chap-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320143212.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-aft-socks-chap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-aft-socks-chap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320143212.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03272; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02294; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15035;
21 Mar 97 12:57 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17048>; Fri, 21 Mar 1997 09:54:02 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01253; Fri, 21 Mar 1997 12:49:17 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-rsvp-policy-ext-02.txt, .ps
Date: 21 Mar 1997 12:49:14 -0500
Organization: Rutgers University
Lines: 96
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhmq$162$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : RSVP Extensions for Policy Control
Author(s) : S. Herzog
Filename : draft-ietf-rsvp-policy-ext-02.txt, .ps
Pages : 16
Date : 03/20/1997
This memo describes a set of extensions for supporting generic policy
based admission control in RSVP. [Note 1]
These extensions include the standard format of POLICY_DATA objects,
a generic RSVP/Policy-Control interface, and a description of
RSVP's handling of policy events.
This document does not advocate particular policy control mechanisms;
however, a Router/Server Policy Protocol description for these
extensions can be found in [LPM].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-policy-ext-02.txt".
Or
"get draft-ietf-rsvp-policy-ext-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-ext-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-policy-ext-02.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-policy-ext-02.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320104156.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-policy-ext-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-policy-ext-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320104156.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03283; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02293; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15040;
21 Mar 97 12:57 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17061>; Fri, 21 Mar 1997 09:54:03 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01480; Fri, 21 Mar 1997 12:54:01 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-rsvp-policy-oops-00.txt
Date: 21 Mar 1997 12:53:58 -0500
Organization: Rutgers University
Lines: 86
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhvm$1df$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Open Outsourcing Policy Service (OOPS) for RSVP
Author(s) : S. Herzog, D. Pendarakis, R. Rajan, R. Guerin
Filename : draft-ietf-rsvp-policy-oops-00.txt
Pages : 29
Date : 03/20/1997
This document describes a protocol for exchanging policy information and
decisions between an RSVP-capable router (client) and a policy server. The
OOPS protocol supports a wide range of router configurations and RSVP
implementations, and is compatible with the RSVP Extensions for Policy
Control [Ext].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-policy-oops-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-oops-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-policy-oops-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320104544.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-policy-oops-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-policy-oops-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320104544.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03218; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02239; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15016;
21 Mar 97 12:56 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17011>; Fri, 21 Mar 1997 09:53:55 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01238; Fri, 21 Mar 1997 12:49:09 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-ediint-req-02.txt
Date: 21 Mar 1997 12:49:05 -0500
Organization: Rutgers University
Lines: 86
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhmh$135$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Electronic Data
Interchange-Internet Integration Working Group of the IETF.
Title : Requirements for Inter-operable Internet EDI
Author(s) : C. Shih, M. Jansson, R. Drummond
Filename : draft-ietf-ediint-req-02.txt
Pages : 39
Date : 03/20/1997
This document is a functional specification, discussing the
requirements for inter-operable EDI, with sufficient background
material to give an explanation for the EDI community of the
Internet, and security related issues.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ediint-req-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ediint-req-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ediint-req-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320100042.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ediint-req-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ediint-req-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320100042.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03261; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02331; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15056;
21 Mar 97 12:57 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17089>; Fri, 21 Mar 1997 09:54:10 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01386; Fri, 21 Mar 1997 12:51:47 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-crowcroft-rmfp-01.txt
Date: 21 Mar 1997 12:51:44 -0500
Organization: Rutgers University
Lines: 83
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhrg$1b1$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RMFP: A Reliable Multicast Framing Protocol
Author(s) : J. Crowcroft, Z. Wang, A. Ghosh, C. Diot
Filename : draft-crowcroft-rmfp-01.txt
Pages : 5
Date : 03/20/1997
There has been considerable interest in reliable multicast, and a number of
reliable multicast transport applications and systems have been built in
the past years.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-crowcroft-rmfp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-crowcroft-rmfp-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-crowcroft-rmfp-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320141855.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-crowcroft-rmfp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-crowcroft-rmfp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320141855.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03266; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02297; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15036;
21 Mar 97 12:57 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17049>; Fri, 21 Mar 1997 09:54:02 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01255; Fri, 21 Mar 1997 12:49:17 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-svrloc-protocol-16.txt
Date: 21 Mar 1997 12:49:15 -0500
Organization: Rutgers University
Lines: 89
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhmr$14m$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Service Location Protocol
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Service Location Protocol
Author(s) : J. Veizades, E. Guttman, C. Perkins, S. Kaplan
Filename : draft-ietf-svrloc-protocol-16.txt
Pages : 72
Date : 03/20/1997
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet no longer need so much static configuration of
network services for network based applications. This is especially
important as computers become more portable, and users less tolerant or
able to fulfill the demands of network system administration.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-protocol-16.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-protocol-16.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-protocol-16.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320131943.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-protocol-16.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-protocol-16.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320131943.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03290; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02410; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15068;
21 Mar 97 12:57 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17122>; Fri, 21 Mar 1997 09:54:20 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01358; Fri, 21 Mar 1997 12:51:01 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-ietf-frnetmib-frs-mib-01.txt
Date: 21 Mar 1997 12:50:59 -0500
Organization: Rutgers University
Lines: 88
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhq3$1ab$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Frame Relay Service MIB
Working Group of the IETF.
Title : Definitions of Managed Objects for Frame Relay Service
Author(s) : D. Fowler
Filename : draft-ietf-frnetmib-frs-mib-01.txt
Pages : 64
Date : 03/20/1997
This memo defines an extension to the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Frame Relay Service.
This memo does not specify a standard for the Internet community.
This document entirely replaces RFC 1604.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-frnetmib-frs-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-frnetmib-frs-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-frnetmib-frs-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320114453.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-frnetmib-frs-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-frs-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320114453.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03204; 21 Mar 97 12:59 EST
Received: from cnri by ietf.org id aa02243; 21 Mar 97 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15019;
21 Mar 97 12:56 EST
Received: from RUTGERS.EDU by venera.isi.edu (5.65c/5.61+local-26)
id <AA17032>; Fri, 21 Mar 1997 09:53:58 -0800
Received: (from daemon at localhost) by RUTGERS.EDU (8.6.12+bestmx+oldruq+newsunq/8.6.12) id MAA01244; Fri, 21 Mar 1997 12:49:12 -0500
To: ru-comp-dev-ietf at rutgers.edu
Path: usenet
Sender:ietf-request at ietf.org
From: Internet-Drafts at ietf.org
Newsgroups: ru.comp.dev.ietf
Subject: I-D ACTION:draft-mcdonald-simple-ipsec-api-01.txt
Date: 21 Mar 1997 12:49:06 -0500
Organization: Rutgers University
Lines: 87
X-Orig-Sender: news at rutgers.edu
Message-Id: <5guhmi$12p$1 at rutgers.rutgers.edu>
Source-Info: From (or Sender) name not authenticated.
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Simple IP Security API Extension to BSD Sockets
Author(s) : D. McDonald
Filename : draft-mcdonald-simple-ipsec-api-01.txt
Pages : 12
Date : 03/20/1997
In order to take advantage of the IP Security Architecture [Atk95], an
application should be able to tell the system what IP-layer security
services it needs to function with some degree of confidence. A simple
API that also allows simple security association policy to be set is
presented here. This document descends from earlier work performed in the
U. S. Naval Research Laboratory's IPv6 and IP security implementation
[AMPMC96].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-mcdonald-simple-ipsec-api-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-mcdonald-simple-ipsec-api-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320103642.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mcdonald-simple-ipsec-api-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320103642.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04936; 21 Mar 97 13:04 EST
Received: from hp.rz.uni-potsdam.de by ietf.org id aa04823; 21 Mar 97 13:03 EST
Received: from rz.uni-potsdam.de (persius.rz.uni-potsdam.de) by hp.rz.uni-potsdam.de with ESMTP
(1.37.109.10G/16.2) id AA217187047; Fri, 21 Mar 1997 18:57:27 +0100
Received: from jhartman.rz.uni-potsdam.de by rz.uni-potsdam.de (SMI-8.6/SMI-SVR4)
id SAA06450; Fri, 21 Mar 1997 18:59:23 +0100
Message-Id: <33326DC2.FD0 at pobox.com>
Date: Fri, 21 Mar 1997 12:15:14 +0100
Sender:ietf-request at ietf.org
From: Joerg Hartmann <joerg.hartmann at pobox.com>
Reply-To: ecology at pobox.com
Organization: Oekologie & Innovationen
X-Mailer: Mozilla 4.0b2 (Win95; I)
Mime-Version: 1.0
To: ietf at ietf.org
Subject: Re: remove
X-Priority: 3 (Normal)
References: <199703112315.RAA23372 at uh.msc.edu> <v0302090faf4cc0de605b at [128.2.98.8]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
All the problems of a list server (unsubscribe/remove mails, quoted
digests ...) don't exist if you just replace the list server with a
simple NNTP newsserver, of course running closed/private newsgroups, not
public ones.
Joshua D. Baer wrote:
>
> At 9:13 PM -0500 3/11/97, Cleve Graves wrote:
>
> So why don't we put a "remove/unsubscribe" filter in,
> monitor what it takes out and doesn't take out, correct
> problems, and make out listserver a model for what to expect
> a listserver to do now that we have Internet toaster and
> "toaster USERS". And let us not forget that USER always has
> been and always will be a four letter word.... Thank god,
> for what would we be doing without them?
>
> This is the approach I took with the latest release of ListSTAR for
> the Macintosh. I've NEVER seen someone post a message to the list with
> subject "remove" who really wanted to post something. So we trap for
> it, and unsubscribe the person. Our server has it's own simple syntax,
> but we also accept all other listserver syntaxes, because we know
> people are going to send them anyway. Very few messages like this ever
> get posted to the list. Other list managers have done this to a lesser
> degree, such as LetterRip and Lyris.
>
> Again, if you'r interested in helping stop this, check out the List
> Headers proposal.
>
> <URL:mailto:list-header at arpp.carleton.ca?subject=subscribe>
>
> ~Josh
>
> -- ----------------------------------
> Joshua D. Baer
>
> SkyList Mailing List Hosting Service
> http://cgi.skyweyr.com/Guest.Login
--
Ecology & Innovations, mailto:ecology at pobox.com,
http://pobox.com/~ecology/
Hebbelstrasse 9, D-14469 Potsdam, Germany Phone: +49-(0)331-27092-15
P.O. Box 600844, D-14408 Potsdam Fax/3: +49-(0)331-27092-17
CEO + MD IT/OS Mr. Joerg Hartmann, mailto:joerg.hartmann at pobox.com,
http://pobox.com/~ecology/joerg.hartmann/
Received: from cnri by ietf.org id aa05376; 21 Mar 97 13:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15384;
21 Mar 97 13:07 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA07112 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 15:41:26 GMT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, ietf.org at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: cat-ietf at mit.edu
From: Internet-Drafts at ietf.org
Reply-To: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-gssv2-cbind-04.txt
Date: Fri, 21 Mar 1997 09:53:08 -0500
Message-Id: <9703210953.aa15881 at ietf.org>
Precedence: bulk
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : Generic Security Service API Version 2 : C-bindings
Author(s) : J. Wray
Filename : draft-ietf-cat-gssv2-cbind-04.txt
Pages : 94
Date : 03/20/1997
This draft document specifies C language bindings for Version 2 of the
Generic Security Service Application Program Interface (GSSAPI), which is
described at a language-independent conceptual level in other drafts
[GSSAPI]. It revises RFC-1509, making specific incremental changes in
response to implementation experience and liaison requests. It is
intended, therefore, that this draft or a successor version thereof will
become the basis for subsequent progression of the GSS-API specification on
the standards track.
The Generic Security Service Application Programming Interface provides
security services to its callers, and is intended for implementation atop a
variety of underlying cryptographic mechanisms. Typically, GSSAPI callers
will be application protocols into which security enhancements are
integrated through invocation of services provided by the GSSAPI. The
GSSAPI allows a caller application to authenticate a principal identity
associated with a peer application, to delegate rights to a peer, and to
apply security services such as confidentiality and integrity on a
per-message basis.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-cat-gssv2-cbind-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-cbind-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970320103307.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-gssv2-cbind-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-gssv2-cbind-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970320103307.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14415; 21 Mar 97 15:01 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa13874; 21 Mar 97 14:58 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id OAA25310;
Fri, 21 Mar 1997 14:55:14 -0500
Message-Id: <199703211955.OAA25310 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: rossg at cpd.co.uk
Cc: ietf at ietf.org
Subject: Re: Re[2]: RFC 2118 - the start of a new era?
In-Reply-To: Your message of "Fri, 21 Mar 1997 15:00:06 GMT."
<199703211500.PAA13881 at esprit.cpd.co.uk>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199703211500.PAA13881 at esprit.cpd.co.uk>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_2023581600P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 21 Mar 1997 14:55:13 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_2023581600P
Content-Type: text/plain; charset=us-ascii
On Fri, 21 Mar 1997 15:00:06 GMT, rossg at cpd.co.uk said:
> It is GOOD when any company, not just Micro$oft, promote
> inter-operability between competing products like this. When will I be
> able to use MS Word for Unix :-)?
You can. It's called Emacs.
No wait.. That's a *different* huge bloated collection of software
that started off life as an editor and evolved into something else ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_2023581600P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMzLnn9QBOOoptg9JAQGSQAQAr+zMsTdZxbTY3/WHwvaQO+Vr40bHOguy
Ik2lRwIbUW+YjOFIWoUjkl4y4HbqLHDgc5ytWACWRN47ntvD/xq6KJ+ZAol3ONo4
0W+nICLahqetovHMEOkMREWdEEneyVB7UFe0RjrMgIrPITSE0/8Bv/OTWZ7jQNo7
u8QdBOOBgb8=
=/ATS
-----END PGP MESSAGE-----
--==_Exmh_2023581600P--
Received: from cnri by ietf.org id aa15489; 21 Mar 97 15:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18288;
21 Mar 97 15:08 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA14152 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 18:25:12 GMT
Date: Fri, 21 Mar 1997 13:25:06 -0500
Message-Id: <9703211825.AA20627 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Fri, 21 Mar 1997 07:41:44 -0500,
<199703211241.HAA27725 at gza-client1.cam.ov.com>
Subject: Re: Name type issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Fri, 21 Mar 1997 07:41:44 -0500
From: John Linn <linn at cam.ov.com>
(2) Specifically regarding the User Name form, it's described as
referring to a local user name with interpretation as defined by the
local OS. (While the name's structure is OS-defined, there's no
requirement that the set of names of this type which a mechanism can
import need have any correspondence with the set of users registered
on a local machine.) RFC-1964 describes, e.g., this name form's
likely processing within a Kerberos mechanism implementation as being
accomplished by postfixing a "@" separator and realm specifier to the
basic local username. The User Name form, therefore, isn't documented
as a means to import a distributed-level name in a manner which is
supportable across mechanisms, such as we have for target services in
the Host-Based Service name form. QUESTION: should we recommend or
require such a facility and, if so, do people have preferences among
the following possibilities:
I don't think so..... I don't quite see the motivation for doing this.
How and where would this be useful?
(2a) Recommend that User Name implementations optionally accept local
names postfixed with some form of domain specifier; here, I'd be
concerned that we'd be implying that the input should comprise a
hard-to-describe hybrid form where some elements' structure is defined
by the local OS and others by the mechanism in question
I think this is a bad idea. Suppose we use '@' to indicate the domain
specifier prefix --- what for a particular OS, '@' is a valid character
found in a local username?
I could imagine a new OID type which implies "distributed-level naming",
where the '@' served as the separator, and '@' in the local name would
have to be escaped using a backslash, but this adds a lot of complexity,
and I'm not sure that the attendant gain in functionality is worth it.
(2b) Recommend that GSS_Import_name with a GSS_C_NO_OID tag act
equivalently to GSS_Import_name with the tag which corresponds to the
native name form of the importing mechanism
(2c) Define a new name type to indicate "native name form of importing
mechanism"
How is "native name form" different from "local username"? Are you
assuming that "native name form" includes a domain specifier here?
- Ted
Received: from ietf.org by ietf.org id aa19942; 21 Mar 97 15:54 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa19606; 21 Mar 97 15:49 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id PAA32948;
Fri, 21 Mar 1997 15:46:37 -0500
Message-Id: <199703212046.PAA32948 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0gamma 1/27/96
To: ecology at pobox.com
Cc: ietf at ietf.org
Subject: Re: remove
In-Reply-To: Your message of "Fri, 21 Mar 1997 12:15:14 +0100."
<33326DC2.FD0 at pobox.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199703112315.RAA23372 at uh.msc.edu> <v0302090faf4cc0de605b at [128.2.98.8]>
<33326DC2.FD0 at pobox.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-2120418292P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 21 Mar 1997 15:46:36 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-2120418292P
Content-Type: text/plain; charset=us-ascii
On Fri, 21 Mar 1997 12:15:14 +0100, you said:
> All the problems of a list server (unsubscribe/remove mails, quoted
> digests ...) don't exist if you just replace the list server with a
> simple NNTP newsserver, of course running closed/private newsgroups, not
> public ones.
One word: Firewalls.
The current list works for *anybody* in the world who has basic E-mail
connectivity, no matter how complicated, or how it is
implemented. Doing it as a newsgroup implies a requirement that all
participants be able to handle netnews. A netnews reader may not be
available for their system, or there may be corporate firewall
restrictions in place for where they currently read the IETF list
(requiring them to get access elsewhere just to participate). You
also get to worry about propogating the newsgroup(*), and all the
other associated problems.
(*) You *could* run just one server I suppose, if you're willing to
deal with it getting pounded with NNTP requests and all that. But
then you have to worry about having an NNTP spool, making sure that
there's connectivity to *everyplace* all the time, and so on.
The current IETF has as a membership requirement *ONLY* that you have
E-mail access *somewhere* on the planet. Be very careful about any
changes that would "raise the bar" for entry.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-2120418292P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMzLzqtQBOOoptg9JAQGxaAP+Ip8ye4Qee/wSEkYgaDDKMmqIgGiJCi1c
voBrmROotk9Lm8KJcsVrJafimzeQqZvavpMR5WSeo13K08m/adYgqig4I2iROtd3
pcCTBeQ81wGyTxdvxh1e0ENMbxynyXgPYwidcT23BD5VHLd4+7ce0KnDOSC0Fozi
BWPKKSG2gu0=
=96AO
-----END PGP MESSAGE-----
--==_Exmh_-2120418292P--
Received: from cnri by ietf.org id aa29711; 21 Mar 97 17:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21965;
21 Mar 97 17:40 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA19336 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 20:38:45 GMT
Date: Fri, 21 Mar 1997 15:38:24 -0500
Message-Id: <9703212038.AA20792 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Thu, 20 Mar 1997 11:55:08 -0500 (EST),
<199703201655.AA05496 at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Thu, 20 Mar 1997 11:55:08 -0500 (EST)
What I acutally wanted to ask for: How does a "portable" application
that wants to use ACLs based on exported names how to populate this ACL?
I.e. how many and which "true" mechanisms are available, and how
many entries need to go into the ACL for each user?
Well, it can use gss_indicate_mechs() to indicate which mechanisms are
available, and then call gss_inquire_names_for_mech to get a list of
name types. It will need to somehow translate the OID's into a
printable string representation (note there are internationalizational
issues here).
The administrator would then have to populate the ACL by choosing a
mechanism and a name type (probably from pick lists), and then typing in
the name which would be fed to gss_import_name(). In a general case,
where there might be a large number of mechanisms and name types, yes
this could get a bit messy. I'd be quite surprised if there were more
than a handful of sites that used 2 or at most 3 GSSAPI mechanisms,
though.
I currently only have provisions for exactly one "canonical" exported name;
so if a customer wants to replace a single-mechanism or mechanism family
with a multi-mechanism sort of like kerberos + spkm, I will have to supply
a mechanism OID to disable negotiation so that the existing ACL will
continue to work.
This makes the extra functionality of the negotiating multi-mechanism
effectively useless ...
Well, what it means is that each user will only be able to login to your
application using either Kerberos or SPKM. This is unfornate, but the
'L' in ACL generally implies that you can handle multiple ACL entries
--- "list" usually means more than one!
- Ted
Received: from ietf.org by ietf.org id aa03123; 21 Mar 97 18:12 EST
Received: from shell1.aimnet.com by ietf.org id aa02739; 21 Mar 97 18:09 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.5/SHELL) with SMTP id PAA14535; Fri, 21 Mar 1997 15:06:23 -0800 (PST)
Date: Fri, 21 Mar 1997 15:06:22 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Valdis.Kletnieks at vt.edu
cc: ecology at pobox.com, ietf at ietf.org
Subject: Replace mail list with netnews? [was: Re: remove
In-Reply-To: <199703212046.PAA32948 at black-ice.cc.vt.edu>
Message-ID: <Pine.SOL.3.95.970321150422.14088A-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 21 Mar 1997 Valdis.Kletnieks at vt.edu wrote:
> On Fri, 21 Mar 1997 12:15:14 +0100, you said:
> > All the problems of a list server (unsubscribe/remove mails, quoted
> > digests ...) don't exist if you just replace the list server with a
> > simple NNTP newsserver, of course running closed/private newsgroups, not
> > public ones.
>
> One word: Firewalls.
Second words: It expires, usually too quickly
Dave Morris
Received: from cnri by ietf.org id aa04881; 21 Mar 97 18:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23131;
21 Mar 97 18:33 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA21393 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 21:26:49 GMT
Message-Id: <199703212126.AA00485 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Fri, 21 Mar 1997 16:26:06 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703212038.AA20792 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 21, 97 03:38:24 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
>
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Thu, 20 Mar 1997 11:55:08 -0500 (EST)
>
> What I acutally wanted to ask for: How does a "portable" application
> that wants to use ACLs based on exported names how to populate this ACL?
> I.e. how many and which "true" mechanisms are available, and how
> many entries need to go into the ACL for each user?
>
> Well, it can use gss_indicate_mechs() to indicate which mechanisms are
> available, and then call gss_inquire_names_for_mech to get a list of
> name types. It will need to somehow translate the OID's into a
> printable string representation (note there are internationalizational
> issues here).
So the application has to be told about some the details of the mechanism,
It won't work automagically. Ok, that's what I assumed.
So the portability in this area cannot be compiled in a priori.
It has to be "learned" by the application when it gets to know that
mechanism. Compiled into a newer release or customer-configurable.
>
> The administrator would then have to populate the ACL by choosing a
> mechanism and a name type (probably from pick lists), and then typing in
> the name which would be fed to gss_import_name(). In a general case,
> where there might be a large number of mechanisms and name types, yes
> this could get a bit messy. I'd be quite surprised if there were more
> than a handful of sites that used 2 or at most 3 GSSAPI mechanisms,
> though.
>
> I currently only have provisions for exactly one "canonical" exported name;
> so if a customer wants to replace a single-mechanism or mechanism family
> with a multi-mechanism sort of like kerberos + spkm, I will have to supply
> a mechanism OID to disable negotiation so that the existing ACL will
> continue to work.
>
> This makes the extra functionality of the negotiating multi-mechanism
> effectively useless ...
>
> Well, what it means is that each user will only be able to login to your
> application using either Kerberos or SPKM. This is unfornate, but the
> 'L' in ACL generally implies that you can handle multiple ACL entries
> --- "list" usually means more than one!
Well, it's not really a problem with my ACL, it's a problem with the
mapping of chamaeleons onto single names, which a combined negotiating
krb5+spkm multimechanism probably won't do. That's one of the reasons
that I wanted a "canonical" name, something that a non-family negotiating
multi-mech might not be able to offer.
-Martin
Received: from cnri by ietf.org id aa06452; 21 Mar 97 18:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23574;
21 Mar 97 18:57 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA16928 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 19:31:26 GMT
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu
Subject: Re: Name type issues
References: <199703211241.HAA27725 at gza-client1.cam.ov.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 21 Mar 1997 14:30:51 -0500
In-Reply-To: John Linn's message of Fri, 21 Mar 1997 07:41:44 -0500
Message-Id: <t53ybbhoxec.fsf at rover.cygnus.com>
Lines: 54
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
John Linn <linn at cam.ov.com> writes:
>> The User Name form, therefore, isn't documented
>> as a means to import a distributed-level name in a manner which is
>> supportable across mechanisms, such as we have for target services in
>> the Host-Based Service name form.
This is correct, but I don't believe this is a problem. The intent is
that this name be used to convert a local form into a global form for
the purposes of initiating a gss context. This conversion is
inherently mechanism specific. The Host-Based Service name form is
used to identify the remote peer, and therefore needs to name a
service in a more global context.
I'd really prefer not to see this intent codified, as this would seem
to be overspecification. Applications should be checking for
import_name failure, and handling it accordingly.
>> QUESTION: should we recommend or
>> require such a facility and, if so, do people have preferences among
>> the following possibilities:
>>
>> (2a) Recommend that User Name implementations optionally accept local
>> names postfixed with some form of domain specifier; here, I'd be
>> concerned that we'd be implying that the input should comprise a
>> hard-to-describe hybrid form where some elements' structure is defined
>> by the local OS and others by the mechanism in question
If there is some local notion of domain specifier, then the existing
definiton ("named user on a local system") would seem to be adequate.
Otherwise, I think your concern is warranted. I don't believe there
is any reasonable generic definition of a domain specifier. If such a
thing comes into existence in the future, we can define a new name
type or extend an old one at that time.
>> (2b) Recommend that GSS_Import_name with a GSS_C_NO_OID tag act
>> equivalently to GSS_Import_name with the tag which corresponds to the
>> native name form of the importing mechanism
This assumes that there is a single qualified native name form. This
is not necessarily the case.
>> (2c) Define a new name type to indicate "native name form of importing
>> mechanism"
See above.
>> (2d) Explicitly preclude (2b) and (2c), and require that the native
>> name form be explicitly tagged with a non-generic value
This seems like the best answer. If there are multiple native name
forms, then each can be assigned its own, non-generic value.
Marc
Received: from cnri by ietf.org id aa08412; 21 Mar 97 19:24 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24128;
21 Mar 97 19:24 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA25140 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 23:05:42 GMT
Date: Sat, 22 Mar 1997 00:05:23 +0100
Message-Id: <199703212305.AAA19815 at p18509.wdf.sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
To: cat-ietf at mit.edu
Subject: diffs between cbind-03 and -04
Precedence: bulk
FYI, I have just finished "analyzing" the differences between
draft-ietf-cat-gssv2-cbind-03.txt and -04 and I have composed
a manually digested "diff -bc" file. It's about 108 Kbyte, so
I won't send it to the list, but if anyone is interested,
drop me a mail.
-Martin
Received: from cnri by ietf.org id aa10518; 21 Mar 97 20:31 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25129;
21 Mar 97 20:31 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <AAA27980 at pad-thai.cam.ov.com>; Sat, 22 Mar 1997 00:30:44 GMT
Date: Fri, 21 Mar 1997 19:30:38 -0500
Message-Id: <9703220030.AA20965 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Fri, 21 Mar 1997 16:26:06 -0500 (EST),
<199703212126.AA00485 at sap-ag.de>
Subject: Re: Comments solicited re negotiated mechanism action
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Fri, 21 Mar 1997 16:26:06 -0500 (EST)
So the application has to be told about some the details of the mechanism,
It won't work automagically. Ok, that's what I assumed.
So the portability in this area cannot be compiled in a priori.
It has to be "learned" by the application when it gets to know that
mechanism. Compiled into a newer release or customer-configurable.
Well the only thing you really need is the OID to <descriptive name in
locale-appropriate language>. I suppose we could add a GSSAPI call
which did this translation (which took a ISO 3 character locale as an
argument).
Well, it's not really a problem with my ACL, it's a problem with the
mapping of chamaeleons onto single names, which a combined negotiating
krb5+spkm multimechanism probably won't do. That's one of the reasons
that I wanted a "canonical" name, something that a non-family negotiating
multi-mech might not be able to offer.
You're assuming that there is a "canonical name". If krb5 and spkm are
using disjoint namespaces, there might not be any way to map names from
the two namespaces into a single canonical namespace. How then, could
there be a "canonical" name?
- Ted
Received: from cnri by ietf.org id aa11457; 21 Mar 97 21:22 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25786;
21 Mar 97 21:22 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA26560 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 23:47:04 GMT
Message-Id: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970321233127Z-28587 at bwdldb.ott.bnr.ca>
From: Carlisle Adams <Cadams at entrust.com>
To: "'\"508/486-5210 20-Mar-1997 1130\"@bnr400wray at tuxedo.enet.dec.com'" <@tuxedo.enet.dec.com:"508/486-5210 20-Mar-1997 1130"@bnr400wray>
Cc: "'cat-ietf at mit.edu'" <cat-ietf at mit.edu>,
"'wray at tuxedo.enet.dec.com'" <wray at tuxedo.enet.dec.com>
Subject: RE: IDUP-GSS-API
Date: Fri, 21 Mar 1997 18:31:27 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Encoding: 69 TEXT
Precedence: bulk
Hi John,
>----------
>From: "508/486-5210 20-Mar-1997
>1130"@bnr400wray at tuxedo.enet.dec.com[SMTP:"508/486-5210 20-Mar-1997
>1130"@bnr400wray at tuxedo.enet.dec.com]
>Sent: Thursday, March 20, 1997 12:40 PM
>To: Carlisle Adams; Carlisle Adams; cat-ietf at mit.edu
>Cc: cat-ietf at mit.edu; wray at tuxedo.enet.dec.com
>Subject: IDUP-GSS-API
>
>Carlisle,
>
>I apologise for sending extensive comments at such a late stage, but I've
>recently been doing some IDUP-related work and found the following issues
>with
>the -06 draft of the IDUP spec.
I've had deadlines on a few projects right around this time so, assuming
I can even get the next draft of IDUP out in time for the submission
cutoff, I think it's unlikely that it will address many of your
comments.
Let me just note, however, that Denis has contributed a set of calls
(modeled on the SE calls) which are specific to evidence generation and
verification. These seem to move in the direction you were hoping for.
I feel, though, that the simple calls need to live in conjunction with
the more complicated calls (i.e., that removing the more complicated
calls would be the wrong approach). Many calling applications currently
only need to do relatively simple things and so will only use the simple
calls. As time progresses, I think it will not be uncommon for an
application to sign and encrypt data and ask for a proof of receipt from
the recipient(s) all at the same time. Such an application will only
want to input the data *once* and get back a blob to send out.
Protocols like MSP already do this: you ask for confidentiality, ask
for proof of origin, and request a receipt from some subset of
recipients, for example, and what comes back is a single,
properly-formatted ASN.1 structure. It is not at all clear to me how
this can be accomplished with a set of separate calls without requiring
the application to effectively input the data several times.
As complicated as the big calls are, with the multiple levels of
parameter bundles, I believe they are useful to sophisticated
applications that need to do a number of security services at once.
Again, most current calling applications do not need to use the more
complicated calls and it is not even required that mechanism
implementers implement them (it is only recommended). They exist for
the more sophisticated applications and mechanisms to use when they are
needed.
Finally, I'll just note that the parameter bundles and the more
complicated calls are not impossible to implement. Our designers have
implemented IDUP over a number of mechanisms without undue difficulty...
Again, I'm sorry for not responding to your more detailed comments (due
to lack of time); I hope to have given them serious consideration by
Memphis.
--------------------------------------
Carlisle Adams
Entrust Technologies
cadams at entrust.com
---------------------------------------
Received: from cnri by ietf.org id aa11683; 21 Mar 97 21:29 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25867;
21 Mar 97 21:29 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA26369 at pad-thai.cam.ov.com>; Fri, 21 Mar 1997 23:42:40 GMT
Message-Id: <199703212341.AA06279 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Name type issues
To: John Linn <linn at cam.ov.com>
Date: Fri, 21 Mar 1997 18:40:58 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703211241.HAA27725 at gza-client1.cam.ov.com> from "John Linn" at Mar 21, 97 07:41:44 am
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
>
> Some points re name types, triggered by a query I received from
> Martin Rex:
>
> (1) RFC-2078 contains definitions for three name types (User Name
> form, Machine UID form, and String UID form) which were originally
> included in RFC-1964. Unfortunately, the caveat paragraph which
> accompanied them in 1964, recognizing their UNIX-specific lineage and
> acknowledging the fact that additional or alternative types might be
> needed to handle local user ID forms for other OSs, didn't survive the
> editorial processing from one document to the other. This raises, to
> me, the following thoughts:
>
> (1a) We should record the intent to resurrect the caveat for RFC-2078.
>
> (1b) QUESTION: What's current implementation practice, if any,
> concerning support and anticipated structure for names of these types
> on non-UNIX platforms?
Currently RFC2078 explicitly mentions "uid_t" which is a "C" datatype
from the POSIX specification. Should the use of GSS_C_NT_MACHINE_UID_NAME
and GSS_C_NT_STRING_UID_NAME be restricted to POSIX "uid_t" ?
Alternative numeric user names might be DCE/Sesame UUIDs or
UUIDs/SIDs on Win32. Are these *UID* nametypes mentioned in the X/Open
version of GSS-API? Are they offered by DCE's or Sesame's GSS-API ?
If yes, what do they accept as UIDs?
Personally, I wouldn't mind to keep the POSIX uid_t restriction
(it would just make these nametypes unavailable for non-POSIX platforms).
>
> (2) Specifically regarding the User Name form, it's described as
> referring to a local user name with interpretation as defined by the
> local OS. (While the name's structure is OS-defined, there's no
> requirement that the set of names of this type which a mechanism can
> import need have any correspondence with the set of users registered
> on a local machine.) RFC-1964 describes, e.g., this name form's
> likely processing within a Kerberos mechanism implementation as being
> accomplished by postfixing a "@" separator and realm specifier to the
> basic local username. The User Name form, therefore, isn't documented
> as a means to import a distributed-level name in a manner which is
> supportable across mechanisms, such as we have for target services in
> the Host-Based Service name form. QUESTION: should we recommend or
> require such a facility and, if so, do people have preferences among
> the following possibilities:
>
> (2a) Recommend that User Name implementations optionally accept local
> names postfixed with some form of domain specifier; here, I'd be
> concerned that we'd be implying that the input should comprise a
> hard-to-describe hybrid form where some elements' structure is defined
> by the local OS and others by the mechanism in question
>
> (2b) Recommend that GSS_Import_name with a GSS_C_NO_OID tag act
> equivalently to GSS_Import_name with the tag which corresponds to the
> native name form of the importing mechanism
>
> (2c) Define a new name type to indicate "native name form of importing
> mechanism"
>
> (2d) Explicitly preclude (2b) and (2c), and require that the native
> name form be explicitly tagged with a non-generic value
The high level spec currently says about the "User name form" that it
is "OS specific". I would say that the current practice (and my
understanding up to now) rather is: the User name form is mechanism specific
and may be subject to OS restrictions for some implementations.
My reasoning is that probably most GSS-API implementations do support
the User name form, but happily accept their native "principal name form"
totally independent of the actual integration with the operating system.
I expect most GSS-API implementations to accept the User name form, even
when the underlying OS doesn't know or distinguish users.
What is "OS specific" supposed to mean for the User name form" anyway?
Is it supposed to mean that the input is unconditionally subjected to the
local OS syntax rules for usernames. On top of syntax, is it required
that the user also exists on the local machine?
What does Kerberos do when one acquires initiating credentials for
user "foo"? Does it look for the credentials cache of the user "foo"
and tries to use it independent of the principal name described by
these credentials? Or does it look in the current users credentials
cache for the credentials of the principal "foo at default.realm" ?
If it does the latter, then it is interpreting the name definitely
mechanism specific and *NOT* OS specific.
I assume that all Kerberos-based gssapi implementations will
accept a principal name accompanied by GSS_C_NT_USER_NAME,
and according to RFC1964, a Kerberos Principal name can contain
any possible character (some have to be escaped), which is probably
more than any traditional OS will accept.
IMHO the current usage is a little out of sync with the spec,
and the spec is a little fuzzy (because it doesn't give any hint
in which respect the User name form is supposed to be "OS specific").
Personally I really don't mind the current usage, rather I'd like
the spec to be clarified and sync'ed with reality.
... talking about RFC1964; it's funny how it "regulates" binary
exported names vs printable names:
2.1.1. Kerberos Principal Name Form
(1b) The ASCII newline, tab, backspace, and null characters
may occur directly within the component or may be
represented, respectively, by `\n`, `\t`, `\b`, or `\0`.
2.1.3. Exported Name Object Form for Kerberos V5 Mechanism
(2) all occurrences of the null, backspace, tab, or newline
characters within principal components or realm names will be
represented, respectively, with `\0`, `\b`, `\t`, or `\n`.
The exported names, which are supposed to be binary, are supposed to
escape dangerous characters; for the printable Kerberos principal name
form the escaping of the dangerous characters LF, TAB, BS and NUL is
only optional. Having NUL in the middle of a printable string in
the C-Language will definitely cause trouble.
For GSS-API I'd like to see the requirement that all control characters
have to be escaped in printable string encoded names returned from
display_name()!
-Martin
Received: from cnri by ietf.org id aa15159; 22 Mar 97 21:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17580;
22 Mar 97 21:53 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <BAA09564 at pad-thai.cam.ov.com>; Sun, 23 Mar 1997 01:20:53 GMT
To: Martin.Rex at sap-ag.de
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu
Subject: Re: Name type issues
References: <199703212341.AA06279 at sap-ag.de>
From: Marc Horowitz <marc at cygnus.com>
Date: 22 Mar 1997 20:20:36 -0500
In-Reply-To: Martin Rex's message of Fri, 21 Mar 1997 18:40:58 -0500 (EST)
Message-Id: <t53bu8bwgij.fsf at rover.cygnus.com>
Lines: 82
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> The high level spec currently says about the "User name form" that it
>> is "OS specific". I would say that the current practice (and my
>> understanding up to now) rather is: the User name form is mechanism specific
>> and may be subject to OS restrictions for some implementations.
>>
>> My reasoning is that probably most GSS-API implementations do support
>> the User name form, but happily accept their native "principal name form"
>> totally independent of the actual integration with the operating system.
>> I expect most GSS-API implementations to accept the User name form, even
>> when the underlying OS doesn't know or distinguish users.
How do you justify this expectation? On an OS without users, I would
consider it reasonable not to implement this name type.
>> What is "OS specific" supposed to mean for the User name form" anyway?
>> Is it supposed to mean that the input is unconditionally subjected to the
>> local OS syntax rules for usernames. On top of syntax, is it required
>> that the user also exists on the local machine?
It means that the conversion from the input to the underlying
mechanism may be a function of some local conversion. For instance,
under some systems (such as Multics), users' names include the name of
the primary group for the account (such as Bigler.StudentAD, or
Horowitz.Staff). It might be the convention when converting names to
remove the group identifier, since kerberos has no notion of groups.
It would be reasonable to reject names which are of an improper form,
although "be liberal in what you accept" would require the
implementation to have a good reason.
It may be a requirement that the user exist. For instance, if one
were to build a gssapi mechanism based on unix user id's (a bad idea,
I know, but bear with me), it would be impossible to convert from a
username to the associated uid unless the user already existed.
The fact that there really isn't any guaranteed way to generically
name the initiator of a gss context is yet another reason why using
anything but the default name or credential is a bad idea.
>> What does Kerberos do when one acquires initiating credentials for
>> user "foo"? Does it look for the credentials cache of the user "foo"
>> and tries to use it independent of the principal name described by
>> these credentials? Or does it look in the current users credentials
>> cache for the credentials of the principal "foo at default.realm" ?
>> If it does the latter, then it is interpreting the name definitely
>> mechanism specific and *NOT* OS specific.
My unix implementations do the latter. It's not clear that this will
be the case for all implementations. The interpretation of the name
is mechanism *and* OS specific. It just happens that for the common
implementations, the unix contribution to the name transformation is
very simple (an identity).
>> I assume that all Kerberos-based gssapi implementations will
>> accept a principal name accompanied by GSS_C_NT_USER_NAME,
>> and according to RFC1964, a Kerberos Principal name can contain
>> any possible character (some have to be escaped), which is probably
>> more than any traditional OS will accept.
I don't see how you justify this assumption. RFC1964 very clearly
states that the name's "interpretation is OS-specific".
Again, an implementation may be liberal in what it accepts (mine is),
but this is only a recommendation, not a requirement.
>> IMHO the current usage is a little out of sync with the spec,
>> and the spec is a little fuzzy (because it doesn't give any hint
>> in which respect the User name form is supposed to be "OS specific").
>> Personally I really don't mind the current usage, rather I'd like
>> the spec to be clarified and sync'ed with reality.
Well, it's going to remain a little fuzzy unless we define semantics
for all operating systems. The RFC does give one brief example:
Assuming that users' principal names are the same as their local
operating system names, an implementation of GSS_Import_name() based
on Kerberos V5 technology can process names of this form by
postfixing an "@" sign and the name of the local realm.
Marc
Received: from ietf.org by ietf.org id aa24614; 23 Mar 97 2:21 EST
Received: from cnri by ietf.org id aa24252; 23 Mar 97 2:09 EST
Received: from mailsrv2.pcy.mci.net by CNRI.Reston.VA.US id aa02789;
23 Mar 97 2:09 EST
Received: from www.spooknet.com (usr6-dialup21.mix2.Atlanta.mci.net)
by MAIL-CLUSTER.PCY.MCI.NET (PMDF V5.1-6 #10044)
id <01IGTPPCUGB4934ZW1 at MAIL-CLUSTER.PCY.MCI.NET> for IETF at NRI.RESTON.VA.US;
Sun, 23 Mar 1997 02:03:58 EST
Received: from www.spooknet.com (usr6-dialup21.mix2.Atlanta.mci.net)
by MAIL-CLUSTER.PCY.MCI.NET (PMDF V5.1-6 #10044)
with SMTP id <01IGTPP2H64U9350D2 at MAIL-CLUSTER.PCY.MCI.NET> for
IETF at NRI.RESTON.VA.US; Sun, 23 Mar 1997 02:03:36 -0500 (EST)
Date: Sun, 23 Mar 1997 14:50:03 +0000 (GMT)
Sender:ietf-request at ietf.org
From: goblet <spirit at spooknet.com>
Subject: Coffee Anyone?
To: IETF at nri.reston.va.us
Cc:
Reply-to: spirit at spooknet.com
Message-id: <01IGTPP2UDR49350D2 at MAIL-CLUSTER.PCY.MCI.NET>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Mailer:
Source-Info: From (or Sender) name not authenticated.
Hi NetNeighbor,
A net friend of mine gave me a copy of a very unique program you might be interested in.
He sent me the copy through email file attachment after I requested it. This thing really works, I have personally recieved checks from folks I don't even know. My friend told me he would send anyone a copy of the program if they would just request it per the instructions below.
Check it out, I don't think you will be disappointed. It has been tested for viruses and works fine on any IBM compatible computer.
If your not interested in this program, just disregard this information
Have a great day,
Net Neighbor
_____________________________________________________
Get on the road to financial freedom with this revolutionary work-at-home
free software program! Called TUFF(Toward Ultimate Financial Freedom)!!!
(TUFF) is a powerful new work at home money making program that
has almost everything. Perpetual growth system keeps bringing in
money for you even if you cease to personally work the program.
This is so simple, it's crazy. No complicated matrix's or profit centers.
For your FREE review of the TUFF DISK(File is 624K. Takes about three
minutes to download at 28k baud),
Do not hit your reply button!
Reply with "SEND FILE" to:
Tuffdistributor at bigfoot.com
OR send POSTAL ADDRESS by email if you had rather receive a disk via postal mail to:
tuffdistributor at bigfoot.com
-------------------------------------------------------------------------
TUFF IS ETERNAL, RESIDUAL INCOME. No other disk program like it to date.
For your FREE review of the TUFF disk, reply with "SEND FILE", in the subject of your
email to:
tuffdistributor at bigfoot.com.
File is 624K. If you'd prefer a disk sent via
postal mail - reply with your postal address.
-------------------------------------------------------------------------
NEW FREE TUFF DISK. Eternal disk program, you keep earning long after you
have quit marketing the disk! Thousands possible. For your FREE disk,
reply to: tuffdistributor at bigfoot.com with "SEND FILE". File is 624K.
_________________________________________________________________________
Received: from cnri by ietf.org id aa19129; 24 Mar 97 5:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05786;
24 Mar 97 5:39 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <JAA19957 at pad-thai.cam.ov.com>; Mon, 24 Mar 1997 09:12:20 GMT
Message-Id: <3336C405.1238 at frcl.bull.fr>
Date: Mon, 24 Mar 1997 10:12:21 -0800
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: Carlisle Adams <Cadams at entrust.com>
Cc: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: IDUP-GSS-API
References: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-970321233127Z-28587 at bwdldb.ott.bnr.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Carlisle Adams wrote:
> Let me just note, however, that Denis has contributed a set of calls
> (modeled on the SE calls) which are specific to evidence generation and
> verification. These seem to move in the direction you were hoping for.
I have also had the same concern about the complexity of the calls and
was figuring people interrested only for the support of simple evidence
calls.
I expect Carlisle to incorporate my contribution on "EV" calls in the
next revision of IDUP (if time allows for it), however if you want it
sooner posted to the mailing list I can do it. Just tell me or ask for
it.
"EV" calls are currently mimicking the "SE" calls but with a different
set of input/outputs.
> I feel, though, that the simple calls need to live in conjunction with
> the more complicated calls (i.e., that removing the more complicated
> calls would be the wrong approach). Many calling applications currently
> only need to do relatively simple things and so will only use the simple
> calls. As time progresses, I think it will not be uncommon for an
> application to sign and encrypt data and ask for a proof of receipt from
> the recipient(s) all at the same time. Such an application will only
> want to input the data *once* and get back a blob to send out.
Yes. This is a concern that simple calls do not address at this time.
Let me attempt a new proposal based on some ideas from David Kurn.
Calls that can be achieved using a single buffer, should be kept simple
and could stay as there are (only one kind of service at a time or
embedded tokens). As soon as a combination of services would be desired
then long calls (i.e. multiple buffers) would have to be used. These
calls are achieved at least in three steps, the first one being a
"StartXXX" and where no data is inputed. This call would be modified to
provide an environment handle 'env_handle) as an ouput that can then be
re-used as an input for another "StartXXX" call before the processing of
the buffer begins.
In this way we would avoid the complexity of the current Protect calls
with all their bundles but still achieve the goal of combining the
operations.
A minor change that would be needed is to specify when setting the
environment whether including data in the token is desired or not.
> Protocols like MSP already do this: you ask for confidentiality, ask
> for proof of origin, and request a receipt from some subset of
> recipients, for example, and what comes back is a single,
> properly-formatted ASN.1 structure. It is not at all clear to me how
> this can be accomplished with a set of separate calls without requiring
> the application to effectively input the data several times.
I believe that something along my above proposal would solve the
concern.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In addition I will attempt to address another point so that you can
think about it (or respond to it) before Memphis.
GSS-APIs (not IDUP) allow to apply a protection (integrity only or
confidentiality with integrity) in a connection environment between two
correspondents A and B. IDUP-GSS-APIs allow to apply a protection in a
connectionless environment between one correspondent A and multiple
correspondents Bs. While A may protect a message for confidentiality and
integrity it may well apply for B1 for confidentiality and for B2 for
integrity. This means that B1 is able to decrypt but unable to verify
the integrity (do not forget that since IDUP is mechanism independent it
may well apply to secret key technology where B1 does not have the
secret to verify the cryptocheckvalue). This means that, in that case,
two tokens would be embedded so that the output of the first "unprotect"
operation performed by B1 will be used as the input of the second
unprotect operation performed by B2.
In other words, IDUP may well provide embeddded tokens as soon that more
than one service is provided.
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa25401; 24 Mar 97 10:07 EST
Received: from ietf.ietf.org by ietf.org id aa24348; 24 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-l2tp-02.txt
Date: Mon, 24 Mar 1997 09:59:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703240959.aa24348 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Layer Two Tunneling Protocol "L2TP"
Author(s) : K. Hamzeh, T. Kolar, M. Littlewood, G. Pall,
J. Taarud, A. Valencia, W. Verthein
Filename : draft-ietf-pppext-l2tp-02.txt
Pages : 79
Date : 03/21/1997
Virtual dial-up allows many separate and autonomous protocol domains to
share common access infrastructure including modems, Access Servers, and
ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This
document describes the Layer Two Tunneling Protocol (L2TP) which permits
the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using
such tunnels, it is possible to divorce the location of the initial dial-up
server from the location at which the dial-up protocol connection is
terminated and access to the network provided.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-l2tp-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-l2tp-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321153538.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2tp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-l2tp-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321153538.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25403; 24 Mar 97 10:08 EST
Received: from ietf.ietf.org by ietf.org id aa24318; 24 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dhc-interserver-01.txt
Date: Mon, 24 Mar 1997 09:59:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703240959.aa24318 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Dynamic Host Configuration
Working Group of the IETF.
Title : An Inter-server Protocol for DHCP
Author(s) : R. Droms, R. Cole
Filename : draft-ietf-dhc-interserver-01.txt
Pages : 31
Date : 03/21/1997
The DHCP protocol is designed to allow for multiple DHCP servers, so that
reliability of DHCP service can be improved through the use of redundant
servers. To provide redundant service, multiple DHCP servers must carry
the same information about assigned IP addresses and parameters; i.e., the
servers must be configured with the same bindings. Because DHCP servers
may dynamically assign new addresses or configuration parameters, or extend
the lease on an existing address assignment, the bindings on some servers
may become out of date. The DHCP inter-server protocol provides an
automatic mechanism for synchronization of the bindings stored on a set of
cooperating DHCP servers. The underlying capabilities of the DHCP
inter-server protocol required for multiple server cache replications are
based upon the Server Cache Synchronization Protocol (SCSP).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-interserver-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-interserver-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-interserver-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321150018.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-interserver-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-interserver-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321150018.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25395; 24 Mar 97 10:08 EST
Received: from ietf.ietf.org by ietf.org id aa24429; 24 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-carpenter-ipng-6over4-02.txt
Date: Mon, 24 Mar 1997 09:59:34 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703240959.aa24429 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels
Author(s) : B. Carpenter, C. Jung
Filename : draft-carpenter-ipng-6over4-02.txt
Pages : 11
Date : 03/21/1997
This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over IPv4
"domains". For the purposes of this document, an IPv4 domain is a fully
interconnected set of IPv4 subnets on which there is at least one IPv6
router and at least one IPv6 host conforming to this specification. This
IPv4 domain could form part of the globally unique IPv4 address space, or
could form part of a private IPv4 network [RFC 1918].
This memo also specifies the content of the Source/Target Link-layer
Address option used in the Router Solicitation, Router Advertisement,
Neighbor Solicitation, and Neighbor Advertisement messages described in
[DISC], when those messages are transmitted on an IPv4 domain.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-carpenter-ipng-6over4-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-carpenter-ipng-6over4-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-carpenter-ipng-6over4-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321162905.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-carpenter-ipng-6over4-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-carpenter-ipng-6over4-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321162905.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25381; 24 Mar 97 10:08 EST
Received: from ietf.ietf.org by ietf.org id aa24264; 24 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-guerin-qospath-mgmt-rsvp-00.txt
Date: Mon, 24 Mar 1997 09:58:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703240958.aa24264 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : QoS Path Management with RSVP
Author(s) : R. Guerin, S. Kamat, S. Herzog
Filename : draft-guerin-qospath-mgmt-rsvp-00.txt
Pages : 14
Date : 03/21/1997
This document describes a proposal aimed at allowing management through the
RSVP [RZB+96] protocol of paths selected by a QoS routing algorithm such as
those of [GOW96, ZSSC96]. The goals of the proposal are to allow efficient
management of such QoS paths with the minimum possible impact to the RSVP
protocol and the existing routing infrastructure. Basic features of the
approach include leveraging of RSVP soft state mechanisms, and simple
extensions to enable soft pinning (sticking) of paths selected by the QoS
routing algorithm. In addition, the proposal addresses the issue of
preventing the formation of data path loops, and of avoiding potential race
conditions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-guerin-qospath-mgmt-rsvp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-guerin-qospath-mgmt-rsvp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-guerin-qospath-mgmt-rsvp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970324095404.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-guerin-qospath-mgmt-rsvp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-guerin-qospath-mgmt-rsvp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324095404.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25378; 24 Mar 97 10:08 EST
Received: from ietf.ietf.org by ietf.org id aa24195; 24 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldap-mult-mast-rep-00.txt
Date: Mon, 24 Mar 1997 09:58:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703240958.aa24195 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : LDAP Multi-master Replication Protocol
Author(s) : C. Weider, J. Strassner
Filename : draft-ietf-asid-ldap-mult-mast-rep-00.txt
Pages : 6
Date : 03/21/1997
This paper defines a multi-master, incremental replication protocol for the
LDAP protocol [LDAPv3]. It defines the use of two types of transport
protocols for replication data, and specifies the schema which must be
supported by a server which wishes to participate in replication activities
using this protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldap-mult-mast-rep-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321104358.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldap-mult-mast-rep-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321104358.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25398; 24 Mar 97 10:08 EST
Received: from ietf.ietf.org by ietf.org id aa24365; 24 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-calhoun-diameter-00.txt
Date: Mon, 24 Mar 1997 09:59:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703240959.aa24365 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DIAMETER
Author(s) : P. Calhoun, A. Rubens
Filename : draft-calhoun-diameter-00.txt
Pages : 16
Date : 03/21/1997
This original document was named Enhanced RADIUS and was changed at the
request of the WG since this protocol is different from the former.
This document describes a management protocol used between Network Access
Servers and DIAMETER Servers for authentication, authorization, accounting
of dial-up users. A considerable amount of effort was put into the design
of this protocol to ensure that an implementation could support both
DIAMETER and RADIUS at the same time.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-calhoun-diameter-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-calhoun-diameter-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-calhoun-diameter-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321154711.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-calhoun-diameter-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-calhoun-diameter-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321154711.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa27830; 24 Mar 97 10:25 EST
Received: from trix.Cisco.com by CNRI.Reston.VA.US id aa11080;
24 Mar 97 10:25 EST
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id HAA20895 for <extdom.snanaumib at aliashost.cisco.com>; Mon, 24 Mar 1997 07:18:45 -0800
Received: from ietf.org (ietf.org [132.151.1.19]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id HAA15837 for <snanaumib at external.cisco.com>; Mon, 24 Mar 1997 07:18:44 -0800 (PST)
Received: from ietf.ietf.org by ietf.org id aa24245; 24 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: snanaumib at external.cisco.com
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-snanau-appnmib-04.txt
Date: Mon, 24 Mar 1997 09:58:39 -0500
Sender: cclark at ietf.org
Message-ID: <9703240958.aa24245 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNA NAU Services MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for APPN
Author(s) : B. Clouston, B. Moore
Filename : draft-ietf-snanau-appnmib-04.txt
Pages : 131
Date : 03/21/1997
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for monitoring and controlling network
devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This
memo identifies managed objects for the APPN protocol.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-snanau-appnmib-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-snanau-appnmib-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snanau-appnmib-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321134936.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-snanau-appnmib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-appnmib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321134936.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa28383; 24 Mar 97 10:33 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa11207; 24 Mar 97 10:33 EST
Received: (from slist at localhost) by merit.edu (8.8.5/merit-2.0) id KAA27575; Mon, 24 Mar 1997 10:19:31 -0500 (EST)
Resent-Date: Mon, 24 Mar 1997 10:19:31 -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-ipcp-network-01.txt
Date: Mon, 24 Mar 1997 09:58:25 -0500
Sender: cclark at ietf.org
Message-ID: <9703240958.aa24211 at ietf.org>
Resent-Message-ID: <"So5YO2.0.yj6.KjfDp"@merit.edu>
Resent-From: ietf-ppp at merit.edu
X-Mailing-List: <ietf-ppp at MERIT.EDU> archive/latest/2873
X-Loop: ietf-ppp at MERIT.EDU
Precedence: list
Resent-Sender: ietf-ppp-request at merit.edu
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The PPP Internet Protocol Control Protocol (IPCP)
Author(s) : G. McGregor
Filename : draft-ietf-pppext-ipcp-network-01.txt
Pages : 13
Date : 03/21/1997
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point links.
PPP also defines an extensible Link Control Protocol, and proposes a family
of Network Control Protocols (NCPs) for establishing and configuring
different network-layer protocols.
This document defines the NCP for establishing and configuring the
Internet Protocol [2] over PPP, and a method to negotiate and
use Van Jacobson TCP/IP header compression [3] with PPP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-ipcp-network-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-network-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-ipcp-network-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321105840.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-ipcp-network-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-ipcp-network-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321105840.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa02500; 24 Mar 97 11:35 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa13107;
24 Mar 97 11:35 EST
Received: (from majordom at localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00391 for ipsec-outgoing; Mon, 24 Mar 1997 11:19:14 -0500 (EST)
To: IETF-Announce: ;
cc: ipsec at tis.com
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-96-00.txt
Date: Mon, 24 Mar 1997 09:58:17 -0500
Message-ID: <9703240958.aa24177 at ietf.org>
Sender: owner-ipsec at ex.tis.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : HMAC-MD5-96 IP Authentication with Replay Prevention
Author(s) : M. Oehler, R. Glenn
Filename : draft-ietf-ipsec-ah-hmac-md5-96-00.txt
Pages : 8
Date : 03/21/1997
This document describes a keyed-MD5 transform to be used in conjunction
with the IP Authentication Header [RFC-1826]. The particular transform is
based on [RFC-2104]. A replay prevention field is also specified.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ah-hmac-md5-96-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970321095813.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-96-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ah-hmac-md5-96-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970321095813.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa10111; 24 Mar 97 15:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17685;
24 Mar 97 15:03 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA06318 at pad-thai.cam.ov.com>; Mon, 24 Mar 1997 17:05:45 GMT
Message-Id: <9703241640.AA14024 at us1rmc.bb.dec.com>
Date: Mon, 24 Mar 97 11:40:04 EST
From: "John Wray, Digital DPE, 508/486-5210 24-Mar-1997 0944" <wray at tuxedo.enet.dec.com>
To: cadams at entrust.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, cadams at entrust.com
Subject: RE: IDUP-GSS-API
Precedence: bulk
Carlisle,
>Let me just note, however, that Denis has contributed a set of calls
>(modeled on the SE calls) which are specific to evidence generation and
>verification. These seem to move in the direction you were hoping for.
>I feel, though, that the simple calls need to live in conjunction with
>the more complicated calls (i.e., that removing the more complicated
>calls would be the wrong approach). Many calling applications currently
>only need to do relatively simple things and so will only use the simple
>calls. As time progresses, I think it will not be uncommon for an
>application to sign and encrypt data and ask for a proof of receipt from
>the recipient(s) all at the same time. Such an application will only
>want to input the data *once* and get back a blob to send out.
>
>Protocols like MSP already do this: you ask for confidentiality, ask
>for proof of origin, and request a receipt from some subset of
>recipients, for example, and what comes back is a single,
>properly-formatted ASN.1 structure. It is not at all clear to me how
>this can be accomplished with a set of separate calls without requiring
>the application to effectively input the data several times.
As far as receipts go, the major area of apparent complexity that I was
concerned about was to the re-use of the protect() functions to generate and
process receipts, not to request them. I agree that _requesting_ a receipt
shold be done at the same time the application specifies what protection
services to apply - you don't want to have to pass in the to-be-protected data
more than once.
>As complicated as the big calls are, with the multiple levels of
>parameter bundles, I believe they are useful to sophisticated
>applications that need to do a number of security services at once.
>Again, most current calling applications do not need to use the more
>complicated calls and it is not even required that mechanism
>implementers implement them (it is only recommended). They exist for
>the more sophisticated applications and mechanisms to use when they are
>needed.
Can you give an example of the sort of function that can't be done using the
"smaller" calls I suggested? I think you may have mis-interpreted my mail - my
biggest beef with the current low-level calls was the overloading of the
protect() calls to cover both single and multi-buffer cases, and also to cover
both encapsulation and non-encapsulation. Simply using four distinct routine
names, one for each case, would be much less confusing, and result in many
fewer provisos of the form "this parameter is only used in the case where
such-and-such".
>Finally, I'll just note that the parameter bundles and the more
>complicated calls are not impossible to implement. Our designers have
>implemented IDUP over a number of mechanisms without undue difficulty...
Regarding parameter bundles, my issue wasn't one of difficulty implementing the
IDUP draft; rather it was that they are unfriendly to the calling application.
As far as I can see, I either need a host of support routines to generate the
appropriate C object that corresponds to each of these bundles, or I need to
declare a series of such objects and initialize their fields myself. This is
the style used by XOM/XDS, and I can attest from personal experience that it's
a horrible style of API to program to. I'd far rather see either the data
presented to each routine directly as parameters, or introduce an additional
step prior to calling the protect() routines where application makes a series
of calls to annotate the protect-context (a lightweight
per-protection-operation object derived from the environment) in the
appropriate way.
The parameter bundle technique is particularly unpleasant where it's used to
return data from the IDUP routine, and even more so when used for
bi-directional data transfer. For example, the target_info bundle seems to be
used both to supply a list of names to which an IDU should be addressed, and
also to return a list of error-code/name pairs for those names that the IDUP
implementation had a problem with. This seems to mean that either the calling
application will have to reserve storage for (an unknown number of) erroneous
names, or the IDUP implementation will have to dynamically allocate this
storage, with the result that this parameter bundle will end up containing a
mix of storage allocated both by the application and the IDUP implementation.
I'm not against the use of parameter bundles per-se, but I think they should
only be used as a last-resort, when there's no simpler way to do things. I
believe that some of the places where they're used in the draft could be
done without them.
For example, ignoring status returns, the full parameter-list of the
single-buffer encapsulating case (probably the simplest scenario) could look
something like:
IDUP_Wrap(ENVIRONMENT_HANDLE env_handle,
void * Mech_specific_info,
gss_buffer_t input_idu,
ORIGINATOR_SERVICES originator_services,
TARGET_SERVICES target_services,
gss_buffer_t output_pidu);
In the above, mech_specific_info has become a (void *), as it's
mechanism-specific so there's no reason to define its structure.
ORIGINATOR_SERVICES and TARGET_SERVICES are parameter bundles, and are your
PROT_SERVICES bundle sub-divided into those features that apply in concept to
the data as-a-whole, and to each specific target. For example, DOA and
creation of POO are "ORIGINATOR_SERVICES", whereas CONF and requesting POD are
"TARGET_SERVICES" (in that they require that the IDUP implementation knows the
specific targets when protection is being applied), and each requested
target-service would have a list of target names associated with it. Splitting
things up this way allows a caller to simply provide a NULL for target_services
if he wants to protect an IDU in a target-independent manner (e.g. simply
attach a digital signature to some data so that anyone could read it), and also
doesn't require space for a set of target names inside bundles that don't care
about targets.
An alternative to the above that is more attractive if you introduce the
concept of a protection-context (which I think is needed anyway for reasons
described in my earlier mail) is to specify the desired protection services by
calls to annotate this context prior to invoking the protect call:
/* Establish a protection context: */
IDUP_Establish_Context(ENVIRONMENT_HANDLE env_handle,
PROTECT_CONTEXT * ctx_handle);
/* Perform some set of the following calls to define the protection... */
IDUP_Specify_Target(PROTECT_CONTEXT ctx_handle,
name target_name,
boolean request_receipt);
IDUP_Enable_CONF(PROTECT_CONTEXT ctx_handle,
CONF_QOS qos);
IDUP_Enable_DOA(PROTECT_CONTEXT ctx_handle,
DOA_QOS qos);
IDUP_Enable_POD(PROTECT_CONTEXT ctx_handle,
POD_QOS qos);
/* Finally protect the data... */
IDUP_Wrap(PROTECT_CONTEXT ctx_handle,
gss_buffer_t input_idu,
gss_buffer_t output_pidu);
/* If POD was requested, the context should be retained to verify any returned
receipts. After it's finished with, it can be released: */
IDUP_Release_Context(PROTECT_CONTEXT ctx_handle);
As well as being simple to program to, this style of API has the advantage that
it's easy to extend for additional services - you can just define additional
annotation functions.
John
Received: from cnri by ietf.org id aa12374; 24 Mar 97 15:56 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18795;
24 Mar 97 15:56 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA11059 at pad-thai.cam.ov.com>; Mon, 24 Mar 1997 19:06:21 GMT
Message-Id: <199703241906.OAA01603 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Marc Horowitz <marc at cygnus.com>
Cc: Martin.Rex at sap-ag.de, John Linn <linn at cam.ov.com>, cat-ietf at mit.edu,
linn at cam.ov.com
Subject: Re: Name type issues
In-Reply-To: Your message of "22 Mar 1997 20:20:36 EST."
<t53bu8bwgij.fsf at rover.cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 24 Mar 1997 14:06:15 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Marc wrote, replying to Martin:
> Martin Rex <martin.rex at sap-ag.de> writes:
>
> >> The high level spec currently says about the "User name form" that it
> >> is "OS specific". I would say that the current practice (and my
> >> understanding up to now) rather is: the User name form is mechanism specific
> >> and may be subject to OS restrictions for some implementations.
> >>
> >> My reasoning is that probably most GSS-API implementations do support
> >> the User name form, but happily accept their native "principal name form"
> >> totally independent of the actual integration with the operating system.
> >> I expect most GSS-API implementations to accept the User name form, even
> >> when the underlying OS doesn't know or distinguish users.
>
> How do you justify this expectation? On an OS without users, I would
> consider it reasonable not to implement this name type.
I agree. User name, Machine UID, and String UID forms originally appeared
in RFC-1964, enclosed within an "Optional Name Forms" subsection, which
should (I now believe) have propagated along with their inclusion into
RFC-2078; unless I'm recalling incorrectly, the intent of promoting them
to mechanism-independent was to make a common set of definitions accessible
to all mechanisms wishing to support the types, not to mandate that all
mechanisms must provide such support.
>
> >> What is "OS specific" supposed to mean for the User name form" anyway?
> >> Is it supposed to mean that the input is unconditionally subjected to the
> >> local OS syntax rules for usernames. On top of syntax, is it required
> >> that the user also exists on the local machine?
>
> It means that the conversion from the input to the underlying
> mechanism may be a function of some local conversion. For instance,
> under some systems (such as Multics), users' names include the name of
> the primary group for the account (such as Bigler.StudentAD, or
> Horowitz.Staff). It might be the convention when converting names to
> remove the group identifier, since kerberos has no notion of groups.
>
> It would be reasonable to reject names which are of an improper form,
> although "be liberal in what you accept" would require the
> implementation to have a good reason.
>
> It may be a requirement that the user exist. For instance, if one
> were to build a gssapi mechanism based on unix user id's (a bad idea,
> I know, but bear with me), it would be impossible to convert from a
> username to the associated uid unless the user already existed.
This question was debated on the list some time back, leading to the
statement (RFC-2078, p. 64) that "If a mechanism claims support for a
particular name type, its GSS_Import_name() operation shall be able to
accept all possible values conformant to the external name syntax as
defined for that name type."
--jl
Received: from ietf.org by ietf.org id aa13206; 24 Mar 97 16:14 EST
Received: from ietf.ietf.org by ietf.org id aa12998; 24 Mar 97 16:10 EST
To: IETF-Announce: ;
Subject: WG ACTION: Telnet TN3270 Enhancements (tn3270e)
Date: Mon, 24 Mar 1997 16:10:53 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9703241610.aa12998 at ietf.org>
A new working group has been formed in the Applications Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
Telnet TN3270 Enhancements (tn3270e)
------------------------------------
Chair(s):
Ed Bailey <bart at vnet.ibm.com>
D. Villanueva <dericv at wrq.com>
Applications Area Director(s):
Keith Moore <moore+iesg at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Area Advisor
R. Moskowitz <rgm3 at chrysler.com>
Mailing lists:
General Discussion:tn3270e at list.nih.gov
To Subscribe: listserv at list.nih.gov
In Body: sub tn3270e <first_name> <last_name>
Archive: listserv at list.nih.gov
Description of Working Group:
Present specifications for access to 3270 and 5250 based applications over
TCP/IP require improvement to become more commercially viable. Security,
Service Location, Response Time, and Session Balancing are improvement
examples.
The WG will drive to update and extend the standards specifications proposed
in rfc1647 and rfc1205 so that they fully support 3270 and 5250 style access
to host (S/390 and AS/400) applications respectively in today's environments.
Consideration will be given to work already in progress on protocols for
accessing 3270 and 5250 based applications over TCP/IP.
Three protocol documents will be produce
Deliverables
1. A revised version of rfc1647 (tn3270e) including clarifications of the
protocol, and security considerations. The revised rfc1647 will be submitted
to the IESG for advancement of the tn3270e protocol to draft standard status.
Currently it is a proposed standard.
2. A new standards track document defining options for the tn3270e protocol.
Such options are: IPDS printing, response time monitoring, error reporting,
session balancing, service location, and security.
3. A new standards track document defining enhancements to the tn5250
protocol.
This new protocol will be called tn5250e. This is not Display Station Passthrubut printing, LU assignment, service location, and security.
Goals and Milestones:
Apr 97 Goal 1 revised tn3270e (rfc1647) Conduct interoperability
testing.
Apr 97 Goal 2 tn3270e new options Propose a list of initial
enhancements on listsrv for review.
Apr 97 Discuss scope of initial tn3270e enhancements at IETF session.
Apr 97 Propose a list of initial TN5250e enhancements on listsrv for
review.
Apr 97 Discuss scope of initial tn5250ec enhancements at IETF session.
May 97 Goal 1 revised tn3270e (rfc1647) Publish Internet-Draft and
issue Working Group Last Call.
Jun 97 Goal 1 revised tn3270e (rfc1647) Incorporate any revisions and
publish Internet-Draft.
Jun 97 Goal 1 revised tn3270e (rfc1647) Submit to IESG for
consideration for Proposed Standard.
Aug 97 Goal 2 tn3270e new options Resolve issues with initial
enhancements using the listsrv.
Aug 97 Goal 3 tn5250e Resolve issues with initial enhancements using
the listsrv.
Sep 97 Goal 2 tn3270e new options Issue initial draft of new proposed
rfc to listsrv for review.
Sep 97 Goal 3 tn5250e Issue initial draft of new proposed rfc to
listsrv for review.
Nov 97 Goal 2 tn3270e new options Incorporate comments and publish
proposed rfc for implementation.
Nov 97 Goal 3 tn5250e Incorporate comments and publish proposed rfc
for implementation.
Apr 98 Goal 2 tn3270e new options Conduct initial interoperability
testing.
Apr 98 Goal 3 tn5250e Conduct initial interoperability testing.
Jun 98 Goal 2 tn3270e new options Gather operational experience from
implementers.
Jun 98 Goal 3 tn5250e Gather operational experience from
implementers.
Aug 98 Goal 2 tn3270e new options Publish Internet-Draft and issue
Working Group Last Call.
Aug 98 Goal 3 tn5250e Publish Internet-Draft and issue Working Group
Last Call.
Oct 98 Goal 2 tn3270e new options Incorporate any revisions and
publish Internet-Draft.
Oct 98 Goal 2 tn3270e new options Submit to IESG for consideration
for Proposed Standard.
Oct 98 Goal 3 tn5250e Incorporate any revisions and publish
Internet-Draft.
Oct 98 Goal 3 tn5250e Submit to IESG for consideration for Proposed
Standard.
Received: from ietf.org by ietf.org id aa13208; 24 Mar 97 16:14 EST
Received: from ietf.ietf.org by ietf.org id aa13008; 24 Mar 97 16:10 EST
To: IETF-Announce: ;
Subject: WG ACTION: SNMP Version 3 (snmpv3)
Date: Mon, 24 Mar 1997 16:10:57 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9703241610.aa13008 at ietf.org>
A new working group has been formed in the Operational Requirements Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
SNMP Version 3 (snmpv3)
-----------------------
Chair(s):
Russ Mundy <mundy at tis.com>
Operational Requirements Area Director(s):
Scott Bradner <sob at harvard.edu>
Michael O'Dell <mo at uu.net>
Deirdre Kostick <kostick at qsun.att.com>
Area Advisor
Mike O'Dell <mo at uu.net>
Mailing lists:
General Discussion:snmpv3 at tis.com
To Subscribe: snmpv3-request at tis.com
Archive: ftp://ftp.tis.com/pub/ietf/snmpv3
Description of Working Group:
The SNMPv3 Working Group is chartered to prepare recommendations for
the next generation of SNMP. The goal of the Working Group is to
produce the necessary set of documents that will provide a single
standard for the next generation of core SNMP functions.
During the past several years, there have been a number of activities
aimed at incorporating security and other improvements to SNMP.
Unfortunately, strongly held differences on how to incorporate these
improvements into SNMP prevented the SNMPV2 Working Group from coming
to closure on a single approach. As a result, two different approaches
(commonly called V2u and V2*) have emerged.
The Security and Administrative Framework Evolution for SNMP Advisory
Team (the Advisory Team) was formed to provide a single recommended
approach for SNMP evolution. The technical starting point for this
Working Group will be the recommended approach provided by the Advisory
Team.
This approach provides for the convergence of concepts and technical
elements of V2u and V2*. The SNMPv3 Working Group is not starting new
work and will use as many concepts, technical elements and
documentation as practical from the V2u and V2* activities. Previous
delays in providing a single standard for the next generation of SNMP
core functions dictate that the Working Group move forward as quickly
as possible to document and publish Internet Drafts and RFC's. To this
end, the Working Group will make use of as much existing documentation
as practical. Additionally, functional changes beyond those needed to
provide a single approach will be strongly discouraged.
Timely completion of a single approach for SNMPv3 is crucial for the
continued success of SNMP. Recognizing the need for prompt completion,
the following objectives are provided to the Working Group:
- accommodate the wide range of operational environments with
differing management demands;
- facilitate the need to transition from previous, multiple protocols
to SNMPv3;
- facilitate the ease of setup and maintenance activities.
Note: SNMPv3 planned specifications:
SNMPv3 Modules and Interface Definitions
SNMPv3 Message Processing and Control Module Specification
SNMPv3 Security Model Module Specification
SNMPv3 Local Processing Mosule Specification
SNMPv3 Proxy Specification
Goals and Milestones:
Apr 97 Post first SNMPv3 Internet-Draft, Modules and Interface
Definitions.
Apr 97 Working Group meeting at Memphis IETF to discuss SNMPv3
recommended approach, discuss Working Group Charter and the
plan for completion.
Jun 97 Post revised SNMPv3 Modules and Interface Definitions
Internet-Drafts.
Jul 97 Post initial SNMPv3 Message Processing and Control Module
Internet-Draft.
Jul 97 Post initial SNMPv3 Security Model Module Internet-Draft.
Aug 97 Finalize SNMPV3 Modules and Interface Definitions
Internet-Draft and review other I-Ds at Munich IETF.
Sep 97 Submit SNMPv3 Modules and Interface Definitions to IESG for
consideration as a Proposed Standard.
Sep 97 Post revised SNMPv3 Message Processing and Control Module
Internet-Draft.
Sep 97 Post revised SNMPv3 Security Model Module Internet-Draft.
Sep 97 Post revised SNMPv3 Local Processing Module Internet-Draft.
Sep 97 Post initial SNMPv3 Proxy Specification Internet-Draft.
Apr 98 All SNMPv3 specifications submitted to IESG for consideration
as Proposed Standards.
Received: from ietf.org by ietf.org id aa13209; 24 Mar 97 16:14 EST
Received: from ietf.ietf.org by ietf.org id aa12986; 24 Mar 97 16:10 EST
To: IETF-Announce: ;
Subject: WG ACTION: WWW Distributed Authoring and Versioning (webdav)
Date: Mon, 24 Mar 1997 16:10:45 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9703241610.aa12986 at ietf.org>
A new working group has been formed in the Applications Area
of the IETF. For additional information, contact the Area Directors
or the WG Chair.
WWW Distributed Authoring and Versioning (webdav)
-------------------------------------------------
Chair(s):
Jim Whitehead <ejw at ics.uci.edu>
Applications Area Director(s):
Keith Moore <moore+iesg at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Area Advisor
Keith Moore <moore+iesg at cs.utk.edu>
Mailing lists:
General Discussion:w3c-dist-auth at w3.org
To Subscribe: w3c-dist-auth-request at w3.org
In Body: Subject of subscribe
Archive: http://www/w3/org/pub/WWW/Archives/Public/w3c-dist-auth/
Description of Working Group:
This working group will define the HTTP extensions necessary to enable
distributed web authoring tools to be broadly interoperable, while
supporting user needs.
The HTTP protocol contains functionality which enables the editing of
web content at a remote location, without direct access to the storage
media via an operating system. This capability is exploited by several
existing HTML distributed authoring tools, and by a growing number of
mainstream applications (e.g. word processors) which allow users to
write (publish) their work to an HTTP server. To date, experience from
the HTML authoring tools has shown they are unable to meet their user's
needs using the facilities of the HTTP protocol. The consequence of this
is either postponed introduction of distributed authoring capability, or
the addition of nonstandard extensions to the HTTP protocol. These
extensions, developed in isolation, are not interoperable.
An ad-hoc group has analyzed the functional needs of several
organizations, and has developed requirements for distributed authoring
and versioning. These requirements encompass the following capabilities,
which shall be considered by this working group:
IN-SCOPE:
*Locking: lock, lock status, unlock
*Name space manipulation: copy, move/rename, resource redirection (e.g.
3xx response codes)
*Containers: creation, access, modification, container-specific
semantics
*Attributes: creation, access, modification, query, naming
*Notification of intent to edit: reserve, reservation status, release
reservation
*Use of existing authentication schemes
*Access control
*Unprocessed source retrieval
*Informing proxies of an action's impact
*Versioning:
*Checkin/Checkout
*History graph
*Differencing
*Automatic Merging
*Naming and accessing resource versions
Further information on these requirements can be found in the document,
"Requirements for Distributed Authoring and Versioning on the World Wide
Web". <http://www.ics.uci.edu/~ejw/authoring/webdav-req-00.html>
While the scope of activity of this working group may seem rather
broad, in fact much of the functionality under consideration is well
understood, and has been previously considered. This working group will
leverage off of previous work when it is applicable. Discussion of the
security issues concerning distributed authoring and versioning are
essential to the creation of a protocol which implements this
functionality.
Though the feature set described above bears a resemblance to the
capabilities provided by a network file system, the intent of this
working group is not to create a replacement distributed file system
(e.g. NFS, CIFS). The WEBDAV emphasis on collaborative authoring of
resources which are not necessarily stored in a file system, and which
have associated metadata in the form of links and attributes,
differentiate WEBDAV from a distributed file system.
Many decisions have been made to reduce the scope of effort of this
working group. It is the intent of this working group to avoid the
inclusion of the following functionality, unless it proves impossible to
create a useful set of distributed authoring capabilities without it:
NOT IN SCOPE:
*Definition of core attribute sets, beyond those attributes necessary
for the implementation of distributed authoring and versioning
functionality
*Creation of new authentication schemes
*HTTP server to server communication protocols
*Distributed authoring via non-HTTP protocols (except email)
*Implementation of functionality by non-origin proxies
Eventually, it is desirable to provide access to WEBDAV capability by
disconnected clients, or by clients whose only connectivity is via
email. However, given the scope of developing requirements and
specifications for disconnected operation, the initial target user
group of fully connected clients, and the desire to work swiftly, the
working group will address this issue by ensuring the protocol
specification does not preclude a future body from developing an
interoperability specification for disconnected operation via email.
Deliverables
The final output of this working group is expected to be three
documents:
1. A scenarios document, which gives a series of short descriptions of
how distributed authoring and versioning functionality can be used,
typically from an end-user perspective. Ora Lassila, Nokia, currently
visiting with the World Wide Web Consortium, is editor of this
document.
2. A requirements document, which describes the high-level functional
requirements for distributed authoring and versioning, including
rationale. Judith Slein, Xerox, is editor of this document.
3. A protocol specification, which describes new HTTP methods,
headers, request bodies, and response bodies, to implement the
distributed authoring and versioning requirements. Del Jensen, Novell,
is editor of this document.
The most recent versions of these documents are accessible via links
from the WEBDAV Web page.
Goals and Milestones:
Mar 97 (Specification) Produce revised distributed authoring and
versioning protocol specification. Submit as Internet Draft.
Apr 97 (Meeting, Specification, Requirements) Meet at Memphis IETF and
hold working group meeting to review the protocol specification
and requirements document.
Apr 97 (Scenarios) Revise scenarios document. Submit as Internet
Draft.
Aug 97 (Scenarios) Create final scenarios document. Submit as
Informational RFC.
Aug 97 (Requirements) Create final version of distributed authoring
and versioning requirements document. Submit as Informational
RFC.
Aug 97 (Specification) Produce revised distributed authoring and
versioning protocol specification. Submit as Internet Draft.
Dec 97 (Specification) Complete revisions to distributed authoring and
versioning specification. Submit as a Proposed Standard RFC.
Received: from cnri by ietf.org id aa15981; 24 Mar 97 17:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20283;
24 Mar 97 17:05 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA13625 at pad-thai.cam.ov.com>; Mon, 24 Mar 1997 20:10:07 GMT
Message-Id: <199703242009.AA00656 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Name type issues
To: John Linn <linn at cam.ov.com>
Date: Mon, 24 Mar 1997 15:09:10 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703241906.OAA01603 at gza-client1.cam.ov.com> from "John Linn" at Mar 24, 97 02:06:15 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
John Linn wrote:
> Marc wrote, replying to Martin:
> > Martin Rex <martin.rex at sap-ag.de> writes:
> >
> > >> The high level spec currently says about the "User name form" that it
> > >> is "OS specific". I would say that the current practice (and my
> > >> understanding up to now) rather is: the User name form is mechanism specific
> > >> and may be subject to OS restrictions for some implementations.
> > >>
> > >> My reasoning is that probably most GSS-API implementations do support
> > >> the User name form, but happily accept their native "principal name form"
> > >> totally independent of the actual integration with the operating system.
> > >> I expect most GSS-API implementations to accept the User name form, even
> > >> when the underlying OS doesn't know or distinguish users.
> >
> > How do you justify this expectation? On an OS without users, I would
> > consider it reasonable not to implement this name type.
>
> I agree. User name, Machine UID, and String UID forms originally appeared
> in RFC-1964, enclosed within an "Optional Name Forms" subsection, which
> should (I now believe) have propagated along with their inclusion into
> RFC-2078; unless I'm recalling incorrectly, the intent of promoting them
> to mechanism-independent was to make a common set of definitions accessible
> to all mechanisms wishing to support the types, not to mandate that all
> mechanisms must provide such support.
Although RFC2078 says:
This name type is used to indicate a named user on a local system.
Its interpretation is OS-specific. This name form is constructed as:
it doesn't classify any nametypes as optional or mandatory.
You need at least one generic nametype for your target to "portably"
initiate a security context, either an explicit one or GSS_C_NO_OID.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
