[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Target names can not necessarily be derived from from the host-based
service name form (service at hostname), UIDs (or POSIX uid_t) are not
available on some platforms. If you want to see the user name form being
restricted to the local OS's notion of users, we will need a GENERIC,
EXPLICIT (and MANDATORY) nametype to tag the name of an individual
distinguishable entity (Kerberos term "principal", X.500 "subject" (?)),
otherwise "truely portable" applications are impossible.
-Martin
Received: from ietf.org by ietf.org id aa19369; 24 Mar 97 19:57 EST
Received: from www.atr.net by ietf.org id aa18770; 24 Mar 97 19:40 EST
Received: from www.atr.net (www.atr.net [206.232.44.253]) by warp.atr.net (NTMail 3.02.10) with ESMTP id qa000458 for <ietf at ietf.org>; Mon, 24 Mar 1997 19:38:25 +0000
Message-ID: <33371E81.694E at atr.net>
Date: Mon, 24 Mar 1997 19:38:25 -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: ietf at ietf.org
Subject: Http vrs. 1.1
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.
The HTTP version 1.1 protocol
seems to have solved lots of web
related network problems (read sessioning problems)
+ should have a major effect on Internet traffic.
http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html
There is a Java based server and client up there.
Any machine that can run a java program should be
able to test the code.
--
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 aa03608; 25 Mar 97 3:39 EST
Received: from cnri by ietf.org id aa03458; 25 Mar 97 3:33 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa04675;
25 Mar 97 3:33 EST
Received: from mtigwc02.worldnet.att.net (mailhost.worldnet.att.net) by venera.isi.edu (5.65c/5.61+local-26)
id <AA24923>; Tue, 25 Mar 1997 00:30:43 -0800
Received: from LOCALNAME ([207.147.201.140]) by mtigwc02.worldnet.att.net
(post.office MTA v2.0 0613 ) with SMTP id AAA458;
Tue, 25 Mar 1997 08:30:40 +0000
Message-Id: <33378DEE.2034 at worldnet.att.net>
Date: Tue, 25 Mar 1997 00:33:50 -0800
Sender:ietf-request at ietf.org
From: WILLIAM LONG <SWAPKEY at worldnet.att.net>
X-Mailer: Mozilla 3.0C-WorldNet (Win16; U)
Mime-Version: 1.0
To: ietf at isi.edu
Cc: Jay at isi.edu, Long at isi.edu
Subject: Corky? Guess who?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Jay Long, Corky Guess who?
Received: from cnri by ietf.org id aa05057; 25 Mar 97 4:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05706;
25 Mar 97 4:44 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <HAA06287 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 07:38:25 GMT
From: Jacques Lebastard <J.Lebastard at frcl.bull.fr>
Message-Id: <9703250737.AA16967 at ronde.frcl.bull.fr>
Subject: Re: Name type issues
To: Martin.Rex at sap-ag.de
Date: Tue, 25 Mar 1997 08:37:49 +0100 ("MET)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703242009.AA00656 at sap-ag.de> from "Martin Rex" at Mar 24, 97 03:09:10 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Precedence: bulk
> 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.
> >From the discussion at the IETF Meeting at San Jose it sounds like
> GSS_C_NO_OID is interpreted differently by existing implementations;
> if I remember correctly, Ted mentioned that MIT's Kerberos 5 assumes
> "hostbased service names", and Bill Sommerfeld mentioned that DCE assumes
> principal names. I don't know about Sesame and SPKM -- do they support
> GSS_C_NO_OID for import_name at all?
Like DCE, SESAME assume the name to be a Kerberos principal name.
--
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 ietf.org by ietf.org id aa10061; 25 Mar 97 10:14 EST
Received: from ietf.ietf.org by ietf.org id aa09705; 25 Mar 97 10:01 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: XDR: External Data Representation Standard to
Draft Standard
Date: Tue, 25 Mar 1997 10:01:35 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703251001.aa09705 at ietf.org>
The IESG has approved the Internet-Draft "XDR: External Data
Representation Standard" RFC1832 as a Draft Standard. This document is
the product of the ONC Remote Procedure Call Working Group. The IESG
contact persons are Allison Mankin and Allyn Romanow.
Technical Summary
XDR is a byte-oriented data-description language. Its primary
commercial use has been as the format of data for the ONCRPC protocol
(RFC 1831) and protocols built on it, such as Network File System.
XDR is known to permit network transmission of data among a wide
variety of platforms.
Working Group Summary
The working group was unanimous in viewing RFC 1832 as ready to
proceed to DS without any revisions.
The Last Call period surfaced no concerns with the quality of
the protocol.
Protocol Quality
This document was reviewed for the IESG by Allison Mankin.
Implementations known to be independent of Sun Microsystem's freely
available reference implementation were identified by John Wroclawsky
and Keith Moore from the Transport Area Directorate. There are two
that are known to be completely independent, and another is believed
likely to be independent, but not verified so.
The detailed implementation reports are located at:
http://www.ietf.org/IESG/implementation.html
Received: from ietf.org by ietf.org id aa11072; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10196; 25 Mar 97 10:14 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-trans-ethernet-00.txt
Date: Tue, 25 Mar 1997 10:14:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10196 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 IPNG Working Group of the
IETF.
Title : Transmission of IPv6 Packets over Ethernet Networks
Author(s) : M. Crawford
Filename : draft-ietf-ipngwg-trans-ethernet-00.txt
Pages : 5
Date : 03/24/1997
This memo specifies the frame format for transmission of IPv6 packets and
the method of forming IPv6 link-local addresses and statelessly
autoconfigured addresses on Ethernet networks. It also specifies the
content of the Source/Target Link-layer Address option used in Router
Solicitation, Router Advertisement, Neighbor Solicitation and Neighbor
Advertisement messages when those messages are transmitted on an Ethernet.
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-trans-ethernet-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-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-ipngwg-trans-ethernet-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: <19970324102801.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-trans-ethernet-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324102801.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11089; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10128; 25 Mar 97 10:14 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-mib-02.txt
Date: Tue, 25 Mar 1997 10:13:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10128 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 : Application Management MIB
Author(s) : C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia
Filename : draft-ietf-applmib-mib-02.txt
Pages : 47
Date : 03/24/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 used for the management of
applications. This MIB complements the System Application MIB, providing
for the management of applications' common aspects which could not
typically be observed without the cooperation of the software being
managed.
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-mib-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-mib-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-applmib-mib-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: <19970324100458.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-applmib-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-applmib-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324100458.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11094; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10319; 25 Mar 97 10:14 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-pep-02.txt
Date: Tue, 25 Mar 1997 10:14:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10319 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 : PEP: an Extension Mechanism for HTTP
Author(s) : D. Connolly
Filename : draft-ietf-http-pep-02.txt
Pages : 17
Date : 03/24/1997
HTTP is an extensible protocol. PEP is an extension mechanism designed to
address the tension between private agreement and public specification and
to accommodate extension of HTTP clients and servers by software
components.
The PEP mechanism is to associate each extension with a URI, and
use a few new header fields to carry the extension identifier and
related information from HTTP clients, thru proxies and intermediaries,
to servers, and back again.
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-pep-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-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-http-pep-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: <19970324110804.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-pep-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-pep-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324110804.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11098; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10149; 25 Mar 97 10:14 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-trans-fddi-net-00.txt
Date: Tue, 25 Mar 1997 10:14:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10149 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 IPNG Working Group of the
IETF.
Title : Transmission of IPv6 Packets over FDDI Networks
Author(s) : M. Crawford
Filename : draft-ietf-ipngwg-trans-fddi-net-00.txt
Pages : 8
Date : 03/24/1997
This memo specifies the MTU and frame format for transmission of IPv6
packets on FDDI networks, including a method for MTU determination in the
presence of 802.1d bridges to other media. It also specifies the method of
forming IPv6 link-local addresses on FDDI networks and the content of the
Source/Target Link-layer Address option used the Router Solicitation,
Router Advertisement, Neighbor Solicitation and Neighbor Advertisement
messages when those messages are transmitted on an FDDI 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-ietf-ipngwg-trans-fddi-net-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-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-ietf-ipngwg-trans-fddi-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: <19970324101933.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-trans-fddi-net-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324101933.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11109; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10346; 25 Mar 97 10:14 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-smirnov-ion-earth-02.txt
Date: Tue, 25 Mar 1997 10:14:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10346 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : EARTH - EAsy IP multicast Routing THrough ATM clouds
Author(s) : M. Smirnov
Filename : draft-smirnov-ion-earth-02.txt
Pages : 23
Date : 03/24/1997
The EARTH could be positioned between MARS [1] and VENUS [2], however EARTH
deals not only with address resolution but with routing issues as well.
This document describes a solution simplifying distribution of IP multicast
flows over ATM clouds with the use of point-to-multipoint connections. The
EARTH solution includes:
- the notion of multicast IP subnet over ATM;
- IP multicast addresses (Class D) resolution to ATM addresses;
- support for IP multicast shortcuts over multiple LISs and for
the DVMRP capable egress routers;
- support for a multicast group management and receiver-initiated
quality of service (QoS) specification;
- optional replication of EARTH servers with server synchronisation
based on SCSP [3].
The current version of EARTH proposal has an extension to solve problems
of ATM backbone for the Internet with DVMRP support over MLIS; while
retaining support for ATM subnets (LANs). Another extension addresses
redundant EARTH servers specifying, how SCSP protocol could be re-designed
to run over MLIS.
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-smirnov-ion-earth-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-smirnov-ion-earth-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-smirnov-ion-earth-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: <19970324112420.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-smirnov-ion-earth-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-smirnov-ion-earth-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324112420.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11132; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10235; 25 Mar 97 10:14 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-dyn-subnet-conf-00.txt
Date: Tue, 25 Mar 1997 10:14:14 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10235 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 : DSCP: Dynamic Subnet Configuration Protocol
Author(s) : K. Taniguchi, T. Nishida
Filename : draft-ietf-dhc-dyn-subnet-conf-00.txt
Pages : 6
Date : 03/24/1997
The Dynamic Subnet Configuration Protocol (DSCP) provides a framework for
passing configuration information to administrative servers on a TCP/IP
network which allows dynamic subnet configuration. Examples of
administrative servers, which are DSCP clients, are a network
administrator's host, DHCP server, etc. DSCP is built on a client server
model. The DSCP server allocates subnet configuration parameters to
dynamically configured subnetworks. DSCP is an extension of DHCP [1,2].
This document describes DSCP model and defines a new DHCP options to allow
the subnet configuration dynamically.
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-dyn-subnet-conf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-dyn-subnet-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-ietf-dhc-dyn-subnet-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: <19970324103303.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-dyn-subnet-conf-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-dyn-subnet-conf-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324103303.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11265; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10494; 25 Mar 97 10:14 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-kikuchi-web-cert-repository-00.txt
Date: Tue, 25 Mar 1997 10:14:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10494 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Public Key Infrastructure: Web-based
Certificate and CRL Repository
Author(s) : H. Kikuchi, M. Sakurai, H. Hattori, Y. Sameshima
Filename : draft-kikuchi-web-cert-repository-00.txt
Pages : 17
Date : 03/24/1997
This document provides a specification how to publish and retrieve X.509
certificates and certificate revocation lists (CRLs). In the proposed
method, the World Wide Web (WWW) is used for securely distributing
certificates across a firewall in both human and machine readable syntax. A
various certificate concerning information that includes certificates,
CRLs, and certification authority (CA) policy are retrieved from an
integrated single authority access point specified in X.509 version 3
extensions. The information access point accepts certification and
revocation requests in the uniform access method based on the standard 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-kikuchi-web-cert-repository-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kikuchi-web-cert-repository-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-kikuchi-web-cert-repository-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: <19970324114626.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kikuchi-web-cert-repository-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kikuchi-web-cert-repository-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324114626.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11284; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10490; 25 Mar 97 10:14 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-acap+ at andrew.cmu.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-acap-spec-02.txt
Date: Tue, 25 Mar 1997 10:14:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10490 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 Configuration
Access Protocol Working Group of the IETF.
Title : ACAP -- Application Configuration Access Protocol
Author(s) : C. Newman, J. Myers
Filename : draft-ietf-acap-spec-02.txt
Pages : 53
Date : 03/24/1997
The Application Configuration Access Protocol (ACAP) is designed to
support remote storage and access of program option, configuration
and preference information.
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-acap-spec-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-acap-spec-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-acap-spec-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: <19970324114142.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-acap-spec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-acap-spec-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324114142.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11318; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10534; 25 Mar 97 10:14 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-gellens-submit-03.txt
Date: Tue, 25 Mar 1997 10:14:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10534 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Message Submission and Relay
Author(s) : H. Alvestrand, R. Gellens
Filename : draft-gellens-submit-03.txt
Pages : 10
Date : 03/24/1997
SMTP was defined as a message *relay* protocol, that is, a means for
message transfer agents (MTAs) to route finished (complete) messages.
SMTP forbids MTAs from altering the message text, except to
add 'Received' header fields.
However, SMTP is now also widely used as a message *submission* protocol,
that is, a means for message user agents (MUAs) to introduce new messages
into the MTA routing network. Regardless of whether
this is good or bad, it is far too late to change.
Messages being submitted are in some cases finished (complete) messages,
and in other cases are unfinished (incomplete) in some aspect or other.
Unfinished messages need to be completed to ensure they conform to
[RFC-822], [RFC-1123], and later requirements. For example, the message
may lack proper Date or Message-ID headers, and domains might not be fully
qualified. In some cases, the MUA may be unable to generate finished
(complete) messages (for example, it might not know its time zone). Even
when submitted messages are finished (complete), local site policy may
dictate that the message text be modified in some ways. Such completions or
modifications violate the letter and spirit of SMTP when used
as a relay 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-gellens-submit-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gellens-submit-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-gellens-submit-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: <19970324120104.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gellens-submit-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gellens-submit-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324120104.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11356; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10566; 25 Mar 97 10:14 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-hoffman-smtp-ssl-00.txt
Date: Tue, 25 Mar 1997 10:14:56 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10566 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extension for Secure SMTP over TLS
Author(s) : P. Hoffman
Filename : draft-hoffman-smtp-ssl-00.txt
Pages : 3
Date : 03/24/1997
This document describes an extension to the SMTP service that allows an
SMTP server and client to use transport-layer security to provide private,
authenticated communication over the Internet. This gives SMTP agents the
ability to protect some or all of their communications from eavesdroppers
and attackers.
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-hoffman-smtp-ssl-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-smtp-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-hoffman-smtp-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: <19970324120535.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-smtp-ssl-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-smtp-ssl-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324120535.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11361; 25 Mar 97 10:16 EST
Received: from ietf.ietf.org by ietf.org id aa10599; 25 Mar 97 10:15 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-rvsa-v10-01.txt
Date: Tue, 25 Mar 1997 10:15:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10599 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 : HTTP Remote Variant Selection Algorithm -- RVSA/1.0
Author(s) : K. Holtman, A. Mutz
Filename : draft-ietf-http-rvsa-v10-01.txt
Pages : 10
Date : 03/24/1997
HTTP allows web site authors to put multiple versions of the same
information under a single URL. Transparent content negotiation is a
mechanism for automatically selecting the best version when the URL is
accessed. A remote variant selection algorithm can be used to speed up the
transparent negotiation process. This document defines the remote variant
selection algorithm with the version number 1.0.
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-rvsa-v10-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-rvsa-v10-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-rvsa-v10-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: <19970324132138.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-rvsa-v10-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-rvsa-v10-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324132138.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11614; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa10671; 25 Mar 97 10:15 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-barber-nntp-imp-06.txt
Date: Tue, 25 Mar 1997 10:15:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10671 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Common NNTP Extensions
Author(s) : S. Barber
Filename : draft-barber-nntp-imp-06.txt
Pages : 25
Date : 03/24/1997
In this document, a number of popular extensions to the NNTP protocol
defined in RFC977 are documented and discussed. While this document is not
intended to serve as a standard of any kind, it will hopefully serve as a
reference document for future implementers of the NNTP protocol. In the
role, this document would hopefully create the possibility for some level
of interoperability among implementations that make use of 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-barber-nntp-imp-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-barber-nntp-imp-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-barber-nntp-imp-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: <19970324133519.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-barber-nntp-imp-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-barber-nntp-imp-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324133519.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11661; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa10742; 25 Mar 97 10:15 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-musella-html-metatag-03.txt
Date: Tue, 25 Mar 1997 10:15:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10742 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The META Tag of HTML
Author(s) : D. Musella
Filename : draft-musella-html-metatag-03.txt
Pages : 4
Date : 03/24/1997
This document defines a strict synopsis to catalogue an HTML document using
the META tag of HTML. The given definition wants to define a base subset
of cataloguing keys to provide a preliminary classification method.
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-musella-html-metatag-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-musella-html-metatag-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-musella-html-metatag-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: <19970325100149.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-musella-html-metatag-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-musella-html-metatag-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325100149.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11813; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa10916; 25 Mar 97 10:15 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-snego-03.txt
Date: Tue, 25 Mar 1997 10:15:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10916 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 Authentication
Technology Working Group of the IETF.
Title : Simple GSS-API Negotiation Mechanism
Author(s) : E. Baize, D. Pinkas
Filename : draft-ietf-cat-snego-03.txt
Pages : 12
Date : 03/24/1997
This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which is
described in [1].
The GSS-API provides a generic interface which can be layered
atop different security mechanisms such that if communicating
peers acquire GSS-API credentials for the same security mechanism,
then a security context may be established between them (subject
to policy). However, GSS-API doesn't prescribe the method by which GSS-API
peers can establish whether they have a common security mechanism.
The Simple GSS-API Negotiation Mechanism defined here is a pseudo-security
mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables
GSS-API peers to determine in-band whether their credential share common
GSS-API security mechanism(s), and if so, to invoke normal security context
establishment for a selected common security mechanism. This is most useful
for applications that are based on GSS-API implementations which support
multiple security mechanisms.
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-snego-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-snego-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-cat-snego-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: <19970324140203.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-snego-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-snego-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324140203.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11850; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa10990; 25 Mar 97 10:15 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-nhrp-appl-01.txt
Date: Tue, 25 Mar 1997 10:15:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10990 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 : NHRP Protocol Applicability Statement
Author(s) : D. Cansever
Filename : draft-ietf-ion-nhrp-appl-01.txt
Pages : 8
Date : 03/24/1997
As required by the Routing Protocol Criteria [RFC 1264], this draft report
discusses the applicability of the Next Hop Resolution Protocol (NHRP) in
routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks,
such as ATM, SMDS and X.25. The final form of this draft report is a
prerequisite to advancing NHRP on the standards track.
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-nhrp-appl-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-nhrp-appl-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-nhrp-appl-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: <19970324140546.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-nhrp-appl-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-nhrp-appl-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324140546.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11888; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa11069; 25 Mar 97 10:15 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: poised 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-poisson-wg-guide-00.txt
Date: Tue, 25 Mar 1997 10:15:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa11069 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 Process for Organization of
Internet StandardS ONg Working Group of the IETF.
Title : IETF Working Group Guidelines and Procedures
Author(s) : S. Bradner
Filename : draft-ietf-poisson-wg-guide-00.txt
Pages : 19
Date : 03/24/1997
The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet Standards.
IETF activities are organized into working groups (WGs). This document
describes the guidelines and procedures for formation and operation of IETF
working groups. It also describes the formal relationship between IETF
participants WG and the Internet Engineering Steering Group (IESG) and the
basic duties of IETF participants, including WG Chairs, WG participants,
and IETF Area Directors.
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-poisson-wg-guide-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-poisson-wg-guide-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-poisson-wg-guide-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: <19970324141042.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-poisson-wg-guide-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-poisson-wg-guide-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324141042.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12020; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa11307; 25 Mar 97 10:16 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-xgssapi-acc-cntrl-02.txt
Date: Tue, 25 Mar 1997 10:16:17 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11307 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 Authentication
Technology Working Group of the IETF.
Title : Extended Generic Security Service APIs: XGSS-APIs Access
control and delegation extensions
Author(s) : T. Parker, D. Pinkas
Filename : draft-ietf-cat-xgssapi-acc-cntrl-02.txt
Pages : 24
Date : 03/24/1997
The Generic Security Service Application Program Interface (GSS-API), as
defined in RFC-1508, provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and technologies
and hence allowing source-level portability of applications to different
environments. It defines GSS-API services and primitives at a level
independent of underlying mechanism and programming language environment.
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.
The primitives of the GSS-API do not currently allow support of security
attributes other than a single identity and do not allow fine control
of delegation.
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-xgssapi-acc-cntrl-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-xgssapi-acc-cntrl-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-cat-xgssapi-acc-cntrl-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: <19970324144250.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-xgssapi-acc-cntrl-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-xgssapi-acc-cntrl-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324144250.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12026; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa11351; 25 Mar 97 10:16 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-mib-01.txt
Date: Tue, 25 Mar 1997 10:16:23 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11351 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 : Management Information Base for IP Version 6: Textual
Conventions and General Group
Author(s) : D. Haskin, S. Onishi
Filename : draft-ietf-ipngwg-ipv6-mib-01.txt
Pages : 40
Date : 03/24/1997
This document is one in the series of documents that provide MIB
definitions for IP Version 6. Specifically, the IPv6 MIB textual
conventions as well as the IPv6 MIB General group is defined
in this document.
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols
in the IPv6-based internets.
This document specifies a MIB module in a manner that is both
compliant to the SNMPv2 SMI, and semantically identical to the
peer SNMPv1 definitions.
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-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-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-ipngwg-ipv6-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: <19970324145010.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324145010.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12066; 25 Mar 97 10:17 EST
Received: from ietf.ietf.org by ietf.org id aa11395; 25 Mar 97 10:16 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-udp-tcp-mib-01.txt
Date: Tue, 25 Mar 1997 10:16:26 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11395 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 : Management Information Base for IP Version 6: UDP and
TCP Groups
Author(s) : D. Haskin, S. Onishi
Filename : draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt
Pages : 19
Date : 03/24/1997
This document is one in the series of documents that define various MIB
object groups for IPv6. Specifically, the UDP and TCP groups are defined
in this document.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets.
This document specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
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-udp-tcp-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-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-ipngwg-ipv6-udp-tcp-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: <19970324150550.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324150550.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12182; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11517; 25 Mar 97 10:16 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pwg at pwg.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-printmib-mib-info-01.txt
Date: Tue, 25 Mar 1997 10:16:39 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11517 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 Printer MIB Working Group of
the IETF.
Title : Printer MIB
Author(s) : R. Turner
Filename : draft-ietf-printmib-mib-info-01.txt
Pages : 157
Date : 03/24/1997
This document provides definitions of models and manageable objects for
printing environments. The objects included in this MIB apply to physical,
as well as logical entities within a printing device. This MIB definition
makes explicit references to the Host Resources MIB (RFC 1514), as well as
the Interfaces Group of MIB-II (RFC 1213).
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-printmib-mib-info-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-mib-info-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-printmib-mib-info-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: <19970324151404.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-printmib-mib-info-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-printmib-mib-info-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324151404.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12265; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11585; 25 Mar 97 10:16 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-tn-00.txt
Date: Tue, 25 Mar 1997 10:16:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11585 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 Internetworking Over NBMA
Working Group of the IETF.
Title : Transient Neighbors for IPv6 over ATM
Author(s) : G. Armitage, P. Schulter, M. Jork, G. Harter
Filename : draft-ietf-ion-tn-00.txt
Pages : 30
Date : 03/24/1997
This document describes a model for IPv6 over ATM. The model allows
conventional host-side operation of the Neighbor Discovery protocol, while
also supporting the establishment of 'shortcut' ATM routes. This is
achieved through the use of Redirects to create Transient Neighbors,
standard IPv6 protocol operation within the IPv6 Logical Link, and partial
NHRP for location of off-Link destinations. The egress router detects
flows that are suitable candidates for shortcut, uses NHRP to locate a
better link level first hop, and then issues a Redirect message
to the source.
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-tn-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-tn-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-ion-tn-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: <19970324153225.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-tn-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-tn-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324153225.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12282; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11674; 25 Mar 97 10:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.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-issll-is802-framework-01.txt
Date: Tue, 25 Mar 1997 10:16:55 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa11674 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 Services over
Specific Link Layers Working Group of the IETF.
Title : A Framework for Providing Integrated Services Over
Shared and Switched LAN Technologies
Author(s) : A. Ghanwani, W. Pace, V. Srinivasan
Filename : draft-ietf-issll-is802-framework-01.txt
Pages : 17
Date : 03/24/1997
Traditionally, LAN technologies such as ethernet and token ring have been
required to handle best effort services only. No standard mechanism exists
for providing service guarantees on these media as will be required by
emerging and future multimedia applications. The anticipated demand for
such applications on the Internet has led to the development of RSVP, a
signaling mechanism for performing resource reservation in the Internet.
Concurrently, the Integrated Services working group within the IETF has
been working on the definition of service classes called Integrated
Services which are expected to make use of RSVP. Applications will use
these service classes in order to obtain the desired quality of service
from the network. LAN technologies such as token ring and ethernet
typically constitute the last hop in Internet connections. It is therefore
necessary to enhance these technologies so that they are able to support
the Integrated Services. This memo describes a framework for providing the
functionality to support Integrated Services on shared and switched LAN
technologies.
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-issll-is802-framework-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-is802-framework-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-issll-is802-framework-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: <19970324155016.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-is802-framework-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-is802-framework-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324155016.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12328; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11697; 25 Mar 97 10:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bmwg at harvard.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-bmwg-ippm-loss-00.txt
Date: Tue, 25 Mar 1997 10:16:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa11697 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 Benchmarking Methodology
Working Group of the IETF.
Title : A Packet Loss Metric for IPPM
Author(s) : G. Almes, S. Kalidindi
Filename : draft-ietf-bmwg-ippm-loss-00.txt
Pages : 10
Date : 03/24/1997
This memo defines a metric for packet loss across Internet paths. It
builds on notions introduced and discussed in the IPPM Framework document
(currently "Framework for IP Provider Metrics"
<draft-ietf-bmwg-ippm-framework-00.txt>); the reader is assumed to be
familiar with that document.
This memo is intended to be very parallel in structure to a companion
document for One-way Delay (currently "A One-way Delay Metric for IPPM"
<draft-ietf-bmwg-ippm-delay-00.txt>); the reader is assumed to be familiar
with that 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-bmwg-ippm-loss-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-loss-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-bmwg-ippm-loss-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: <19970324163502.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-bmwg-ippm-loss-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bmwg-ippm-loss-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324163502.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa10386; 25 Mar 97 10:14 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-01.txt
Date: Tue, 25 Mar 1997 10:14:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10386 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 : RADIUS Server MIB
Author(s) : G. Zorn, B. Aboba
Filename : draft-ietf-radius-servmib-01.txt
Pages : 9
Date : 03/24/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-servmib-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-servmib-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: <19970324113218.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-servmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-servmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324113218.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa10387; 25 Mar 97 10:14 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-clientmib-00.txt
Date: Tue, 25 Mar 1997 10:14:39 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251014.aa10387 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 Client MIB
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-radius-clientmib-00.txt
Pages : 9
Date : 03/24/1997
This memo defines a set of extensions which instrument RADIUS client
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 clients.
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-clientmib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-clientmib-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-clientmib-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: <19970324113607.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-clientmib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-clientmib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324113607.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa10811; 25 Mar 97 10:15 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-kalevi-simple-media-access-00.txt, .ps
Date: Tue, 25 Mar 1997 10:15:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10811 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Integrated Media Access (SIMA)
Author(s) : K. Kilkki
Filename : draft-kalevi-simple-media-access-00.txt, .ps
Pages : 25
Date : 03/24/1997
The basic objectives of future Internet are to increase the network
capacity, to offer a practical real-time service, and to develop a feasible
charging scheme. These objectives introduce very strict requirements for
the traffic control system. This paper presents a new simple approach for
traffic management: Simple Integrated Media Access (SIMA) service.
According to the SIMA concept each customer shall define only two issues
before a connection establishment: a nominal bit rate (NBR) and the
selection between real-time and non-real-time service classes. NBR has two
purposes: it forms the basis of charging, and it defines how the network
capacity is divided among different connections during overload situations.
Simplicity means that, on the one hand, the network operator does not
guarantee the continuous availability of network operator does not
guarantee the continuous availability of nominal bit rate, and on the other
hand, the user is allowed to send data with any bit rate independently of
the NBR. However, the bit rate of transmission defines the cell loss
probability in the case of network congestion. In this way a simple, but
effective, self-regulation of traffic can be realised.
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-kalevi-simple-media-access-00.txt".
Or
"get draft-kalevi-simple-media-access-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kalevi-simple-media-access-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-kalevi-simple-media-access-00.txt".
Or
"FILE /internet-drafts/draft-kalevi-simple-media-access-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: <19970324134945.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kalevi-simple-media-access-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kalevi-simple-media-access-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324134945.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ad12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa10901; 25 Mar 97 10:15 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-tls at consensus.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-tls-protocol-02.txt
Date: Tue, 25 Mar 1997 10:15:30 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251015.aa10901 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-02.txt
Pages : 69
Date : 03/24/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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tls-protocol-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-tls-protocol-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: <19970324135627.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tls-protocol-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tls-protocol-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324135627.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12388; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11845; 25 Mar 97 10:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: grip-wg at uu.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-grip-framework-irt-04.txt
Date: Tue, 25 Mar 1997 10:17:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa11845 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 G and R for Security
Incident Processing Working Group of the IETF.
Title : Expectations for Security Incident Response
Author(s) : N. Brownlee, E. Guttman
Filename : draft-ietf-grip-framework-irt-04.txt
Pages : 29
Date : 03/24/1997
The purpose of this document is to express the general Internet community's
expectations of Security Incident Response Teams. It is not possible to
define a set of requirements that would be appropriate for all teams, but
it is possible and helpful to list and describe the general set of topics
and issues which are of concern and interest to constituent communities.
SIRT constituents have a legitimate need and right to fully understand the
policies and procedures of "their" Security Incident Response Team. One
way to support this understanding is to supply detailed information which
users may consider, in the form of a formal template completed by the SIRT.
An outline of such a template and a filled in example is 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-grip-framework-irt-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-grip-framework-irt-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-grip-framework-irt-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: <19970324164303.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-grip-framework-irt-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-grip-framework-irt-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324164303.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ae12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11538; 25 Mar 97 10:16 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-cheng-hmac-test-cases-00.txt
Date: Tue, 25 Mar 1997 10:16:43 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11538 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Test Cases for HMAC-MD5 and HMAC-SHA-1
Author(s) : P. Cheng, R. Glenn
Filename : draft-cheng-hmac-test-cases-00.txt
Pages : 8
Date : 03/24/1997
This document provides two sets of test cases for HMAC-MD5 and HMAC-SHA-1,
respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC]
message authentication function using the MD5 [MD5] hash function and the
SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and
other protocols to authenticate messages. The test cases and results
provided in this document are meant to be used as a conformance test for
HMAC-MD5 and HMAC-SHA-1 implementations.
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-cheng-hmac-test-cases-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-cheng-hmac-test-cases-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-cheng-hmac-test-cases-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: <19970324152657.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-cheng-hmac-test-cases-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-cheng-hmac-test-cases-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324152657.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id af12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11616; 25 Mar 97 10:16 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-thayer-seccomp-01.txt
Date: Tue, 25 Mar 1997 10:16:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251016.aa11616 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Compression Payload for Use with IP Security
Author(s) : R. Thayer
Filename : draft-thayer-seccomp-01.txt
Pages : 5
Date : 03/24/1997
This document describes a payload format to be used to store compressed
protocol messages within an IP packet which is using security features as
defined in [RFC-1825].
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-thayer-seccomp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thayer-seccomp-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-thayer-seccomp-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: <19970324153804.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thayer-seccomp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thayer-seccomp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324153804.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ag12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa11763; 25 Mar 97 10:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bmwg at harvard.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-bmwg-ippm-delay-01.txt
Date: Tue, 25 Mar 1997 10:17:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa11763 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 Benchmarking Methodology
Working Group of the IETF.
Title : A One-way Delay Metric for IPPM
Author(s) : G. Almes, S. Kalidindi
Filename : draft-ietf-bmwg-ippm-delay-01.txt
Pages : 12
Date : 03/24/1997
This memo defines a metric for one-way delay of packets across Internet
paths. It builds on notions introduced and discussed in the IPPM Framework
document (currently "Framework for IP Provider Metrics"
<draft-ietf-bmwg-ippm-framework-00.txt>); the reader is assumed to be
familiar with that document.
This memo is intended to be very parallel in structure to a companion
document for Packet Loss (soon to be submitted as "A Packet Loss Metric for
IPPM" <draft-ietf-bmwg-ippm-loss-00.txt>).
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-bmwg-ippm-delay-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-delay-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-bmwg-ippm-delay-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: <19970324163817.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-bmwg-ippm-delay-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bmwg-ippm-delay-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324163817.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ah12345; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa12045; 25 Mar 97 10:17 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-icmp-mib-01.txt
Date: Tue, 25 Mar 1997 10:17:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa12045 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 : Management Information Base for IP Version 6:
ICMPv6 Group
Author(s) : D. Haskin, S. Onishi
Filename : draft-ietf-ipngwg-ipv6-icmp-mib-01.txt
Pages : 18
Date : 03/24/1997
This document is one in the series of documents that define various
MIB object groups for IPv6. Specifically, the ICMPv6 group is defined
in this document.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the
IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer
SNMPv1 definitions.
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-icmp-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-icmp-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-ipngwg-ipv6-icmp-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: <19970324164816.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-icmp-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-icmp-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324164816.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12604; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa12125; 25 Mar 97 10:17 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipp at pwg.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-ipp-req-00.txt
Date: Tue, 25 Mar 1997 10:17:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa12125 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 Printing Protocol
Working Group of the IETF.
Title : Requirements for an Internet Printing Protocol
Author(s) : F. Wright
Filename : draft-ietf-ipp-req-00.txt
Pages : 53
Date : 03/24/1997
This document is one of a set of documents which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an application
level protocol that can be used for distributed printing on the Internet.
The protocol is heavily influenced by the printing model introduced in the
Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA
identifies the both end user and administrative features, IPP is initially
focused only on the end user functionality.
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-ipp-req-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-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-ipp-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: <19970324170108.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipp-req-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipp-req-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324170108.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12603; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa12175; 25 Mar 97 10:17 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-sio-00.txt
Date: Tue, 25 Mar 1997 10:17:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa12175 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 : The Server Identification Option for DHCP
Author(s) : G. Stump, P. Gupta
Filename : draft-ietf-dhc-sio-00.txt
Pages : 6
Date : 03/24/1997
This option is provided by DHCP servers to DHCP clients to identify the
origin of a DHCPOFFER -- on a basis other than a server's IP address -- so
that a DHCP client may optionally select from among multiple offers based
on a client's preference to a particular DHCP server(s). The information
contained in this option is a hex value indicating the assigned
identification of the server originating the DHCPOFFER in which
this option is contained.
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-sio-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-sio-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-sio-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: <19970324172725.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-sio-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-sio-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324172725.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12624; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa12239; 25 Mar 97 10:18 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-userclass-01.txt
Date: Tue, 25 Mar 1997 10:18:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251018.aa12239 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 : The User Class Option for DHCP
Author(s) : G. Stump, R. Droms
Filename : draft-ietf-dhc-userclass-01.txt
Pages : 5
Date : 03/24/1997
This option is used by a DHCP client to optionally identify the type or
category of user or applications it represents. The information contained
in this option is an NVT ASCII text object that represents the user class
of which the client is a member.
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-userclass-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-userclass-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-userclass-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: <19970324173547.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-userclass-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-userclass-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324173547.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12643; 25 Mar 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa12208; 25 Mar 97 10:17 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-sso-00.txt
Date: Tue, 25 Mar 1997 10:17:55 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703251017.aa12208 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 : The Server Selection Option for DHCP
Author(s) : P. Gupta, G. Stump
Filename : draft-ietf-dhc-sso-00.txt
Pages : 6
Date : 03/24/1997
This option is provided by DHCP servers to DHCP clients so that clients may
optionally select from among multiple offers received from DHCP servers in
the network based on a network-administrated preference system. The
information contained in this option is a hex value that represents the
priority of the offer in which this option is contained.
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-sso-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-sso-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-sso-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: <19970324173159.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-sso-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-sso-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324173159.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13187; 25 Mar 97 10:23 EST
Received: from ietf.ietf.org by ietf.org id aa12938; 25 Mar 97 10:22 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Document Action: Basic Socket Interface Extensions for IPv6 to
Informational
Date: Tue, 25 Mar 1997 10:22:30 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703251022.aa12938 at ietf.org>
The IESG has reviewed the Internet-Draft "Basic Socket Interface
Extensions for IPv6" <draft-ietf-ipngwg-bsd-api-07.txt> and
recommends that it be published by the RFC Editor as an Informational
RFC. This document is the product of the IPNG Working Group. The IESG
contact persons are Frank Kastenholz and Jeffrey Burgan.
Received: from ietf.org by ietf.org id aa13180; 25 Mar 97 10:23 EST
Received: from dns.umu.se by ietf.org id aa12384; 25 Mar 97 10:18 EST
Received: from eleanor.umdc.umu.se (eleanor.umdc.umu.se [130.239.17.32])
by mail.umu.se (8.8.5/8.8.5) with SMTP id QAA02207;
Tue, 25 Mar 1997 16:15:00 +0100 (MET)
Message-Id: <1.5.4.32.19970325152322.00766460 at macavity.umdc.umu.se>
X-Sender: roland at macavity.umdc.umu.se (Unverified)
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 Mar 1997 16:23:22 +0100
To: Phil Karn <karn at qualcomm.com>
Sender:ietf-request at ietf.org
From: Roland Hedberg <Roland.Hedberg at umdac.umu.se>
Subject: Re: Memphis hotel situation
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 17:10 1997-03-06 -0800, Phil Karn wrote:
>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?
>
A little more than a month ago (20th feb, the day after the hotel name was
published )
I started to try to get a hotel room at the Peabody Hotel, to this day I
have not been
able to get a reservation for the complete week. For a week or two I
actually though I
had succeeded but...
In fact I have only been able to get a reservation for the 5th until the 8th.
But that's not all, in the latest message I got from Peabody they indicated
that they now
had raised there price to US$ 230!!!!/single/day on what grounds I do not know.
At this time the probabilitity of finding a room for a week at another hotel
in the vicinity of Peabody must be approaching zero, still I have to try.
So if anyone can give me a hint as to where to look please do.
And as a final comment: I don't know if all attendees of the IETF meeting
has met the same
treatment as I have or if I'm punished for not being a US-citizent or whatever.
Still I can't help feeling that I have done what has been possible from my
position and
obviously failed, so there must be some structural error in the process.
-- Roland
Received: from ietf.org by ietf.org id aa13483; 25 Mar 97 10:25 EST
Received: from ietf.ietf.org by ietf.org id aa13390; 25 Mar 97 10:24 EST
To: IETF-Announce: ;
cc: snanaumib at external.cisco.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Definitions of Managed Objects for APPN to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Tue, 25 Mar 1997 10:24:48 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703251024.aa13390 at ietf.org>
The IESG has received a request from the SNA NAU Services MIB Working
Group to consider "Definitions of Managed Objects for APPN"
<draft-ietf-snanau-appnmib-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 April 14, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa16132; 25 Mar 97 10:39 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa11997; 25 Mar 97 10:39 EST
Received: (from slist at localhost) by merit.edu (8.8.5/merit-2.0) id KAA17509; Tue, 25 Mar 1997 10:13:53 -0500 (EST)
Resent-Date: Tue, 25 Mar 1997 10:13:53 -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-l2tp-03.txt
Date: Tue, 25 Mar 1997 10:14:25 -0500
Sender: cclark at ietf.org
Message-ID: <9703251014.aa10287 at ietf.org>
Resent-Message-ID: <"H5rzb.0.JH4.ik-Dp"@merit.edu>
Resent-From: ietf-ppp at merit.edu
X-Mailing-List: <ietf-ppp at MERIT.EDU> archive/latest/2880
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 : 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-03.txt
Pages : 79
Date : 03/24/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-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-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-pppext-l2tp-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: <19970324105910.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-l2tp-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-l2tp-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324105910.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa17218; 25 Mar 97 10:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12427;
25 Mar 97 10:54 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA19011 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 14:20:25 GMT
Message-Id: <9703251408.AA20196 at us1rmc.bb.dec.com>
Date: Tue, 25 Mar 97 09:08:07 EST
From: "John Wray, Digital DPE, 508/486-5210 25-Mar-1997 0859" <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: Diffs in GSSAPI C-bindings draft -04
Precedence: bulk
The new C-bindings document is available from the usual sites. Here's a
summary of the changes (thanks to Martin for producing diffs against the
previous version):
Replaced "GSS_CONST" with "const".
Added text to descriptions of routines that return dynamic data indicating
which routine the app should use to free that data.
Deleted gss_release_oid(), gss_oid_to_str() and gss_str_to_oid() and
removed references to them.
Added comment in section 5.4 about all gss_OID_sets being dynamic objects.
Added para about the semantic differences between comparing names with
gss_compare_names() vs. gss_export_name() & memcmp()
Moved the comments about IP and X.25 to their correct address families.
Added a para about delegated credentials, the identities they contain,
and how they may be used.
Modified the example application code for gss_init/accept_sec_context()
to better handle token deletion and error cases.
Added text to gss_init/accept_sec_context() clarifying behavior in the
event of an error.
Added commentary to gss_accept/init_sec_context saying the the
implementation should set unused bits in ret_flags to zero.
Added GSS_S_CREDENTIALS_EXPIRED and GSS_S_NO_CRED as possible returns
from gss_acquire_cred() and gss_add_cred().
Replaced references to "signatures" with "MICs".
Added GSS_S_BAD_MIC as an alias for GSS_S_BAD_SIG.
Added commentary text to gss_release_oid_set().
In textual description of boolean parameters, replaced "false" and "true"
with "zero" and "non-zero" to better match C.
Added a para to gss_delete_sec_context() routine description saying that
the app must free half-built contexts resulting from incomplete init/accept
calls.
Significantly expanded commentary for gss_display_status().
Added to commentary of gss_export_sec_context() as per discussion on list.
Added para to gss_wrap saying that wrapping of zero-length tokens should be
permitted.
Fixed typos (and probably introduced some others).
John
Received: from ietf.org by ietf.org id aa11532; 25 Mar 97 14:39 EST
Received: from HOPS.AG.UTK.EDU by ietf.org id aa10792; 25 Mar 97 14:34 EST
Received: from hops.ag.utk.edu ( [128.169.15.22] ) by hops.ag.utk.edu
(Hethmon Brothers Smtpd) ; Tue, 25 Mar 1997 14:31:30 -0500
Message-Id: <199702251431.3025493.7 at hops.ag.utk.edu>
To: cat-ietf at mit.edu, Ftp-wg <ftp-wg at hops.ag.utk.edu>, ietf at ietf.org
Priority: Normal
X-Mailer: Post Road Mailer (Green Edition Ver 2.0.15)
Date: Tue, 25 Mar 1997 14:31:27
Sender:ietf-request at ietf.org
From: Paul Hethmon <phethmon at utk.edu>
Reply-To: phethmon at utk.edu
Subject: Comments on FTP Security Extensions draft
Source-Info: From (or Sender) name not authenticated.
Addressed to: cat-ietf at mit.edu
Ftp-wg <ftp-wg at hops.ag.utk.edu>
ietf at ietf.org
I've got some general comments on the FTP Security Extensions
draft: draft-ietf-cat-ftpsec-09.txt
General comments: Overall, I feel the draft provides a good
framework for security within the FTP protocol. It seems a
bit complex, but does have the virtue of sitting transparently
over existing FTP. There are a few points I would like to see
addressed before advancing the draft.
Specifically:
1. The draft needs a reference for GSSAPI and Kerberos V4. It
should not assume these are common knowledge.
2. While the GSSAPI and Kerberos appendices do offer an example
on implementation, the document would greatly benefit from a
generic example. If you're not familar with either of those
mentioned, then understanding the control flow and mechanisms
is much harder. Something which is a contrived example with
explanations is needed.
3. PASS is mentioned as optional if an AUTH scheme is used. A
clearer idea that the individual AUTH scheme specifies whether
it is and whether encryption over it is used would be helpful.
4. The draft notes IANA is to register AUTH schemes. Does this
registry include information about the actual scheme, or just
the name? If the latter, then requiring an informational
RFC to describe the scheme and where to go for more information
seems a necessity to me. Otherwise, we're leaving out the most
important part. If FTP implementors don't know where to find the
information, it will be impossible to do. Don't assume because
those in the security field are familiar with the schemes that
everyone else is. It's likely they're not.
5. In Section 6, a reference is made to "most significant byte
first". To be clearer, I think adding "network byte order" would
be helpful. It may just be me, but the term "network byte order"
is more clear. When I see "most significant byte first", I have
to run and check my docs again.
6. Given the overall FTP updates, the FTPEXT working group is
handling. I think this document should address the i18n issues
in draft-ietf-ftpext-intl-01.txt. Whether it does this by
incorporating those proposals, or by not allowing them is a
toss up at this point. I would rather see this draft encompass
them, but given the point it is, I could live with a disclaimer
that they are not supported.
thanks,
Paul Hethmon
FTPEXT Chair
Paul Hethmon
phethmon at hethmon.com -- phethmon at utk.edu
------------------------------------------------------------
Inet.Mail Internet Mail Server -- http://www.hethmon.com/inetmail.html
------------------------------------------------------------
Author of "Illustrated Guide to HTTP", Manning April 97
http://www.browsebooks.com/Hethmon
------------------------------------------------------------
Received: from cnri by ietf.org id aa24586; 25 Mar 97 17:12 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21757;
25 Mar 97 17:12 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA14712 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 20:27:41 GMT
Message-Id: <199703252027.PAA02529 at thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: cat-ietf at mit.edu
Subject: possible future work item for CAT: kerberos-through-firewalls?
Date: Tue, 25 Mar 1997 15:27:24 -0500
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Precedence: bulk
Within the firewall-building community, there is a strong resistance
to letting *any* UDP traffic through firewalls as well as to putting
Kerberos KDC replicas outside a firewall. Regardless of whether these
fears are well-founded (and, in general, I think they are not
well-founded), they are an obstacle to deployment of Kerberos in many
environments.
Is there any interest within this WG in exploring ways to allow a
firewall to act as a relay agent for the client-KDC protocols?
There seem to be several issues lurking here:
- relaying the requests themselves
- dealing with protocol addresses inside tickets
- outbound vs. inbound relaying (i.e., client behind firewall,
KDC behind firewall, or both).
Maybe we can talk about this for a few minutes at the CAT meeting in Memphis.
- Bill
Received: from cnri by ietf.org id aa27850; 25 Mar 97 18:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22891;
25 Mar 97 18:08 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA18730 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 21:26:09 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: <199703242009.AA00656 at sap-ag.de>
From: Marc Horowitz <marc at cygnus.com>
Date: 25 Mar 1997 16:25:39 -0500
In-Reply-To: Martin Rex's message of Mon, 24 Mar 1997 15:09:10 -0500 (EST)
Message-Id: <t53913bpsto.fsf at rover.cygnus.com>
Lines: 53
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> 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.
This is not true. You can pass GSS_C_NO_NAME as the desired_name
argument to gss_acquire_cred, or you can pass GSS_C_NO_CREDENTIAL as
the credential to gss_init_sec_context or gss_accept_sec_context.
Actually, looking at cbind-03, it looks like the latter two functions
are allowed to return GSS_S_NO_CRED if GSS_C_NO_CREDENTIAL is specified:
initiator_cred_handle gss_cred_id_t, read, optional
handle for credentials claimed. Supply
GSS_C_NO_CREDENTIAL to act as a default
initiator principal. If no default
initiator is defined, the function will
return GSS_S_NO_CRED.
acceptor_cred_handle gss_cred_id_t, read
Credential handle claimed by context acceptor.
Specify GSS_C_NO_CREDENTIAL to accept the
context as a default principal. If
GSS_C_NO_CREDENTIAL is specified, but no
default acceptor principal is defined,
GSS_S_NO_CRED will be returned.
This is a change from rfc1509, and seems to be in conflict with
rfc2078. When was it added? I believe that all mechanisms must have
some sort of default credential semantics, at least for initiation.
Otherwise, Martin would be correct, and writing a portable application
would be impossible.
rfc2078 says, for init:
o GSS_S_NO_CRED indicates that no context was established,
either because the input cred_handle was invalid, because the
referenced credentials are valid for context acceptor use
only, or because the caller lacks authorization to access the
referenced credentials.
and for accept:
o GSS_S_NO_CRED indicates that no context was established, either
because the input cred_handle was invalid, because the
referenced credentials are valid for context initiator use
only, or because the caller lacks authorization to access the
referenced credentials.
These descriptions do not refer to the absence of a definition of
defaults.
Marc
Received: from cnri by ietf.org id aa03811; 25 Mar 97 19:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24575;
25 Mar 97 19:38 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA25919 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 22:58:06 GMT
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Cc: cat-ietf at mit.edu
Subject: Re: possible future work item for CAT: kerberos-through-firewalls?
References: <199703252027.PAA02529 at thunk.ch.apollo.hp.com>
From: Mark Eichin <eichin at cygnus.com>
Date: 25 Mar 1997 17:56:43 -0500
In-Reply-To: Bill Sommerfeld's message of Tue, 25 Mar 1997 15:27:24 -0500
Message-Id: <xe1lo7bmvh0.fsf at maneki-neko.cygnus.com>
Lines: 5
X-Mailer: Gnus v5.4.15/Emacs 19.34
Precedence: bulk
> There seem to be several issues lurking here:
Also consider that perhaps defining a TCP interface to the kdc would
help make the protocol "more acceptable" to this community...
Received: from ietf.org by ietf.org id aa05085; 25 Mar 97 20:02 EST
Received: from ingwwdf.sap-ag.de by ietf.org id aa04526; 25 Mar 97 19:53 EST
Received: from sap-ag.de (sapwdf.wdf.sap-ag.de [147.204.3.3]) by ingwwdf.wdf.sap-ag.de (8.6.12/8.6.9) with SMTP id BAA20195; Wed, 26 Mar 1997 01:48:28 +0100
Received: from hw1464.wdf.sap-ag.de by sap-ag.de with SMTP id AA11029
(5.67b8/IDA-1.5); Wed, 26 Mar 1997 02:49:18 +0200
Message-Id: <199703260049.AA11029 at sap-ag.de>
Received: by hw1464.wdf.sap-ag.de
(1.39.111.2/16.2) id AA255237359; Tue, 25 Mar 1997 19:49:19 -0500
Sender:ietf-request at ietf.org
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Comments on FTP Security Extensions draft
To: phethmon at utk.edu
Date: Tue, 25 Mar 1997 19:49:19 -0500 (EST)
Cc: cat-ietf at mit.edu, ftp-wg at hops.ag.utk.edu, ietf at ietf.org
In-Reply-To: <199702251431.3025493.7 at hops.ag.utk.edu> from "Paul Hethmon" at Mar 25, 97 02:31:27 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
Content-Length: 1993
Source-Info: From (or Sender) name not authenticated.
Paul Hethmon wrote:
>
> 5. In Section 6, a reference is made to "most significant byte
> first". To be clearer, I think adding "network byte order" would
> be helpful. It may just be me, but the term "network byte order"
> is more clear. When I see "most significant byte first", I have
> to run and check my docs again.
If you think the term "network byte order" is clearer, then maybe
you have a problem with the english language. ;-)
"most significant byte first" is definitely self-explaining.
It's funny, I have complained that "network byte order" will not be
sufficiently clear for RFC2078, Section 3.2 and requested the term
"most significant octet first" (similar to Section 3.1).
If you have a 32-bit integer, most significant byte first is obviously:
unsigned char stream[n+x+4];
stream[n+0] = (unsigned char)((int32>>24) & 0xff);
stream[n+1] = (unsigned char)((int32>>16) & 0xff);
stream[n+2] = (unsigned char)((int32>>8) & 0xff);
stream[n+3] = (unsigned char)(int32 & 0xff);
This is regular ANSI-C, works on all platforms, it is a
straightforward implementation from the term "most significant byte first",
and it doesn't have any alignment restrictions for "n".
In the context of FTP, which is a protocol for IP networking, you
will most probably have a socket interface available and be using it,
so using the functions "ntohs()/htons()" and "ntohl()/htonl()" might
be "easier" for you when dealing with 16- and 32-bit quantities,
but you should be aware that these functions are neither ANSI-C
nor POSIX. And if you want to put the result at an arbitrary (unaligned)
address, you'll have to memcpy it over.
Also you should be aware of platform-specifics when using non-standard
functions: E.g. in Microsoft Windows "ntohs()/htons()" and "ntohl()/htonl()"
are implemented as functions within the Winsock-DLL, and under certain
conditions they cause a GPV if you try to use them without having called
WSAStartup() first! (No kidding!)
-Martin
Received: from cnri by ietf.org id aa07992; 25 Mar 97 20:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25858;
25 Mar 97 20:58 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA26481 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 23:05:39 GMT
Date: Tue, 25 Mar 1997 18:05:34 -0500
Message-Id: <9703252305.AA29917 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Cc: cat-ietf at mit.edu
In-Reply-To: Bill Sommerfeld's message of Tue, 25 Mar 1997 15:27:24 -0500,
<199703252027.PAA02529 at thunk.ch.apollo.hp.com>
Subject: Re: possible future work item for CAT: kerberos-through-firewalls?
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Tue, 25 Mar 1997 15:27:24 -0500
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Within the firewall-building community, there is a strong resistance
to letting *any* UDP traffic through firewalls as well as to putting
Kerberos KDC replicas outside a firewall. Regardless of whether these
fears are well-founded (and, in general, I think they are not
well-founded), they are an obstacle to deployment of Kerberos in many
environments.
Is there any interest within this WG in exploring ways to allow a
firewall to act as a relay agent for the client-KDC protocols?
I'm certainly interested!
There seem to be several issues lurking here:
...
- outbound vs. inbound relaying (i.e., client behind firewall,
KDC behind firewall, or both).
Note that this last one is much more complicated than that; I think we
should look at all combinations where (client, server, or KDC) are not
on the same side of the firewall. So we need to look at the cases where
the server is behind the firewall, and the client is not, and vice
versa. This is especially problematic when the firewall is playing
address translation games, since the Kerberos client needs to know
whether or not a particular application server is going to have its
address translated by the firewall or not.
- Ted
Received: from cnri by ietf.org id aa08442; 25 Mar 97 21:05 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26006;
25 Mar 97 21:05 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA24486 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 22:39:56 GMT
Message-Id: <199703252238.AA25687 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: Name type issues
To: Marc Horowitz <marc at cygnus.com>
Date: Tue, 25 Mar 1997 17:38:52 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53913bpsto.fsf at rover.cygnus.com> from "Marc Horowitz" at Mar 25, 97 04:25:39 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:
>
> >> 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.
>
> This is not true. You can pass GSS_C_NO_NAME as the desired_name
> argument to gss_acquire_cred, or you can pass GSS_C_NO_CREDENTIAL as
> the credential to gss_init_sec_context or gss_accept_sec_context.
I wanted to say that you need a "name+nametype" to create a
target_name suitable for gss_init_sec_context().
I was looking for something analogous to GSS_C_NT_USER_NAME, but it
should be interpreted by the mechanism instead. (for multimechanisms
with non-intersecting namespace this might mean "do the best you can").
GSS_C_NO_OID was looking like a good canditate, but it looks like it is
too late to nail down the meaning into the (krb5) mechanism spec. By being
available but not being defined, it has become unusable for "portable"
applications (which don't know the mechanism they're going to use).
-Martin
Received: from cnri by ietf.org id aa09764; 25 Mar 97 21:38 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26451;
25 Mar 97 21:38 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <BAA06211 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 01:27:54 GMT
From: assar at pdc.kth.se
To: Mark Eichin <eichin at cygnus.com>
Cc: Bill Sommerfeld <sommerfeld at apollo.hp.com>, cat-ietf at mit.edu
Subject: Re: possible future work item for CAT: kerberos-through-firewalls?
References: <199703252027.PAA02529 at thunk.ch.apollo.hp.com>
<xe1lo7bmvh0.fsf at maneki-neko.cygnus.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
Date: 26 Mar 1997 02:27:47 +0100
In-Reply-To: Mark Eichin's message of 25 Mar 1997 17:56:43 -0500
Message-Id: <5liv2fa1d8.fsf at assaris.sics.se>
Lines: 14
X-Mailer: Gnus v5.2.40/Emacs 19.34
Precedence: bulk
Mark Eichin <eichin at cygnus.com> writes:
> > There seem to be several issues lurking here:
>
> Also consider that perhaps defining a TCP interface to the kdc would
> help make the protocol "more acceptable" to this community...
We did exactly that in our kerberos 4 distribution for exactly those
reasons.
Why not simply add the following to section 8.2.1 of RFC1510?
A KDC may also listen on TCP port 88 (decimal).
/assar
Received: from cnri by ietf.org id aa10979; 25 Mar 97 22:09 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26956;
25 Mar 97 22:09 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA27937 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 23:26:58 GMT
To: phethmon at utk.edu
Cc: cat-ietf at mit.edu, Ftp-wg <ftp-wg at hops.ag.utk.edu>
Subject: Re: Comments on FTP Security Extensions draft
References: <199702251431.3025493.7 at hops.ag.utk.edu>
From: Marc Horowitz <marc at cygnus.com>
Date: 25 Mar 1997 18:26:14 -0500
In-Reply-To: Paul Hethmon's message of Tue, 25 Mar 1997 14:31:27
Message-Id: <t534tdzpn8p.fsf at rover.cygnus.com>
Lines: 87
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
(I've removed ietf at ietf.org from the cc list.)
Paul Hethmon <phethmon at utk.edu> writes:
>> 1. The draft needs a reference for GSSAPI and Kerberos V4. It
>> should not assume these are common knowledge.
This is reasonable.
>> 2. While the GSSAPI and Kerberos appendices do offer an example
>> on implementation, the document would greatly benefit from a
>> generic example. If you're not familar with either of those
>> mentioned, then understanding the control flow and mechanisms
>> is much harder. Something which is a contrived example with
>> explanations is needed.
At least *some* people will be familiar with GSSAPI and/or Kerberos.
It's pretty much guaranteed that nobody will be familiar with a
contrived example. If you have to learn a contrived example or a real
mechanism, you're better off learning a real mechanism, since this
will be useful to you in the future. This is going to sound
pretentious, but if you're not familiar with basic security
mechanisms, perhaps you shouldn't be implementing security. Much
painful experience has taught us that when people who don't know
security try to do it, they make mistakes.
>> 3. PASS is mentioned as optional if an AUTH scheme is used. A
>> clearer idea that the individual AUTH scheme specifies whether
>> it is and whether encryption over it is used would be helpful.
Section seven covers this issue, I think. Policy issues are
intentionally left up to the implementation.
>> 4. The draft notes IANA is to register AUTH schemes. Does this
>> registry include information about the actual scheme, or just
>> the name? If the latter, then requiring an informational
>> RFC to describe the scheme and where to go for more information
>> seems a necessity to me. Otherwise, we're leaving out the most
>> important part. If FTP implementors don't know where to find the
>> information, it will be impossible to do. Don't assume because
>> those in the security field are familiar with the schemes that
>> everyone else is. It's likely they're not.
Just the name. Mechanism implementors may choose to issue an RFC (and
I would hope they would), but if someone wants to register a name for
a proprietary mechanism which works within the ftpsec frameword, this
should be allowed. The purpose of registration is simply to avoid
conflicts. For a parallel issue, consider MIME types.
application/rtf has a published specification. application/msword
does not, but is still registered.
>> 5. In Section 6, a reference is made to "most significant byte
>> first". To be clearer, I think adding "network byte order" would
>> be helpful. It may just be me, but the term "network byte order"
>> is more clear. When I see "most significant byte first", I have
>> to run and check my docs again.
I've heard people say the exact opposite :-) I'll use both terms, to
avoid any confusion.
>> 6. Given the overall FTP updates, the FTPEXT working group is
>> handling. I think this document should address the i18n issues
>> in draft-ietf-ftpext-intl-01.txt. Whether it does this by
>> incorporating those proposals, or by not allowing them is a
>> toss up at this point. I would rather see this draft encompass
>> them, but given the point it is, I could live with a disclaimer
>> that they are not supported.
I just read this draft for the first time. It looks to me like it and
ftpsec are compatible with no changes to either document (I make no
such claims about the implementation, though :-). I don't know what
the status of intl-ftp-01 is, but the intent of ftpsec is that it
update rfc959. If whichever of intl-ftp-01 and ftpsec progresses
first updates rfc959, and the other updates the first, then I believe
we're all set. Do any WG chairs, AD's, or other process hackers have
any comments on this?
The only issue I believe to be potentially contentious is number 2.
However, assuming we can agree to have ftpsec continue doing what it
has been doing, I think the remainder of the changes (adding
references for gssapi and krb4, and clarifying that big-endian is net
byte order) are clearly editorial.
Thank you for your comments!
Marc
Received: from cnri by ietf.org id aa11301; 25 Mar 97 22:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27053;
25 Mar 97 22:15 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA26100 at pad-thai.cam.ov.com>; Tue, 25 Mar 1997 23:00:54 GMT
Message-Id: <199703252259.AA26855 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
To: Marc Horowitz <marc at cygnus.com>
Date: Tue, 25 Mar 1997 17:59:57 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <t53913bpsto.fsf at rover.cygnus.com> from "Marc Horowitz" at Mar 25, 97 04:25:39 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:
> [...] You can pass GSS_C_NO_NAME as the desired_name
> argument to gss_acquire_cred, or you can pass GSS_C_NO_CREDENTIAL as
> the credential to gss_init_sec_context or gss_accept_sec_context.
>
> Actually, looking at cbind-03, it looks like the latter two functions
> are allowed to return GSS_S_NO_CRED if GSS_C_NO_CREDENTIAL is specified:
>
> initiator_cred_handle gss_cred_id_t, read, optional
> handle for credentials claimed. Supply
> GSS_C_NO_CREDENTIAL to act as a default
> initiator principal. If no default
> initiator is defined, the function will
> return GSS_S_NO_CRED.
>
> acceptor_cred_handle gss_cred_id_t, read
> Credential handle claimed by context acceptor.
> Specify GSS_C_NO_CREDENTIAL to accept the
> context as a default principal. If
> GSS_C_NO_CREDENTIAL is specified, but no
> default acceptor principal is defined,
> GSS_S_NO_CRED will be returned.
>
> This is a change from rfc1509, and seems to be in conflict with
> rfc2078. When was it added? I believe that all mechanisms must have
> some sort of default credential semantics, at least for initiation.
> Otherwise, Martin would be correct, and writing a portable application
> would be impossible.
I would also like to require the "default" initiating credentials to
be defined.
I can live without default accepting credentials; actually I thought
I have to -- or does Kerberos support default accepting credentials?
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.
