[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
-Martin
Received: from cnri by ietf.org id aa13605; 25 Mar 97 22:40 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27412;
25 Mar 97 22:40 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <AAA04024 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 00:55:56 GMT
Message-Id: <199703260054.AA11608 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: possible future work item for CAT: kerberos-through-firewalls?
To: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Date: Tue, 25 Mar 1997 19:54:13 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <199703252027.PAA02529 at thunk.ch.apollo.hp.com> from "Bill Sommerfeld" at Mar 25, 97 03:27:24 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Bill Sommerfeld wrote:
>
> 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).
You should definitely plan for n>=2 firewall traversals.
As a provider of an application that allows customers to plug in
a Kerberos 5 gssapi mechanism, we would really appreciate solutions
in this area.
-Martin
Received: from cnri by ietf.org id aa13852; 25 Mar 97 22:46 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27536;
25 Mar 97 22:46 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <BAA07076 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 01:42:35 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>
Mime-Version: 1.0 (generated by tm-edit 7.103)
Content-Type: text/plain; charset=US-ASCII
From: Johan Danielsson <joda at pdc.kth.se>
Date: 26 Mar 1997 02:41:06 +0100
In-Reply-To: Bill Sommerfeld's message of Tue, 25 Mar 1997 15:27:24 -0500
Message-Id: <xofwwqv4eh9.fsf at blubb.pdc.kth.se>
Lines: 16
X-Mailer: Gnus v5.4.24/Emacs 19.34
Precedence: bulk
The case of having the client behind a firewall and the kdc and
service outside should is actually easier in v4 than in v5 (since the
client doesn't specify it's own address). For v5 the client should
have some way to find out what `extra' address it should add to the
ticket request.
If the firewall doesn't rewrite addresses of incoming packets, having
a client outside the the firewall shouldn't be any problem.
TCP definitely helps. The way I did this with the v4 KDC was to have
the client connect, send the request, and then shutdown(SHUT_WR), so
the KDC has an easy way to know when the client is finished. I also
added a timeout for `stale' clients.
/Johan
Received: from cnri by ietf.org id aa20556; 25 Mar 97 23:29 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00640;
25 Mar 97 23:29 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <BAA06382 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 01:31:05 GMT
Message-Id: <199702252031.0926411.7 at hops.ag.utk.edu>
To: ftp-wg at hops.ag.utk.edu, cat-ietf at mit.edu
Priority: Normal
X-Mailer: Post Road Mailer (Green Edition Ver 2.0.15)
Date: Tue, 25 Mar 1997 20:30:44 EST
From: Paul Hethmon <phethmon at utk.edu>
Reply-To: Paul Hethmon <phethmon at utk.edu>
Subject: Re: Ftp-WG: Re: Comments on FTP Security Extensions draft
Precedence: bulk
Addressed to: ftp-wg at hops.ag.utk.edu
cat-ietf at mit.edu
** Reply to note from ftp-wg at hops.ag.utk.edu Tue, 25 Mar 1997 19:50:31 -0500
> > 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.
I'm not saying "most significant byte first" is not clear, it's
crystal actually. What I'm saying is that most papers dealing with
"networking" issues and byte ordering talk about "network byte
order".
Disregarding the inherent problems with winsock, most tcp/ip stacks
do define the utility routines to convert between byte ordering. By
including the "network byte order" phrase, you clue in a lot of
people to exactly what you mean and what to do. Understanding is
never a bad thing, especially in RFC's.
Paul
Paul Hethmon
phethmon at utk.edu
phethmon at hethmon.com
----------------------------------------------------------
Inet.Mail for OS/2 -- Internet Mail Server
----------------------------------------------------------
www.hethmon.com -- ftp.hethmon.com
----------------------------------------------------------
Received: from cnri by ietf.org id aa21259; 25 Mar 97 23:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00906;
25 Mar 97 23:44 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <BAA07787 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 01:52:09 GMT
Message-Id: <199702252052.0129462.7 at hops.ag.utk.edu>
To: Marc Horowitz <marc at cygnus.com>, cat-ietf at mit.edu,
Ftp-wg <ftp-wg at hops.ag.utk.edu>
Priority: Normal
X-Mailer: Post Road Mailer (Green Edition Ver 2.0.15)
Date: Tue, 25 Mar 1997 20:51:36 EST
From: Paul Hethmon <phethmon at utk.edu>
Reply-To: Paul Hethmon <phethmon at utk.edu>
Subject: Re: Comments on FTP Security Extensions draft
Precedence: bulk
Addressed to: Marc Horowitz <marc at cygnus.com>
cat-ietf at mit.edu
Ftp-wg <ftp-wg at hops.ag.utk.edu>
** Reply to note from Marc Horowitz <marc at cygnus.com> 25 Mar 1997 18:26:14 -0500
> >> 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.
It's likely some of those people will implement security though. Take
the FTPEXT working group as an example. The folks on there represent
quite a few implementors and don't have the specific security
experience. But, their customers will demand security extensions
and some of them will implement it. Most people start by implementing
the protocol application, not a subset of it like security. They
will want to add it in though.
Anything which makes it clear is good. There are too many RFC's which
leave a lot to the imagination with bad to worse results. The non-specification
of LIST in ftp is a prime example. How many non-Unix hosts were there
when 959 was written? Probably not many. Now it's a problem.
Now I do expect anyone who wishes to implement security to do their
homework. The RFC shouldn't spell it all out.
Take this as an example. We could come up with a MD-5 authentication
scheme similar to APOP in POP3. Under this scheme, the registered name
is MD-5. When the client sends the AUTH MD-5, the server should reply
with the key value indicating ADAT is required. The client performs the
MD-5 algorithm over the key value and the shared secret and returns
this in the ADAT reply. If the hash is correct, then the server
indicates to send USER (per the RFC, since the username would have
to be passed as part of the ADAT request). Once USER is received, the
server indicates the client is logged in. The example could continue
by saying the MD-5 scheme does not offer control connection encryption
but uses CCC instead. Likewise, no encryption is performed over the
data connection.
This would be an example of a simple mechanism which I think would
be understandable quicker. A couple of flow charts of the request/response
chain would be the only other thing needed. Maybe some points that this
is only an example and other schemes will be different.
Actually, I wouldn't mind seeing a basic MD-5 based scheme here. It's
not the most secure mechanism, but everything needed is available
in public domain form as RFCs. It would provide increased security for
probably 95% of the uses of named ftp by not sending clear passwords.
Would you consider adding a 3rd appendix if I write up something based
on the above? It would cover my concerns about an example which is
more widely known (MD-5) and easily understood.
thanks,
Paul
Paul Hethmon
phethmon at utk.edu
phethmon at hethmon.com
----------------------------------------------------------
Inet.Mail for OS/2 -- Internet Mail Server
----------------------------------------------------------
www.hethmon.com -- ftp.hethmon.com
----------------------------------------------------------
Received: from cnri by ietf.org id aa29344; 26 Mar 97 2:34 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa03629;
26 Mar 97 2:34 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <GAA25552 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 06:21:51 GMT
Message-Id: <9703260622.AA00028 at dell-mh.mecse.mec.mei.co.jp>
From: Masato Hirose <mhirose at mecse.mec.mei.co.jp>
Date: Wed, 26 Mar 1997 15:22:29 +0900
To: cat-ietf at mit.edu
Subject: unsubscribe
In-Reply-To: <199702252052.0129462.7 at hops.ag.utk.edu>
Mime-Version: 1.0
X-Mailer: AL-Mail 1.32
Content-Type: text/plain; charset=us-ascii
Precedence: bulk
How can I unsubscribe this mailing list?
Does anyone help me?
// Masato Hirose (mhirose at mecse.mec.mei.co.jp)
Received: from cnri by ietf.org id aa04184; 26 Mar 97 4:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05361;
26 Mar 97 4:33 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <IAA01520 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 08:00:05 GMT
Message-Id: <333955E2.11B4 at frcl.bull.fr>
Date: Wed, 26 Mar 1997 08:59:14 -0800
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Reply-To: D.Pinkas at frcl.bull.fr
Organization: Bull
X-Mailer: Mozilla 3.0 (Win16; I)
Mime-Version: 1.0
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: SNEGO
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
I have revised the SNEGO draft to add the "optimistic" negotiation
proposed by Peter Brundrett. While doing this, I have taken a slightly
different option from the one proposed by Peter. This applies for the
response from the target.
If the optimistic negotiation succeeds and involves the transfer of a
mechanism specific token back to the initiator (e.g. mutual
authentication has been requested or the unilateral authentication
involves the transfer of multiple tokens) the proposal was to carry it
in the mechanism specific info. I believe it is more appropriate to
carry it separately in a different data structure: the initiator's
calling application may then extract directly the inner token and may
also extract the mechanism specific info (e.g. a chain of certificates)
in order to process that inner token. Look on page 6 at section 4.2 for
the structure of NegTokenRep.
NegTokenRep ::= SEQUENCE {
negResult [0] ENUMERATED { accept (0), reject (1) }
supportedMech [1] MechType OPTIONAL
MechSpecInfo [2] OCTET STRING OPTIONAL
preferredToken [3] OCTET STRING OPTIONAL
Denis
--
Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
Received: from ietf.org by ietf.org id aa20771; 26 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa18767; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kurz-virtual-lans-benefits-00.txt
Date: Wed, 26 Mar 1997 09:50:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18767 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Realizing the Benefits of Virtual LANs by Using IPv6
Author(s) : T. Kurz, J. Le Boudec, H. Einsiedler
Filename : draft-kurz-virtual-lans-benefits-00.txt
Pages : 13
Date : 03/25/1997
The benefits that Virtual LANs offer can be realized by using features of
an IPv6 network along with small enhancements the IPv6 and DHCPv6 protocol
stacks.
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-kurz-virtual-lans-benefits-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kurz-virtual-lans-benefits-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-kurz-virtual-lans-benefits-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: <19970325140117.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kurz-virtual-lans-benefits-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kurz-virtual-lans-benefits-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325140117.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20762; 26 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa19166; 26 Mar 97 9:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: www-security at nsmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-wts-shtml-03.txt
Date: Wed, 26 Mar 1997 09:51:20 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19166 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 Web Transaction Security
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Security Extensions For HTML
Author(s) : E. Rescorla, A. Schiffman
Filename : draft-ietf-wts-shtml-03.txt
Pages : 3
Date : 03/25/1997
This memo describes a syntax for embedding S-HTTP negotiation parameters in
HTML documents. S-HTTP as described by draft-ietf-wts-shttp-03.txt contains
the concept of negotation headers which reflect the potential receiver of a
message's preferences as to which cryptographic enhancements should be
applied to the message. This document describes a syntax for binding these
negotiation parameters to HTML anchors.
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-wts-shtml-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shtml-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-wts-shtml-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: <19970325161159.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-wts-shtml-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wts-shtml-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325161159.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20763; 26 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa19069; 26 Mar 97 9:51 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-eastlake-kitchen-sink-01.txt
Date: Wed, 26 Mar 1997 09:51:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19069 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Kitchen Sink Resource Record
Author(s) : D. Eastlake
Filename : draft-eastlake-kitchen-sink-01.txt
Pages : 9
Date : 03/25/1997
Periodically people are seized with a desire to put complex, bulky, and/or
obscurely structured data into the Domain Name System (DNS). This draft
defines a kitchen sink Resource Record that will satisfy this lust by
defining a new DNS resource record for the storage of miscellaneous
structured information. [Since the last version, tagged text items have
been added and minor updates and changes for consistency made.]
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-eastlake-kitchen-sink-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-kitchen-sink-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-eastlake-kitchen-sink-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: <19970325160528.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-eastlake-kitchen-sink-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-eastlake-kitchen-sink-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325160528.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20765; 26 Mar 97 9:56 EST
Received: from ietf.ietf.org by ietf.org id aa18462; 26 Mar 97 9:48 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-mailto-url-01.txt
Date: Wed, 26 Mar 1997 09:48:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260948.aa18462 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The mailto URL scheme
Author(s) : P. Hoffman, L. Masinter
Filename : draft-hoffman-mailto-url-01.txt
Pages : 4
Date : 03/25/1997
This document defines the format of Uniform Resource Locators (URL) for
designating electronic mail addresses. It is one of a suite of documents
which replace RFC 1738, "Uniform Resource Locators", and RFC 1808,
"Relative Uniform Resource Locators". The syntax of "mailto" URLs from RFC
1738 is extended to allow creation of more RFC 822 messages by allowing the
URL to express additional header and body fields.
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-mailto-url-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-mailto-url-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-hoffman-mailto-url-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: <19970325102844.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-mailto-url-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-mailto-url-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325102844.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21177; 26 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa19322; 26 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rps at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rps-transition-00.txt
Date: Wed, 26 Mar 1997 09:52:22 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260952.aa19322 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing Policy System
Working Group of the IETF.
Title : A strategy for the transition from RIPE-181 to RPSL
Author(s) : D. Kessens
Filename : draft-ietf-rps-transition-00.txt
Pages : 4
Date : 03/26/1997
This document describes a transition strategy for the Internet routing
registries from the RIPE181 [1] routing language to RPSL [2].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rps-transition-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rps-transition-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-rps-transition-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: <19970326091323.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rps-transition-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rps-transition-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326091323.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21178; 26 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa18545; 26 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-vendor-01.txt
Date: Wed, 26 Mar 1997 09:49:31 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260949.aa18545 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP Vendor Extensions
Author(s) : W. Simpson
Filename : draft-ietf-pppext-vendor-01.txt
Pages : 6
Date : 03/25/1997
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection; and a family of Network
Control Protocols (NCPs) for establishing and configuring different
network-layer protocols. This document defines a general mechanism for
proprietary vendor extensions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-vendor-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-vendor-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-vendor-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: <19970325105046.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-vendor-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-vendor-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325105046.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21248; 26 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa18627; 26 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-dns-rr-rgadd-00.txt
Date: Wed, 26 Mar 1997 09:49:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260949.aa18627 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 : Synthesis of Routing Goop and AAAA Records in IPv6
Author(s) : J. Bound
Filename : draft-ietf-ipngwg-dns-rr-rgadd-00.txt
Pages : 5
Date : 03/25/1997
This document is a proposal to redefine the existing DNS AAAA resource
record into two resource records: an RG record to define the routing
topology of an IPv6 address and an aAA record to define the End System
Identifier of an IPv6 address. The document will define the synthesis of
the RG and aAA record at the DNS primary server, which will return an AAAA
record to DNS resolvers. The objective of this work is to split the AAAA
record in the DNS into location and identifier to provide future
capabilities for dynamic renumbering of addresses. This work was spawned
by the GSE - Alternate Addressing Architecture Proposal for IPv6.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipngwg-dns-rr-rgadd-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-dns-rr-rgadd-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-dns-rr-rgadd-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: <19970325115137.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-dns-rr-rgadd-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-dns-rr-rgadd-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325115137.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab21248; 26 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa18875; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: srvloc at corp.home.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-svrloc-api-01.txt
Date: Wed, 26 Mar 1997 09:50:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18875 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Service Location Protocol
Working Group of the IETF.
Title : An API for Service Location
Author(s) : E. Guttman, D. Provan
Filename : draft-ietf-svrloc-api-01.txt
Pages : 36
Date : 03/25/1997
The Service Location Protocol coupled with the Service Location API provide
a new way for clients to dynamically discovery network services. It is
simple to offer highly available services which require no user
configuration or communication with network administrators prior to use.
The document includes examples and applications.
Client software modified to use Service Location can make very simple
requests to find service by type or by characteristic. The latter
capability allows the client to choose intelligently between services of
the same type. Service software modified to use Service Location may
dynamically advertise its characteristics and existence.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-svrloc-api-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-api-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-api-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970325135336.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-api-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-api-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325135336.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac21248; 26 Mar 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa18928; 26 Mar 97 9:50 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-idup-gss-07.txt
Date: Wed, 26 Mar 1997 09:49:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18928 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 : Independent Data Unit Protection Generic Security
Service Application Program Interface (IDUP-GSS-API)
Author(s) : C. Adams
Filename : draft-ietf-cat-idup-gss-07.txt
Pages : 58
Date : 03/25/1997
The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications requiring
protection of a generic data unit (such as a file or message) in a way
which is independent of the protection of any other data unit and
independent of any concurrent contact with designated "receivers" of the
data unit. Thus, it is suitable for applications such as secure electronic
mail where data needs to be protected without any on-line connection with
the intended recipient(s) of that data. The protection offered by IDUP
includes services such as data origin authentication with data integrity,
data confidentiality with data integrity, and support for non-repudiation
services. Subsequent to being protected, the data unit can be transferred
to the recipient(s) - or to an archive - perhaps to be processed
("unprotected") only days or years later.
Throughout the remainder of this document, the "unit" of data described in
the above paragraph will be referred to as an IDU (Independent Data Unit).
The IDU can be of any size (the application may, if it wishes, split the IDU
into pieces and have the protection computed a piece at a time,
but the resulting protection token applies to the entire IDU).
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-idup-gss-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-idup-gss-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-idup-gss-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970325115904.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-idup-gss-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-idup-gss-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325115904.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21713; 26 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa21619; 26 Mar 97 10:00 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ripv2-protocol-v2-02.txt
Date: Wed, 26 Mar 1997 10:00:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703261000.aa21619 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 RIP Version II Working Group
of the IETF.
Title : RIP Version 2 Carrying Additional Information
Author(s) : G. Malkin
Filename : draft-ietf-ripv2-protocol-v2-02.txt
Pages : 24
Date : 03/25/1997
This document specifies an extension of the Routing Information Protocol
(RIP), as defined in [1], to expand the amount of useful information
carried in RIP messages and to add a measure of security.
A companion document will define the SNMP MIB objects for RIP-2 [2]. An
additional document will define cryptographic security improvements for
RIP-2 [3].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ripv2-protocol-v2-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ripv2-protocol-v2-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-ripv2-protocol-v2-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: <19970325172821.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-protocol-v2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-protocol-v2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325172821.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22687; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18877; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-turner-ipp-trans-develop-00.txt
Date: Wed, 26 Mar 1997 09:50:42 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18877 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : HTTP 1.1 as a Transport for the
Internet Printing Protocol
Author(s) : R. Turner
Filename : draft-turner-ipp-trans-develop-00.txt
Pages : 18
Date : 03/25/1997
The definition of the Internet Printing Protocol (IPP) is specified
abstractly, and does not detail a particular implementation. The abstract
definition of IPP is contained within the "IPP Model" document, a separate
document available at the Printer Working Group IPP web page
HTTP://www.pwg.org/. This document attempts to map IPP Model operations and
semantics to HTTP 1.1 equivalent operations.
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-turner-ipp-trans-develop-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-turner-ipp-trans-develop-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-turner-ipp-trans-develop-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: <19970325154309.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-turner-ipp-trans-develop-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-turner-ipp-trans-develop-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325154309.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22674; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa19154; 26 Mar 97 9:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3ext-03.txt
Date: Wed, 26 Mar 1997 09:51:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19154 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 Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : Lightweight Directory Access Protocol: Extensions for
Dynamic Directory Services
Author(s) : Y. Yaacovi, M. Wahl, K. Settle, T. Genovese
Filename : draft-ietf-asid-ldapv3ext-03.txt
Pages : 8
Date : 03/25/1997
This document defines the requirements for dynamic directory services and
specifies the format of request and response extended operations for
supporting client-server interoperation in a dynamic directories
environment.
The Lightweight Directory Access Protocol (LDAP) [1] supports
lightweight access to static directory services, allowing
relatively fast search and update access. Static directory services store
information about people that persists in its accuracy and value over a
long period of time.
Dynamic directory services are different in
that they store information about people that only persists in its accuracy
and value when it is being periodically refreshed. This information is
stored as dynamic entries and/or dynamic attributes. A typical use will be
a client or a person that is either online - in which case it has an entry
or attributes in the directory, or is offline - in which case its entry or
attributes disappear from the directory. Though the protocol operations
and attributes used by dynamic directory services are similar to the ones
used for static directory services, clients that store dynamic information
in the directory need to periodically refresh this information,
in order to prevent it from disappearing. If dynamic entries or
attributes are not refreshed within a given timeout, they will be removed
from the directory. For example, this will happen if the client that
set them goes offline.
In addition, static directories may include dynamic information, in
the form of dynamic attributes in an otherwise static entry. Such
information needs to be refreshed periodically in the same manner.
A flow control mechanism from the server is also described that allows
a server to inform clients how often they should refresh their
presence.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3ext-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3ext-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-asid-ldapv3ext-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: <19970325165642.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3ext-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3ext-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325165642.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22664; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18804; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-engan-ipv6-hc-00.txt
Date: Wed, 26 Mar 1997 09:50:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18804 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Header Compression for IPv6 over PPP
Author(s) : M. Engan
Filename : draft-engan-ipv6-hc-00.txt
Pages : 7
Date : 03/25/1997
The Point-to-Point Protocol [RFC1548] provides a standard method of
encapsulating Network Layer protocol information over point-to-point links.
Header Compression for IPv6 [IPv6HC] is a method to compress IPv6 datagram
headers (any combination of IPv6, IPv4, TCP and UDP headers can be
compressed).
This document describes methods for transmission of datagrams with headers
compressed by IPv6 Header Compression over point-to-point links.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-engan-ipv6-hc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-engan-ipv6-hc-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-engan-ipv6-hc-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: <19970325144009.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-engan-ipv6-hc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-engan-ipv6-hc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325144009.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22690; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18563; 26 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-ipcp-mip-00.txt
Date: Wed, 26 Mar 1997 09:49:34 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260949.aa18563 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Mobile IPv4 Configuration Option for PPP IPCP
Author(s) : J. Solomon, S. Glass
Filename : draft-ietf-pppext-ipcp-mip-00.txt
Pages : 15
Date : 03/25/1997
Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile
Node can maintain existing transport and application-layer connections
despite changing its point-of-attachment to the Internet and without
changing its IP address. PPP [RFC 1661] provides a standard method for
transporting multi-protocol packets over point-to-point links. As
currently specified, Mobile IP Foreign Agents which support Mobile Node
connections via PPP can do so only by first assigning unique addresses to
those Mobile Nodes, defeating one of the primary advantages of Foreign
Agents. This documents corrects this problem by defining the Mobile IPv4
Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC
1332]. Using this option, two peers can communicate their support for
Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC
2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-ipcp-mip-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-mip-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-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: <19970325110838.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-ipcp-mip-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-ipcp-mip-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325110838.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22692; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18837; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-atm-imp-guide-00.txt, .ps
Date: Wed, 26 Mar 1997 09:50:34 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18837 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : RSVP over ATM Implementation Guidelines
Author(s) : L. Berger
Filename : draft-ietf-issll-atm-imp-guide-00.txt, .ps
Pages : 16
Date : 03/25/1997
This note presents specific implementation guidelines for running RSVP over
ATM switched virtual circuits (SVCs). It presents requirements and
specific guidelines for running over today's ATM networks. The general
problem is discussed in [5]. Integrated Services to ATM service mappings
are covered in [7]
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-atm-imp-guide-00.txt".
Or
"get draft-ietf-issll-atm-imp-guide-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-atm-imp-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-issll-atm-imp-guide-00.txt".
Or
"FILE /internet-drafts/draft-ietf-issll-atm-imp-guide-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: <19970325150613.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-atm-imp-guide-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-atm-imp-guide-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325150613.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22660; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa19192; 26 Mar 97 9:51 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-irtf-e2e-queue-mgt-00.txt, .ps
Date: Wed, 26 Mar 1997 09:51:56 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19192 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Recommendations on Queue Management and Congestion
Avoidance in the Internet
Author(s) : B. Braden, D. Clark, J. Crowcroft, B. Davie,
S. Deering, D. Estrin, S. Floyd, V. Jacobson,
G. Minshall, C. Partridge, L. Peterson,
K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang
Filename : draft-irtf-e2e-queue-mgt-00.txt, .ps
Pages : 16
Date : 03/25/1997
This memo presents two recommendations to the Internet community concerning
measures to improve and preserve Internet performance. It presents a
strong recommendation for testing, standardization, and widespread
deployment of active queue management in routers, to improve the
performance of today's Internet. It also urges a concerted effort of
research, measurement, and ultimate deployment of router mechanisms to
protect the Internet from flows that are not sufficiently responsive to
congestion notification.
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-irtf-e2e-queue-mgt-00.txt".
Or
"get draft-irtf-e2e-queue-mgt-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-irtf-e2e-queue-mgt-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-irtf-e2e-queue-mgt-00.txt".
Or
"FILE /internet-drafts/draft-irtf-e2e-queue-mgt-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: <19970325172015.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-irtf-e2e-queue-mgt-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-irtf-e2e-queue-mgt-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325172015.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22669; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18934; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: qosr at newbridge.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-qosr-framework-00.txt
Date: Wed, 26 Mar 1997 09:50:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18934 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 QoS Routing Working Group of
the IETF.
Title : A Framework for QoS-based Routing in the Internet
Author(s) : E. Crawley, R. Nair, B. Rajagopalan, H. Sandick
Filename : draft-ietf-qosr-framework-00.txt
Pages : 23
Date : 03/25/1997
QoS-based routing is being recognized as the missing piece in the evolution
of QoS-based service offerings in the Internet. This document describes
some of the QoS-based routing issues and proposes a framework for QoS-based
routing in the Internet.
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-qosr-framework-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-qosr-framework-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-qosr-framework-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: <19970325155157.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-qosr-framework-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-qosr-framework-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325155157.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22693; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa19048; 26 Mar 97 9:51 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-02.txt
Date: Wed, 26 Mar 1997 09:51:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19048 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-02.txt
Pages : 9
Date : 03/25/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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-servmib-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-radius-servmib-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: <19970325155725.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-servmib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-servmib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325155725.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22689; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18602; 26 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-gahrns-imap-practice-00.txt
Date: Wed, 26 Mar 1997 09:49:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260949.aa18602 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IMAP4 Implementation Practice
Author(s) : M. Gahrns
Filename : draft-gahrns-imap-practice-00.txt
Pages : 11
Date : 03/25/1997
IMAP4[rfc2060] is rich client/server protocol that allows a client to
access and manipulate electronic mail messages on a server. Within the
protocol framework, it is possible to have differing results for particular
client/server interactions. If a protocol does not allow for this, it is
often unduly restrictive.
For example, when multiple clients are accessing a mailbox and
one attempts to delete the mailbox, an IMAP4 server may choose
to implement a solution based upon server architectural
constraints or individual preference.
With this flexibility comes greater client responsibility.
It is not sufficient for a client to be written based upon the behavior
of a particular IMAP server. Rather the client must be based upon
the behavior allowed by the protocol.
By documenting common IMAP4 server practice for the case of simultaneous
client access to a mailbox, we hope to ensure the widest amount of
inter-operation between IMAP4 clients and 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-gahrns-imap-practice-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-gahrns-imap-practice-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-gahrns-imap-practice-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: <19970325112501.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-gahrns-imap-practice-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gahrns-imap-practice-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325112501.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22676; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18935; 26 Mar 97 9:50 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-call-01.txt
Date: Wed, 26 Mar 1997 09:50:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18935 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 : Terminology for Cell/Call Benchmarking
Author(s) : R. Craig
Filename : draft-ietf-bmwg-call-01.txt
Pages : 10
Date : 03/25/1997
The purpose of this draft is to add terminology specific to the cell and
call-based switch environment to that defined by the Benchmarking
Methodology Working Group (BMWG) of the Internet Engineering Task Force
(IETF) in RFC1242.
While primarily directed towards wide area switches, portions of the
document may be useful for benchmarking other devices such as ADSU's.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-bmwg-call-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-call-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-call-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: <19970325140340.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-bmwg-call-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bmwg-call-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325140340.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22694; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18583; 26 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-wessels-icp-v2-01.txt
Date: Wed, 26 Mar 1997 09:49:44 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260949.aa18583 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Cache Protocol (ICP), version 2
Author(s) : D. Wessels
Filename : draft-wessels-icp-v2-01.txt
Pages : 9
Date : 03/25/1997
This draft document describes the Internet Cache Protocol (ICP) as
currently implemented in a couple of World-Wide Web proxy cache packages.
ICP was initially developed by Peter Danzig, et. al. at the University of
Southern California. It evolved as an important part of hierarchical
caching on the Harvest research project.
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-wessels-icp-v2-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-wessels-icp-v2-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-wessels-icp-v2-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: <19970325111306.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-wessels-icp-v2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-wessels-icp-v2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325111306.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22695; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa19023; 26 Mar 97 9:51 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-01.txt
Date: Wed, 26 Mar 1997 09:51:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19023 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 Client MIB
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-radius-clientmib-01.txt
Pages : 9
Date : 03/25/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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-clientmib-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-clientmib-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: <19970325155513.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-clientmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-clientmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325155513.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22678; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa19242; 26 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dns-security 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-lewis-dnskey-handling-01.txt
Date: Wed, 26 Mar 1997 09:51:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260952.aa19242 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Zone KEY RRSet Signing Procedure
Author(s) : E. Lewis, O. Gudmundsson
Filename : draft-lewis-dnskey-handling-01.txt
Pages : 8
Date : 03/25/1997
Under the security extensions to DNS, as defined in RFC 2065 and
draft-ietf-dnssec-update-04.txt, a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. This document
covers the manner in which this RRSet is generated, signed, and inserted
into the name servers.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-lewis-dnskey-handling-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lewis-dnskey-handling-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-lewis-dnskey-handling-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: <19970325163027.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lewis-dnskey-handling-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lewis-dnskey-handling-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325163027.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22685; 26 Mar 97 10:13 EST
Received: from ietf.ietf.org by ietf.org id aa19136; 26 Mar 97 9:51 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-dusse-smime-cert-00.txt
Date: Wed, 26 Mar 1997 09:51:34 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19136 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : S/MIME Certificate Handling
Author(s) : S. Dusse, P. Hoffman, B. Ramsdell,
L. Lundblade, L. Repka
Filename : draft-dusse-smime-cert-00.txt
Pages : 12
Date : 03/25/1997
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a standard way to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an S/MIME
agent needs to certify that the key is valid. This draft describes the
mechanisms S/MIME uses to create and validate keys using certificates.
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-dusse-smime-cert-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dusse-smime-cert-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-dusse-smime-cert-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: <19970325165129.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dusse-smime-cert-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dusse-smime-cert-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325165129.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22691; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18626; 26 Mar 97 9:49 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-radius at livingston.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-radius-tunnel-auth-01.txt
Date: Wed, 26 Mar 1997 09:49:28 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260949.aa18626 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 Attributes for Tunnel Protocol Support
Author(s) : G. Zorn
Filename : draft-ietf-radius-tunnel-auth-01.txt
Pages : 9
Date : 03/25/1997
This document specifies a set of RADIUS attributes designed to support the
provision of mandatory tunneling in dial-up networks. RADIUS attributes
for both authorization and accounting are specified.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-radius-tunnel-auth-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-auth-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-radius-tunnel-auth-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: <19970325104804.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-radius-tunnel-auth-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-radius-tunnel-auth-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325104804.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22656; 26 Mar 97 10:12 EST
Received: from ietf.ietf.org by ietf.org id aa18703; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-suzuki-res-resv-svc-arch-01.txt
Date: Wed, 26 Mar 1997 09:50:04 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18703 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Architecture of the Resource Reservation Service
for the Commercial Internet
Author(s) : M. Suzuki
Filename : draft-suzuki-res-resv-svc-arch-01.txt
Pages : 17
Date : 03/25/1997
The purpose of this document is to clarify the architecture that should be
used for the resource reservation service for the commercial Internet.
First, this document explains the basis of the tariff for current
telecommunication and Internet services. Then it clarifies problems in the
billing for Internet service, and describes how billing can be improved by
using the resource reservation setup protocol. Finally, it also studies
technical and application models for a commercial resource reservation
service model, and clarifies an architecture for the resource reservation
setup 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-suzuki-res-resv-svc-arch-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-suzuki-res-resv-svc-arch-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-suzuki-res-resv-svc-arch-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970325133021.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-suzuki-res-resv-svc-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-suzuki-res-resv-svc-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325133021.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22630; 26 Mar 97 10:13 EST
Received: from ietf.ietf.org by ietf.org id aa19165; 26 Mar 97 9:51 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: www-security at nsmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-wts-shttp-04.txt
Date: Wed, 26 Mar 1997 09:51:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260951.aa19165 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 Web Transaction Security
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : The Secure HyperText Transfer Protocol
Author(s) : E. Rescorla, A. Schiffman
Filename : draft-ietf-wts-shttp-04.txt
Pages : 43
Date : 03/25/1997
This memo describes a syntax for securing messages sent using the Hypertext
Transfer Protocol (HTTP), which forms the basis for the World Wide Web.
Secure HTTP (S-HTTP) provides independently applicable security services
for transaction confidentiality, authenticity/integrity and
non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key management
mechanisms, security policies and cryptographic algorithms by supporting
option negotiation between parties for each transaction.
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-wts-shttp-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-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-wts-shttp-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: <19970325160847.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-wts-shttp-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wts-shttp-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325160847.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22667; 26 Mar 97 10:13 EST
Received: from ietf.ietf.org by ietf.org id aa19250; 26 Mar 97 9:52 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-nles-00.txt
Date: Wed, 26 Mar 1997 09:52:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260952.aa19250 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : Proposal for a PPP Network Layer Entity
Selection Protocol
Author(s) : A. Doria, X. Chen
Filename : draft-ietf-pppext-nles-00.txt
Pages : 7
Date : 03/26/1997
With the introduction of xDSL services into public telecommunications
networks, direct access (in contrast to dial-up access) will start to be
used as an access method for data as well as other services. PPP has
been very successful in providing connections for IP as well as other
protocols in the dial-up access network. With the advent of direct
access, changes will be need to be made for identifying the target hosts,
as it will no longer be possible to rely on the telephone number that is
dialed prior to initiating the PPP session. This proposal indicates one
method for adapting PPP to the new requirements.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-nles-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-nles-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-nles-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: <19970326091107.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-nles-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-nles-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326091107.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23130; 26 Mar 97 10:14 EST
Received: from ietf.ietf.org by ietf.org id aa18931; 26 Mar 97 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pier at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pier-applications-00.txt
Date: Wed, 26 Mar 1997 09:50:30 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703260950.aa18931 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 Procedures for
Internet/Enterprise Renumbering Working Group of the IETF.
Title : IP Addresses in Applications
Author(s) : P. Nesser
Filename : draft-ietf-pier-applications-00.txt
Pages : 5
Date : 03/25/1997
The Procedures for Internet/Enterprise Renumbering (PIER) Working Group of
the Internet Engineering Task Force (IETF) has been tasked with the
creation of documents to aid renumbering efforts. This document defines a
series of classes of IP address locations. Each class will be described in
a general sense, while specific examples are provided as possible.
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-pier-applications-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pier-applications-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-pier-applications-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: <19970325144722.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pier-applications-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pier-applications-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325144722.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23307; 26 Mar 97 10:16 EST
Received: from mail13.digital.com by ietf.org id aa20162; 26 Mar 97 9:54 EST
Received: from us1rmc.bb.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV)
id JAA05395; Wed, 26 Mar 1997 09:28:47 -0500 (EST)
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA13355; Wed, 26 Mar 97 09:28:31 -0500
Message-Id: <9703261428.AA13355 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 26 Mar 97 09:28:38 EST
Date: Wed, 26 Mar 97 09:28:38 EST
Sender:ietf-request at ietf.org
From: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 0920" <wray at tuxedo.enet.dec.com>
To: martin.rex at sap-ag.de
Cc: "cat-ietf at mit.edu"@in.enet.dec.com,
"ftp-wg at hops.ag.utk.edu"@in.enet.dec.com, "ietf at ietf.org"@in.enet.dec.com,
wray at tuxedo.enet.dec.com
Apparently-To: ietf at ietf.org, ftp-wg at hops.ag.utk.edu, cat-ietf at mit.edu,
martin.rex at sap-ag.de
Subject: Re: Comments on FTP Security Extensions draft
Source-Info: From (or Sender) name not authenticated.
Martin Rex wrote:
>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).
I think this depends on the intended audience. "Network Byte Order" has a
meaning that's specific to the particular network protocol family in use; in a
TCP/IP world, network byte order is big-endian, or most significant byte first.
RFC2078, the GSSAPI spec, is expressly designed to be independent of a
particular networking environment, and so that spec shouldn't use the term
"network byte order", because that term is meaningless outside the context of a
particular protocol family.
Since FTP is supposed to run only over TCP/IP, "network byte order" isn't
ambiguous. However, it might be clearer if it said something like "network
byte order (i.e. most significant byte first)".
John
Received: from ietf.org by ietf.org id aa25474; 26 Mar 97 10:56 EST
Received: from ietf.ietf.org by ietf.org id aa25238; 26 Mar 97 10:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bradner-isoc-incorp-00.txt
Date: Wed, 26 Mar 1997 10:53:44 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703261053.aa25238 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ARTICLES OF INCORPORATION OF INTERNET SOCIETY
Author(s) : ISOC Board of Trustees
Filename : draft-bradner-isoc-incorp-00.txt
Pages : 5
Date : 03/24/1997
These are the articles of incorporation of the Internet Society. They are
published for the information of the IETF community at the request of the
poisson working group.
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-bradner-isoc-incorp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bradner-isoc-incorp-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-bradner-isoc-incorp-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: <19970324142514.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bradner-isoc-incorp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bradner-isoc-incorp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970324142514.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25475; 26 Mar 97 10:56 EST
Received: from ietf.ietf.org by ietf.org id aa25254; 26 Mar 97 10:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bradner-isoc-by-laws-00.txt
Date: Wed, 26 Mar 1997 10:53:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703261053.aa25254 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Society By-Laws
Author(s) : ISOC Board of Trustees
Filename : draft-bradner-isoc-by-laws-00.txt
Pages : 9
Date : 03/25/1997
These are the by-laws of the Internet Society, as amended, as of June 1996.
They are published for the information of the IETF community at the request
of the poisson working group. Please refer to the ISOC web page
(www.isoc.org) for the current version of the by-laws.
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-bradner-isoc-by-laws-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bradner-isoc-by-laws-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-bradner-isoc-by-laws-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: <19970325092633.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bradner-isoc-by-laws-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bradner-isoc-by-laws-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970325092633.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa25722; 26 Mar 97 11:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12472;
26 Mar 97 11:03 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA13012 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 14:23:16 GMT
Message-Id: <9703261412.AA12165 at us1rmc.bb.dec.com>
Date: Wed, 26 Mar 97 09:12:43 EST
From: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 0858" <wray at tuxedo.enet.dec.com>
To: marc at cygnus.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at cygnus.com
Subject: Re: Name type issues
Precedence: bulk
Marc writes:
>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 believe this sentence has been there since we added the new rules for
determining default behavior. I think the reference to credentials being
undefined is needed, but this should indicate a mis-configured GSSAPI
implementation rather than an error that the GSSAPI application can attept to
recover from. The definitions of default initiator and default acceptor
behavior each have four possibilities, listed in order of preference, the last
being something like "otherwise a user-configurable default identity should be
used". The GSS_C_NO_CRED return is for the case where either a credential for
this identity doesn't exist, isn't accessible to the process, or the identity
itself hasn't been configured. For example, assume a Kerberos-like mechanism,
used in a role-oriented environment. A user may hold tickets for multiple
identities, one for each role, and the GSSAPI implementation may require that
he invoke a platform-specific operation to select the current role, prior to
running a GSSAPI application. If the user neglects to perform this role-select
operation, then GSSAPI has no way of knowing which identity to use, and in this
case GSS_C_NO_CRED seems to be the correct status to return.
I don't think this compromises portability across properly set-up GSSAPI
implementations, since it indicates a user or configuration error that can be
corrected (in a platform-specific way) and the operation re-tried.
John
Received: from ietf.org by ietf.org id aa28057; 26 Mar 97 11:38 EST
Received: from spinoza.terena.nl by ietf.org id aa27937; 26 Mar 97 11:35 EST
Received: from [192.87.30.51] (PaulsMac.terena.nl [192.87.30.51]) by spinoza.terena.nl (8.7.6/8.7.3) with SMTP id RAA19960; Wed, 26 Mar 1997 17:32:13 +0100 (MET)
X-Sender: paul at popper.terena.nl
Message-Id: <v02140b04af5eed0754c6 at [192.87.30.51]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 26 Mar 1997 17:37:01 +0200
To: terena-ga at terena.nl, wg-all at terena.nl, newsletters at terena.nl,
ceec at terena.nl, ietf at ietf.org, ccirn at fnc.gov, apng-all at apng.org,
jenc8-info at terena.nl, press at terena.nl, lhl at cs.wisc.edu
Sender:ietf-request at ietf.org
From: Paul Rendek <paul at terena.nl>
Subject: JENC8 Conference - Edinburgh, May 1997 - REMINDER
Source-Info: From (or Sender) name not authenticated.
* REMINDER *
"8th Joint European Networking Conference" (JENC8)
Edinburgh, Scotland, 12-15 May 1997
Please note that the date to benefit from 'early registration' fees
will end on 31 March 1997. A registration form can be found on the JENC8
Conference Web site at:
http://www.terena.nl/jenc8/
For conference registration enquiries please send an email to <jenc8 at ed.ac.uk>
For general enquiries please send an email to <jenc8-sec at TERENA.nl>
or contact:
TERENA Secretariat
Singel 466-468
NL - 1017 AW Amsterdam
The Netherlands
Tel: +31 20 639 1131
Fax: +31 20 639 3289
Email: jenc8-sec at TERENA.nl
Received: from cnri by ietf.org id aa00105; 26 Mar 97 12:19 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14133;
26 Mar 97 12:19 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA15344 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 15:24:11 GMT
Message-Id: <199703261524.KAA06972 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: Martin.Rex at sap-ag.de
Cc: Marc Horowitz <marc at cygnus.com>, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: default creds (was Re: name type issues)
In-Reply-To: Your message of "Tue, 25 Mar 1997 17:59:57 EST."
<199703252259.AA26855 at sap-ag.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 26 Mar 1997 10:24:06 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Re, excerpting:
> > 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?
> >From what I heard it looks for the "host/hostname at local.realm" principal
> if you ask for default accepting credentials. Application servers
> should in general not run with root privileges, and host credentials
> should not be readable by non-root processes. So if my assumption
> is correct, then Kerberos effectively supports only "portable system
> services", but not "portable applications".
>
RFC-2078, section 1.1.1.3, discusses recommended (though not required)
behavior for resolution of default credential references for both initiation
and acceptance. This text was adopted (per discussion; I'm not immediately
sure when) from a C bindings draft into one of the I-D versions which preceded
RFC-2078.
Do I hear a motion to mandate support for initiator default credentials
per this section? If so, would this conformance requirement be inconsistent
with any current implementations?
--jl
Received: from ietf.org by ietf.org id aa00680; 26 Mar 97 12:27 EST
Received: from alcor.Concordia.CA by ietf.org id aa00319; 26 Mar 97 12:23 EST
Received: from localhost (anne at localhost [127.0.0.1])
by alcor.concordia.ca (8.8.5/8.8.5) with SMTP id MAA18560
for ietf at ietf.org; Wed, 26 Mar 1997 12:19:36 -0500 (EST)
Message-Id: <199703261719.MAA18560 at alcor.concordia.ca>
X-Authentication-Warning: alcor.concordia.ca: anne at localhost [127.0.0.1] didn't use HELO protocol
To: ietf at ietf.org
Subject: Memphis hotel situation quite dire! (Seek female nonsmoking roomate)
Reply-To: Anne Bennett <anne at alcor.concordia.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Wed, 26 Mar 97 12:19:36 -0500
Sender:ietf-request at ietf.org
From: Anne Bennett <anne at alcor.concordia.ca>
X-Mts: smtp
Source-Info: From (or Sender) name not authenticated.
I'll be attending the IETF meeting in Memphis April 6 - 11, 1997; the
best I've found so far for a hotel room is La Quinta Inn Medical
Center, which is, I'm told, about 10 minutes away from the Peabody by
car (I have no wheels), and in a questionable area. :-(
Is there another non-smoking woman out there who has managed to get a
room closer to downtown and would be willing to share?
And is there nothing the meeting organizers can do to help? (Or is
there a standard location for roommate exchanges that I have been
unable to find?) I, a secretary, and a travel agent have been trying
for a few weeks now to find something better, and have been having no
luck. I realize that the hotel room block negotiatons were done well
in advance, and as a newsmaster, believe me when I say I understand
how hard it is to deal with exponential growth :-), but I think more
could be done to help the attendees find rooms.
Anne.
--
Ms. Anne Bennett, Computing Services, Concordia University, Montreal H3G 1M8
anne at alcor.concordia.ca (514) 848-7606
Received: from ietf.org by ietf.org id aa06461; 26 Mar 97 13:37 EST
Received: from postman.adn.alcatel.com by ietf.org id aa06144;
26 Mar 97 13:33 EST
Received: from by adn.alcatel.com with SMTP
(1.40.112.8/16.2) id AA186940981; Wed, 26 Mar 1997 13:29:42 -0500
Sender:ietf-request at ietf.org
From: Steve.Silverman at adn.alcatel.com
X-Openmail-Hops: 1
Date: Wed, 26 Mar 97 13:29:36 -0500
Message-Id: <H00004dc006c0d67 at MHS>
In-Reply-To: <199703261719.MAA18560 at alcor.concordia.ca>
Subject: Re: Memphis hotel situation - finding a hotel
Mime-Version: 1.0
To: anne at alcor.concordia.ca
Cc: ietf at ietf.org
Content-Type: text/plain; charset=US-ASCII; name="Re:"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Finding a hotel: If you go to www.lookupusa.com you can find 130
hotels, motels, and B&Bs in Memphis. Remember that Tennessee is TN.
There are several on Union Avenue. I assume you have tried the original
hotel and they couldn't recommend another hotel.
Good luck
Steve
>
> I'll be attending the IETF meeting in Memphis April 6 - 11, 1997; the
> best I've found so far for a hotel room is La Quinta Inn Medical
> Center, which is, I'm told, about 10 minutes away from the Peabody by
> car (I have no wheels), and in a questionable area. :-(
>
Received: from ietf.org by ietf.org id aa13077; 26 Mar 97 14:56 EST
Received: from ietf.ietf.org by ietf.org id aa12987; 26 Mar 97 14:55 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: IMAP4 IDLE command to Proposed Standard
Reply-to: iesg at ietf.org
Date: Wed, 26 Mar 1997 14:55:04 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9703261455.aa12987 at ietf.org>
The IESG has received a request to consider
<draft-leiba-imap-idle-01.txt> "IMAP4 IDLE command as a Proposed
Standard. This has been reviewed in the IETF but is not the product
of an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by April 26, 1997
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from cnri by ietf.org id aa17658; 26 Mar 97 16:00 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19555;
26 Mar 97 16:00 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA23412 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 18:43:53 GMT
Date: Wed, 26 Mar 1997 13:43:30 -0500
Message-Id: <9703261843.AA21708 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: marc at cygnus.com, cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Tue, 25 Mar 1997 17:59:57 -0500 (EST),
<199703252259.AA26855 at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Tue, 25 Mar 1997 17:59:57 -0500 (EST)
I can live without default accepting credentials; actually I thought
I have to -- or does Kerberos support default accepting credentials?
The MIT GSSAPI implementation does not. It's not clear what it would
mean, really.
>From what I heard it looks for the "host/hostname at local.realm" principal
if you ask for default accepting credentials. Application servers
should in general not run with root privileges, and host credentials
should not be readable by non-root processes. So if my assumption
is correct, then Kerberos effectively supports only "portable system
services", but not "portable applications".
Kerberos supports portable application by using the host/service
nametype. I believe that's the only really portable way to name
services --- is to use the host/service nametype on *both* the client
and server side.
- Ted
Received: from cnri by ietf.org id aa18973; 26 Mar 97 16:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20359;
26 Mar 97 16:33 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA21105 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 17:45:27 GMT
Message-Id: <199703261745.MAA17166 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com, mbeaulie at ietf.org
Subject: CAT WG Memphis agenda, DRAFT 2
Date: Wed, 26 Mar 1997 12:45:15 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
CAT WG Memphis agenda, DRAFT 2 as of 26 March 1997
Agenda topics for (single) Memphis CAT session, Tuesday, 8 April 1997,
1300-1500.
1300-1305: Opening discussion
1305-1315: Brian Tung: pkinit/pkcross
1315-1330: New Kerberos extension proposals
- Ari Medvinsky: discussion re draft-ietf-cat-pktapp-00.txt
- Matt Hur: discussion re draft-ietf-cat-kerberos-err-msg-00.txt
1330-1335: Bill Sommerfeld: Kerberos through firewalls
1335-1340: Marc Horowitz: draft-ietf-cat-kerb-chg-password-00.txt
1340-1350: Discussion (if needed) re FTPsec IETF Last-Call
1350-1400: Discussion (if needed) to reconcile/resolve SNEGO WG
Last-Call results
1400-1410: Follow-up and advancement plans for current RFCs:
- RFC-1510 [Kerberos], Cliff Neuman to present
- RFC-1964 [Kerberos V5 GSS-API Mechanism]
- RFC-2025 [SPKM]
- RFC-2078 [GSS-V2]
1410-1425: IDUP discussion
1425-1455: GSS-V2 / C Bindings discussion
1455-1500: Closing discussion
--jl
Received: from cnri by ietf.org id aa20142; 26 Mar 97 17:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21174;
26 Mar 97 17:02 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA24477 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 19:10:24 GMT
Date: Wed, 26 Mar 1997 14:10:17 -0500
Message-Id: <9703261910.AA21738 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 0858" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
In-Reply-To: John Wray, Digital DPE, 508/486-5210 26-Mar-1997 0858's message
of Wed, 26 Mar 97 09:12:43 EST, <9703261412.AA12165 at us1rmc.bb.dec.com>
Subject: Re: Name type issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
I don't believe the concept of "default acceptor" is really very useful.
The application client will still need to name the target in their call
to gss_init_sec_context(), using gss_import_name() and probably the
host/service name type. (After all, you can't default the target name
to gss_init_sec_context.)
Given that a portable application client has to be able to use
gss_import_name to name the target of a gss_init_sec_context, you might
as well have a portable application server use the same means of naming
itself.
The concept of a "default initiator" makes a lot more sense, though and
so I think all implementation should be required to support this
concept. I'm not so sure it would be useful to require implementation
to support a "default acceptor", since in the absence of any
specification of what that "default acceptor" is, a portable application
client won't be able to address that application server when it calls
gss_init_sec_context().
- Ted
Received: from cnri by ietf.org id aa21983; 26 Mar 97 17:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22515;
26 Mar 97 17:52 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA26337 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 19:53:00 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: Name type issues
References: <9703261412.AA12165 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 26 Mar 1997 14:52:42 -0500
In-Reply-To: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 0858"'s message of Wed, 26 Mar 97 09:12:43 EST
Message-Id: <t53sp1io2gl.fsf at rover.cygnus.com>
Lines: 28
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, 508/486-5210 26-Mar-1997 0858" <wray at tuxedo.ENET.dec.com> writes:
>> I believe this sentence has been there since we added the new rules
>> for determining default behavior. I think the reference to
>> credentials being undefined is needed, but this should indicate a
>> mis-configured GSSAPI implementation rather than an error that the
>> GSSAPI application can attept to recover from.
Perhaps this is just a wording problem. Certainly, it might be the
case that the credentials are not available (consider the simple case
where there is no kerberos ccache). However, this does not mean that
the default is not defined. For your role-select model, the default
is defined to be "whatever the role selection widget says". If the
role selection widget is unspecified, then this is not a definition
problem, but an availability problem.
In other words, to me, "defined" is something a specification or
implementation does, not something a user or administrator does.
>> I don't think this compromises portability across properly set-up
>> GSSAPI implementations, since it indicates a user or configuration
>> error that can be corrected (in a platform-specific way) and the
>> operation re-tried.
As you describe it, I agree, but I would still like to see the wording
changed.
Marc
Received: from cnri by ietf.org id aa22768; 26 Mar 97 18:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23025;
26 Mar 97 18:15 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA26869 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 20:04:53 GMT
Message-Id: <9703261953.AA08996 at us1rmc.bb.dec.com>
Date: Wed, 26 Mar 97 14:53:32 EST
From: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 1434" <wray at tuxedo.enet.dec.com>
To: tytso at mit.edu
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, tytso at MIT.EDU
Subject: Re: Name type issues
Precedence: bulk
Ted writes:
>I don't believe the concept of "default acceptor" is really very useful.
>The application client will still need to name the target in their call
>to gss_init_sec_context(), using gss_import_name() and probably the
>host/service name type. (After all, you can't default the target name
>to gss_init_sec_context.)
>
>Given that a portable application client has to be able to use
>gss_import_name to name the target of a gss_init_sec_context, you might
>as well have a portable application server use the same means of naming
>itself.
>
>The concept of a "default initiator" makes a lot more sense, though and
>so I think all implementation should be required to support this
>concept. I'm not so sure it would be useful to require implementation
>to support a "default acceptor", since in the absence of any
>specification of what that "default acceptor" is, a portable application
>client won't be able to address that application server when it calls
>gss_init_sec_context().
The default acceptor is completely analagous to default initiator - they're
both identities that are assumed (by server and client respectively) in the
absence of explicitly requested identities, and are expected to be set-up
outside GSSAPI by some platform-specific means.
One way that a client might obtain a server's principal name might be by
prompting the user for it. That option isn't available to the server (because
there usually isn't a user to ask).
Also, neither GSSAPI nor the application necessarily have to be able to
determine ahead of time what the acceptor identity is. The second option
allowed by the spec for determining acceptor behavior is for GSSAPI (or the
mechanism) to look at the incoming context establishment token, and then see if
it can use that identity.
If we're going to require default initiator (and I think we should), I don't
see why we can't also mandate support of a default acceptor. The final option
("otherwise a user-configurable default identity shall be used") allows for the
very low-cost method of having a configuration-file that GSSAPI can use to
determine what the default identity is, so it's certainly not onerous on
implementors to support this.
John
Received: from cnri by ietf.org id aa23637; 26 Mar 97 18:36 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23474;
26 Mar 97 18:36 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA27934 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 20:34:27 GMT
Message-Id: <199703262034.AA02161 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Wed, 26 Mar 1997 15:33:53 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703261843.AA21708 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 26, 97 01:43:30 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Tue, 25 Mar 1997 17:59:57 -0500 (EST)
>
> I can live without default accepting credentials; actually I thought
> I have to -- or does Kerberos support default accepting credentials?
>
> The MIT GSSAPI implementation does not. It's not clear what it would
> mean, really.
>
> >From what I heard it looks for the "host/hostname at local.realm" principal
> if you ask for default accepting credentials. Application servers
> should in general not run with root privileges, and host credentials
> should not be readable by non-root processes. So if my assumption
> is correct, then Kerberos effectively supports only "portable system
> services", but not "portable applications".
>
> Kerberos supports portable application by using the host/service
> nametype. I believe that's the only really portable way to name
> services --- is to use the host/service nametype on *both* the client
> and server side.
I do *not* agree.
The hostbased service name is not really portable. When an application
does not use hostnames to open the transport connection, e.g. because it
manages multiple-firewall-traversal transparently within its
transport layer, then hostbased service names no longer work.
I know that regular Kerberos doesn't work in this environment,
because it isn't able to traverse any firewalls, but by using public key
based mechanisms (or abusing Kerberos in "reverse operation") firewall
traversel is possible.
The concept of hostbased service name is that it assumes that
(1) a service lives on a single host only, and that (2) you know the
hostname where it lives, and that (3) you know it already when you try
to initiate the security context. (1) is a problem in the regular
IP-world already, where some people have implemented load-balancing
between machines via DNS, by defining a "service name" in the DNS
and mapping it to several different hosts (ip-addresses).
(2) is a problem where you don't have or don't use direct IP-connectivity
or a custom transport layer.
The preference of Kerberos for hostbased service names is (a) historic
and (b) required when using authenticators+replay cache for replay
detection. (DNS-)Hostbased service names are IP-world-specific,
they're not transport independent.
-Martin
Received: from ietf.org by ietf.org id aa23853; 26 Mar 97 18:44 EST
Received: from zephyr.isi.edu by ietf.org id aa23724; 26 Mar 97 18:42 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA07603>; Wed, 26 Mar 1997 15:39:20 -0800
Message-Id: <199703262339.AA07603 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: BCP 14, RFC 2119 on RFC Key Words
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 26 Mar 97 15:39:20 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
BCP 14:
RFC 2119:
Title: Key words for use in RFCs to Indicate
Requirement Level
Author: S. Bradner
Date: March 1997
Mailbox: sob at harvard.edu
Pages: 3
Characters: 4723
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2119.txt
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <970326140847.RFC at ISI.EDU>
SEND /rfc/rfc2119.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2119.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970326140847.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa24156; 26 Mar 97 18:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23869;
26 Mar 97 18:52 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <VAA29177 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 21:05:06 GMT
Date: Wed, 26 Mar 1997 16:04:59 -0500
Message-Id: <9703262104.AA21845 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 1434" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
In-Reply-To: John Wray, Digital DPE, 508/486-5210 26-Mar-1997 1434's message
of Wed, 26 Mar 97 14:53:32 EST, <9703261953.AA08996 at us1rmc.bb.dec.com>
Subject: Re: Name type issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Wed, 26 Mar 97 14:53:32 EST
From: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 1434" <wray at tuxedo.ENET.dec.com>
If we're going to require default initiator (and I think we should),
I don't see why we can't also mandate support of a default acceptor.
The final option ("otherwise a user-configurable default identity
shall be used") allows for the very low-cost method of having a
configuration-file that GSSAPI can use to determine what the default
identity is, so it's certainly not onerous on implementors to support
this.
... and what error should the GSSAPI system return if the configuration
file isn't present? I'm somewhat nervous about assuming the existence
of a configuration file; Kerberos might have one, but not all mechanism
implementation may.
This may also encourage application programmers to assume that the
configuration file will take care of things for them. Which may be fine
if you only need to run one application on a host, but what if you need
to run multiple applications on the same host with different identities,
and you only have one configuration file?
- Ted
Received: from ietf.org by ietf.org id aa24277; 26 Mar 97 18:57 EST
Received: from koobera.math.uic.edu by ietf.org id aa23983; 26 Mar 97 18:49 EST
Received: (qmail 22621 invoked by uid 666); 26 Mar 1997 23:53:37 -0000
Date: 26 Mar 1997 23:53:36 -0000
Message-ID: <19970326235336.22619.qmail at koobera.math.uic.edu>
Sender:ietf-request at ietf.org
From: "D. J. Bernstein" <djb at koobera.math.uic.edu>
To: ietf at ietf.org
Subject: announcing list-protection list
Source-Info: From (or Sender) name not authenticated.
I've created a mailing list, djb-list-protection at koobera.math.uic.edu,
to discuss attacks against mailing lists and mailing list subscribers,
and to discuss methods of protecting against attacks. To subscribe, send
a message to
djb-list-protection-subscribe at koobera.math.uic.edu
---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html
Received: from cnri by ietf.org id aa25634; 26 Mar 97 19:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24643;
26 Mar 97 19:39 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA01745 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 22:06:15 GMT
Date: Wed, 26 Mar 1997 17:06:03 -0500
Message-Id: <9703262206.AA21858 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Wed, 26 Mar 1997 15:33:53 -0500 (EST),
<199703262034.AA02161 at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Wed, 26 Mar 1997 15:33:53 -0500 (EST)
I do *not* agree.
The hostbased service name is not really portable. When an application
does not use hostnames to open the transport connection, e.g. because it
manages multiple-firewall-traversal transparently within its
transport layer, then hostbased service names no longer work.
I know that regular Kerberos doesn't work in this environment,
because it isn't able to traverse any firewalls, but by using public key
based mechanisms (or abusing Kerberos in "reverse operation") firewall
traversel is possible.
Well, except for the hostbased service name, we don't have anything else
to recommend to applications developers!
As can punt the issue on the application server side, but what do you
use on the application client side? Prompting the user for an Object
Identifier and name is not particularly user friendly, and isn't
particularly a good way to get people to adopt this technology.
- Ted
Received: from cnri by ietf.org id aa27165; 26 Mar 97 20:55 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25909;
26 Mar 97 20:55 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA02866 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 22:40:06 GMT
To: cat-ietf at mit.edu
Subject: gss_accept_sec_context and gss_display_status
From: Marc Horowitz <marc at cygnus.com>
Date: 26 Mar 1997 17:39:59 -0500
Message-Id: <t53g1xiz39c.fsf at rover.cygnus.com>
Lines: 36
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
RFC2078 says:
The mech_type return value indicates the specific mechanism employed
on the context, is valid only along with major_status GSS_S_COMPLETE,
and will never indicate the value for "default".
So, if gss_accept_sec_context returns an error, it is impossible to
portably determine the mech oid to pass to gss_display_status to
convert the minor status into a usable form. This seems like a bug.
A multimechanism acceptor will determine the mechanism from the mech
oid included in first initiator token. It would be possible and
desirable for the gssapi to require mechanism implementations to
return an oid in the mech_name output after each call, not just with
GSS_S_COMPLETE.
For the benefit of negotiation mechanisms, we could allow this output
to change, reflecting the mechanism which generated the minor status
code. When GSS_S_COMPLETE is returned, the mech_type would identify
the mechanism which was negotiated, completed, and is to be used for
per-message protection.
If the the mech oid is unknown, then GSS_S_BAD_MECH is returned:
o GSS_S_BAD_MECH indicates receipt of a context establishment token
specifying a mechanism unsupported by the local system or with
the caller's active credentials.
Since this implies that there is no mechanism, the concept of a
mechanism-specific minor status is meaningless. The mechanism must
return a zero minor status code, and the application should ignore the
minor status code.
Comments?
Marc
Received: from cnri by ietf.org id aa27243; 26 Mar 97 21:03 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26050;
26 Mar 97 21:03 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA04464 at pad-thai.cam.ov.com>; Wed, 26 Mar 1997 23:24:52 GMT
Message-Id: <199703262324.AA12632 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Wed, 26 Mar 1997 18:24:31 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703262206.AA21858 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 26, 97 05:06:03 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
>
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Wed, 26 Mar 1997 15:33:53 -0500 (EST)
>
> I do *not* agree.
>
> The hostbased service name is not really portable. When an application
> does not use hostnames to open the transport connection, e.g. because it
> manages multiple-firewall-traversal transparently within its
> transport layer, then hostbased service names no longer work.
>
> I know that regular Kerberos doesn't work in this environment,
> because it isn't able to traverse any firewalls, but by using public key
> based mechanisms (or abusing Kerberos in "reverse operation") firewall
> traversel is possible.
>
> Well, except for the hostbased service name, we don't have anything else
> to recommend to applications developers!
That's why I was asking for one. GSS_C_NO_OID seems to be unusable
according to arbitrary implementation practice within the same mechanism.
The original idea behind GSS_C_NO_OID was to use the "native" name
format of the mechanism. And all mechanisms that existed before GSS-API
or that have other Interface additionally to GSS-API don't use
GSS-API nametypes. Still the administrator is able to create entries in
the Principal / Subject database. Some applications will be logging
authenticated clients, and in distributed systems you will see both,
users as well as servers in the log file and the name will very probably
be shown in a unified canonical form.
Nametype OIDs are a GSS-API invention, and with the current definition,
I doubt that they appear anywhere in the administration of the security
systems. So if administrators and users are able to talk with their
software about names without mentioning nametypes for administration
and single sign-on, it should also be possible for the user to talk with
this software through an application and a gssapi interface.
To my understanding, that's what GSS_C_NO_OID was for and Sesame
and DCE apparently do The Right Thing.
>
> As can punt the issue on the application server side, but what do you
> use on the application client side? Prompting the user for an Object
> Identifier and name is not particularly user friendly, and isn't
> particularly a good way to get people to adopt this technology.
I don't want to require hostnames, I don't want to see nametype OIDs.
A user will normally want to simply use a "service". A novice user
will get everything preconfigured by his administrator and only see
an icon to click on.
As an application provider, I'd really like to save the administrators
and users from having to configure *ANY* nametypes. I do accept the
currently defined "generic" nametypes, but from the discussion on
the list I have to conclude that they're not really useful:
USERNAME, MACHINE_UID, STRING_UID are apparently not supposed to
work on platforms that do not know or distinguish users,
HOSTBASED_SERVICE_NAME do not work for applications that don't
use hostnames to set up transport connections and they don't
work for mechanisms that use a completely different service naming
Personally, I'd either like to see all mechanisms use their native
name format for import_name( name_type=GSS_C_NO_OID ) for gssapi v2,
or a new explicit generic nametype which indicates "the mechanisms
native name format".
-Martin
Received: from cnri by ietf.org id aa29973; 26 Mar 97 22:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa27887;
26 Mar 97 22:52 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <CAA10178 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 02:03:34 GMT
To: Martin.Rex at sap-ag.de
Cc: "Theodore Y. Ts'o" <tytso at mit.edu>, cat-ietf at mit.edu
Subject: Re: default creds (was Re: name type issues)
References: <199703262324.AA12632 at sap-ag.de>
From: Marc H <marc at cygnus.com>
Date: 26 Mar 1997 21:03:18 -0500
In-Reply-To: Martin Rex's message of Wed, 26 Mar 1997 18:24:31 -0500 (EST)
Message-Id: <t53sp1im6qh.fsf at rover.cygnus.com>
Lines: 24
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
Martin Rex <martin.rex at sap-ag.de> writes:
>> As an application provider, I'd really like to save the administrators
>> and users from having to configure *ANY* nametypes. I do accept the
>> currently defined "generic" nametypes, but from the discussion on
>> the list I have to conclude that they're not really useful:
I think it is simply asking too much to expect to be able to isolate
the administrators from having to configure name types.
Perhaps we should have an interface to convert from a human-readable
form (like "hostbased_service_name") to an oid. This would make
configuration less obscure, since you could at least isolate the
administrator from OIDs.
>> Personally, I'd either like to see all mechanisms use their native
>> name format for import_name( name_type=GSS_C_NO_OID ) for gssapi v2,
>> or a new explicit generic nametype which indicates "the mechanisms
>> native name format".
I don't think that "native name format" necessarily has a single
distinguished meaning for every mechanism.
Marc
Received: from ietf.org by ietf.org id aa11032; 27 Mar 97 7:21 EST
Received: from wf10.wfa.digital.ie by ietf.org id aa10712; 27 Mar 97 7:10 EST
Received: by gateway.wfa.digital.ie; (8.7.3/1.3/10May95) id NAA27045; Thu, 27 Mar 1997 13:20:44 GMT
Sender:ietf-request at ietf.org
From: Dermot Tynan <dtynan at wfa.digital.ie>
Message-Id: <9703271208.AA04815 at karpov.wfa.digital.ie>
Subject: Re: Memphis hotel situation quite dire!
To: ietf at ietf.org
Date: Thu, 27 Mar 1997 12:08:12 +0000 (GMT)
In-Reply-To: <199703261719.MAA18560 at alcor.concordia.ca> from "Anne Bennett" at Mar 26, 97 12:19:36 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Anne Bennett wrote:
>
> I, a secretary, and a travel agent have been trying
> for a few weeks now to find something better, and have been having no
> luck.
All this talk of availability of rooms at the Memphis Peabody is making
me extremely nervous. Long after this discussion started, I got
clearance to travel to IETF, and AmEx Travel Services got me a room at
the Memphis Peabody without any difficulty. Why do I have this awful
feeling that I'm booked into the wrong hotel, or that after zillions
of hours of travelling, the desk clerk will look at me strangely and
claim to have never heard of me. How many "Memphis Peabody" hotels
are there? Should I be worried??
- Der
--
Dermot Tynan +353 91 754608
dtynan at wfa.digital.ie DTN: 822-4608
AltaVista Internet Software, Galway, Ireland
Received: from ietf.org by ietf.org id aa12961; 27 Mar 97 8:38 EST
Received: from callandor.cybercash.com by ietf.org id aa12872;
27 Mar 97 8:34 EST
Received: by callandor.cybercash.com; id IAA12430; Thu, 27 Mar 1997 08:24:11 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma012382; Thu, 27 Mar 97 08:23:32 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA07581; Thu, 27 Mar 97 08:27:16 EST
Date: Thu, 27 Mar 1997 08:27:15 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Dermot Tynan <dtynan at wfa.digital.ie>
Cc: ietf at ietf.org
Subject: Re: Memphis hotel situation quite dire!
In-Reply-To: <9703271208.AA04815 at karpov.wfa.digital.ie>
Message-Id: <Pine.SUN.3.91.970327082146.7346C-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Thre is only one Memphis Peabody hotel and if you have a reservation
guarnateed on an American Express card, I would not worry. Should the
hotel be full when you get there (always possible since in every US
state except Hawaii hotel guests can just stay longer and it would take
weeks to get an evication order from a local court) it will be their
responsibility to find alternative accomodations for you. AmEx is quite
tough on hotels if they fail to live up to this obligation.
Donald
On Thu, 27 Mar 1997, Dermot Tynan wrote:
> Date: Thu, 27 Mar 1997 12:08:12 +0000 (GMT)
> From: Dermot Tynan <dtynan at wfa.digital.ie>
> To: ietf at ietf.org
> Subject: Re: Memphis hotel situation quite dire!
>
> Anne Bennett wrote:
> >
> > I, a secretary, and a travel agent have been trying
> > for a few weeks now to find something better, and have been having no
> > luck.
>
> All this talk of availability of rooms at the Memphis Peabody is making
> me extremely nervous. Long after this discussion started, I got
> clearance to travel to IETF, and AmEx Travel Services got me a room at
> the Memphis Peabody without any difficulty. Why do I have this awful
> feeling that I'm booked into the wrong hotel, or that after zillions
> of hours of travelling, the desk clerk will look at me strangely and
> claim to have never heard of me. How many "Memphis Peabody" hotels
> are there? Should I be worried??
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>
> AltaVista Internet Software, Galway, Ireland
>
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
Received: from ietf.org by ietf.org id aa14281; 27 Mar 97 9:02 EST
Received: from dfw-ix9.ix.netcom.com by ietf.org id aa14106; 27 Mar 97 9:01 EST
Received: (from smap at localhost)
by dfw-ix9.ix.netcom.com (8.8.4/8.8.4)
id HAA02524 for <ietf at ietf.org>; Thu, 27 Mar 1997 07:58:37 -0600 (CST)
Received: from aus-tx4-16.ix.netcom.com(199.35.201.144) by dfw-ix9.ix.netcom.com via smap (V1.3)
id sma002509; Thu Mar 27 07:58:16 1997
Message-ID: <3339D413.7F2E at acm.org>
Date: Wed, 26 Mar 1997 19:57:39 -0600
Sender:ietf-request at ietf.org
From: Ken Copeland <kcopelan at acm.org>
Organization: personal mailbox
X-Mailer: Mozilla 4.0b2 (Win95; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Re: Memphis hotel situation quite dire!
X-Priority: 3 (Normal)
References: <Pine.SUN.3.91.970327082146.7346C-100000 at cybercash.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by dfw-ix9.ix.netcom.com id HAA02524
Source-Info: From (or Sender) name not authenticated.
<HTML><BODY>
Donald E. Eastlake 3rd wrote:
<BLOCKQUOTE TYPE=3DCITE>Thre is only one Memphis Peabody hotel and if you
have a reservation
<BR>guarnateed on an American Express card, I would not worry. Shou=
ld
the
<BR>hotel be full when you get there (always possible since in every US
<BR>state except Hawaii hotel guests can just stay longer and it would ta=
ke
<BR>weeks to get an evication order from a local court) it will be their
<BR>responsibility to find alternative accomodations for you. AmEx =
is
quite
<BR>tough on hotels if they fail to live up to this obligation.
<BR>
<BR>Donald
<BR>
<BR>On Thu, 27 Mar 1997, Dermot Tynan wrote:
<BR>
<BR><I>> Date: Thu, 27 Mar 1997 12:08:12 +0000 (GMT)</I>
<BR><I>> From: Dermot Tynan <dtynan at wfa.digital.ie></I>
<BR><I>> To: ietf at ietf.org</I>
<BR><I>> Subject: Re: Memphis hotel situation quite dire!</I>
<BR><I>></I>
<BR><I>> Anne Bennett wrote:</I>
<BR><I>> ></I>
<BR><I>> > I, a secretary, and a travel agent have been trying</I>
<BR><I>> > for a few weeks now to find something better, and have b=
een
having no</I>
<BR><I>> > luck.</I>
<BR><I>></I>
<BR><I>> All this talk of availability of rooms at the Memphis Peabody=
is
making</I>
<BR><I>> me extremely nervous. Long after this discussion starte=
d,
I got</I>
<BR><I>> clearance to travel to IETF, and AmEx Travel Services got me =
a
room at</I>
<BR><I>> the Memphis Peabody without any difficulty. Why do I ha=
ve
this awful</I>
<BR><I>> feeling that I'm booked into the wrong hotel, or that after z=
illions</I>
<BR><I>> of hours of travelling, the desk clerk will look at me strang=
ely
and</I>
<BR><I>> claim to have never heard of me. How many "Memphis=
Peabody"
hotels</I>
<BR><I>> are there? Should I be worried??</I>
</BLOCKQUOTE>
I made a reservation for the Memphis Peabody on 12/17 and have a confirma=
tion
number. At the time I made the reservation I guaranteed with an American
Express card. I=A0called back recently to see if they had government rate=
s
available. I was told they had a computer malfunction in December and tha=
t
my reservation was lost. They did offer me an exorbitant rate for 2 night=
s
though.
<BR>
<BR>I ended up making reservations at the Hampton Inn at 1180 Union Ave. =
(901-276-1175).
I had to also get a rental car, but the combination of the 2 was cheaper
than the conference rate at the Memphis Peabody.
<BR>
<BR>If anyone else decides to stay at the Hampton Inn on Union, they are =
welcome
to ride back and forth with me when I come and go. I=A0will be checking i=
n
Sunday and leaving Friday. - ken
<BR>--
<BR>Ken Copeland--------------------Senior Computer Systems Analyst
<BR>email: kcopelan at acm.org--------U.S. Department of Veterans Affa=
irs
<BR>phone: 512-326-6607------------1615 Woodward Street, MC (91D)&n=
bsp;
<BR>fax: 512-326-7445--------------Austin, TX 78772
<BR>homepage: <A HREF=3D"http://www.geocities.com/CollegePark/6627";>http:=
//www.geocities.com/CollegePark/6627</A>
<BR>
</BODY>
</HTML>
Received: from ietf.org by ietf.org id aa14488; 27 Mar 97 9:06 EST
Received: from socks1.raleigh.ibm.com by ietf.org id aa14420; 27 Mar 97 9:05 EST
Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0)
id AA22154; Thu, 27 Mar 1997 09:02:29 -0500
Received: from lankeeper.raleigh.ibm.com (lankeeper.raleigh.ibm.com [9.37.234.115]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA38494; Thu, 27 Mar 1997 09:02:31 -0500
Received: from socks6.raleigh.ibm.com by lankeeper.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL)
id AA07923; Thu, 27 Mar 1997 09:03:31 -0500
Message-Id: <333A7D5E.22F2 at raleigh.ibm.com>
Date: Thu, 27 Mar 1997 08:59:58 -0500
Sender:ietf-request at ietf.org
From: "W. Mark Townsley" <wmt at raleigh.ibm.com>
Reply-To: wmt at raleigh.ibm.com
Organization: IBM
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Mime-Version: 1.0
To: Dermot Tynan <dtynan at wfa.digital.ie>
Cc: ietf at ietf.org
Subject: Re: Memphis hotel situation quite dire!
References: <9703271208.AA04815 at karpov.wfa.digital.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Dermot Tynan wrote:
>
> Anne Bennett wrote:
> >
> > I, a secretary, and a travel agent have been trying
> > for a few weeks now to find something better, and have been having no
> > luck.
>
> All this talk of availability of rooms at the Memphis Peabody is making
> me extremely nervous. Long after this discussion started, I got
> clearance to travel to IETF, and AmEx Travel Services got me a room at
> the Memphis Peabody without any difficulty. Why do I have this awful
> feeling that I'm booked into the wrong hotel, or that after zillions
> of hours of travelling, the desk clerk will look at me strangely and
> claim to have never heard of me. How many "Memphis Peabody" hotels
There are more than one, when I referred to the "Peabody" making my
reservations, I was asked "which Peabody" (I believe there is a
second on the East side of Memphis). You might want to call back and
confirm with AmEx, or better yet call the Hotel directly.
> are there? Should I be worried??
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>
> AltaVista Internet Software, Galway, Ireland
--
W. Mark Townsley Email: wmt at raleigh.ibm.com
Remote Access Software Development Phone: (919) 543-7522
IBM Networking Division Fax: (919) 543-7378
http://cave.raleigh.ibm.com (Internal Only)
Received: from ietf.org by ietf.org id aa19651; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17219; 27 Mar 97 9:54 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-kerberos-err-msg-00.txt
Date: Thu, 27 Mar 1997 09:54:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17219 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : Integrity Protection for the Kerberos Error Message
Author(s) : A. Medvinsky, M. Hur, D. Brezinski,
G. Tsudik, B. Tung
Filename : draft-ietf-cat-kerberos-err-msg-00.txt
Pages : 4
Date : 03/26/1997
The Kerberos error message, as defined in RFC 1510, is transmitted to the
client without any integrity assurance. Therefore, the client has no means
to distinguish between a valid error message sent from the KDC and one sent
by an attacker. This draft describes a method for assuring the integrity
of Kerberos error messages, and proposes a consistent format for the e-data
field in the KRB_ERROR message. This e-data format enables the storage of
cryptographic checksums by providing an extensible mechanism for specifying
e-data types.
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-kerberos-err-msg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerberos-err-msg-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-kerberos-err-msg-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: <19970326114005.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-kerberos-err-msg-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-kerberos-err-msg-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326114005.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20024; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18218; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-thayer-cipher-00.txt
Date: Thu, 27 Mar 1997 09:56:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa18218 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Stream Cipher Encryption Algorithm
Author(s) : R. Thayer
Filename : draft-thayer-cipher-00.txt
Pages : 8
Date : 03/26/1997
There is a need in the Internet community for an encryption algorithm that
provides interoperable operation with existing deployed commercial
cryptographic applications. This interoperability will allow for a
smoother transition to protocols that have been developed through the IETF
standards process. This document describes an existing algorithm that
satisifies this requirement.
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-cipher-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thayer-cipher-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-thayer-cipher-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: <19970326140606.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thayer-cipher-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thayer-cipher-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326140606.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20026; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17502; 27 Mar 97 9:55 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-connection-00.txt
Date: Thu, 27 Mar 1997 09:55:26 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17502 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : HTTP Connection Management
Author(s) : J. Gettys, A. Freier
Filename : draft-ietf-http-connection-00.txt
Pages : 13
Date : 03/26/1997
The HTTP/1.1 specification (RFC 2068) is silent about various details of
TCP connection management when using persistent connections. This document
discusses some of the implementation issues discussed during HTTP/1.1's
design, and introduces a few new requirements on HTTP/1.1 implementations
learned from implementation experience, not fully understood when RFC 2068
was issued. This is an initial draft for working group comment, and we
expect further drafts.
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-connection-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-connection-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-connection-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: <19970326120318.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-connection-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-connection-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326120318.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab19651; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17701; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mboned at ns.uoregon.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mboned-mdh-00.txt
Date: Thu, 27 Mar 1997 09:55:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17701 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 MBONE Deployment Working
Group of the IETF.
Title : Multicast Debugging Handbook
Author(s) : D. Thaler, B. Aboba
Filename : draft-ietf-mboned-mdh-00.txt
Pages : 30
Date : 03/26/1997
This document serves as a handbook for the debugging of multicast
connectivity problems. In addition to reviewing commonly encountered
problems, the draft summarizes publicly distributable multicast dianostic
tools, and provides examples of their use, along with pointers to source
and binary distributions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-mdh-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-mdh-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-mboned-mdh-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: <19970326125754.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-mdh-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-mdh-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326125754.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20025; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17383; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ssh at clinet.fi
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-secsh-userauth-00.txt
Date: Thu, 27 Mar 1997 09:55:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17383 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 Secure Shell Working Group
of the IETF.
Title : SSH Authentication Protocol
Author(s) : T. Ylonen
Filename : draft-ietf-secsh-userauth-00.txt
Pages : 10
Date : 03/26/1997
This documents describes the SSH authentication protocol. It is used to
prove that the client is authorized access the requested service with the
supplied user name. This authorization can be demonstrated through
possession of a password, through possession of a key, by authenticating
the client host and user, by some other method, or a combination of these.
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-secsh-userauth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-userauth-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-secsh-userauth-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: <19970326115622.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-userauth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-secsh-userauth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326115622.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20053; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17866; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-actng-02.txt
Date: Thu, 27 Mar 1997 09:56:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa17866 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Accounting Problem in Roaming
Author(s) : B. Aboba, D. Lidyard
Filename : draft-ietf-roamops-actng-02.txt
Pages : 23
Date : 03/26/1997
This document describes the accounting problems that arise in providing
dialup roaming capabilities. These include issues relating to
standardization of accounting record formats, and inter-provider transfers
of accounting record bundles. Work relevant to the solution of these
problems are reviewed, and recommendations are made on the direction of
future standardization work.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-actng-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-actng-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-actng-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: <19970326132230.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-actng-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-actng-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326132230.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20064; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17934; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-finlayson-ttl-admin-scope-00.txt
Date: Thu, 27 Mar 1997 09:56:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa17934 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Using TTLs with Administratively Scoped IP Multicast
Addresses
Author(s) : R. Finlayson
Filename : draft-finlayson-ttl-admin-scope-00.txt
Pages : 2
Date : 03/26/1997
The use of "administratively scoped" multicast address ranges (as described
in [1]) leads to a multicast traffic scoping mechanism that is superior to
the original "TTL scoping" mechanism.
Contrary to popular opinion, however, administrative (often abbreviated
as "admin") scoping does not truly *replace* TTL scoping. In particular,
multicast-based applications must still be aware of which
TTL value(s) they use.
In this document, we note that each definition of a range of admin scoped
multicast addresses should be accompanied by a corresponding "maximum
effective TTL" that should be used with these addresses. We describe how
these TTL values are used by applications, and how they may influence the
configuration of multicast border routers.
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-finlayson-ttl-admin-scope-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-finlayson-ttl-admin-scope-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-finlayson-ttl-admin-scope-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: <19970326132935.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-finlayson-ttl-admin-scope-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-finlayson-ttl-admin-scope-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326132935.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20105; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18290; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-dupont-ipv6-gse-multicast-00.txt
Date: Thu, 27 Mar 1997 09:57:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18290 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Implications of the GSE Addressing Scheme
to IPv6 Multicast
Author(s) : F. Dupont
Filename : draft-dupont-ipv6-gse-multicast-00.txt
Pages : 2
Date : 03/26/1997
This document presents some implications for the GSE Addressing Scheme ([1]
draft-ietf-ipngwg-gseaddr-00.txt proposal by Mike O'Dell) on IPv6
multicast: a new scope for large structures and a clever way to compare two
addresses for the election of a designated router.
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-dupont-ipv6-gse-multicast-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dupont-ipv6-gse-multicast-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-dupont-ipv6-gse-multicast-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: <19970326145147.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dupont-ipv6-gse-multicast-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dupont-ipv6-gse-multicast-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326145147.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20063; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18429; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-debry-ipp-sec-00.txt
Date: Thu, 27 Mar 1997 09:57:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18429 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Printing Protocol/1.0: Security
Author(s) : R. deBry, J. Hadsell, D. Manchala, X. Riley
Filename : draft-debry-ipp-sec-00.txt
Pages : 14
Date : 03/26/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, which describes
a distributed printing service.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-debry-ipp-sec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-debry-ipp-sec-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-debry-ipp-sec-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: <19970326150930.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-debry-ipp-sec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-debry-ipp-sec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326150930.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20082; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa16995; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.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-ospf-ospfv6-04.txt
Date: Thu, 27 Mar 1997 09:54:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa16995 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 Open Shortest Path First IGP
Working Group of the IETF.
Title : OSPF for IPv6
Author(s) : R. Coltun, D. Ferguson, J. Moy
Filename : draft-ietf-ospf-ospfv6-04.txt
Pages : 92
Date : 03/26/1997
This document describes the modifications to OSPF to support version 6 of
the Internet Protocol (IPv6). The fundamental mechanisms of OSPF
(flooding, DR election, area support, SPF calculations, etc.) remain
unchanged. However, some changes have been necessary, either due to changes
in protocol semantics between IPv4 and IPv6, or simply to handle the
increased address size of IPv6.
Changes between OSPF for IPv4 and this document include the following.
Addressing semantics have been removed from OSPF packets and
the basic LSAs. New LSAs have been created to carry IPv6 addresses
and prefixes. OSPF now runs on a per-link basis, instead of on a
per-IP-subnet basis. Flooding scope for LSAs has been generalized.
Authentication has been removed from the OSPF protocol itself, instead
relying on IPv6's Authentication Header and Encapsulating Security Payload.
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for
IPv4, even with the larger IPv6 addresses. Most field- and packet-size
limitations present in OSPF for IPv4 have been relaxed. In addition,
option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including on-demand
circuit support, NSSA areas, and the multicast extensions to OSPF
(MOSPF) are also supported in OSPF for IPv6.
Please send comments to ospf at gated.cornell.edu.
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-ospf-ospfv6-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-ospfv6-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-ospf-ospfv6-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: <19970326102224.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-ospfv6-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-ospfv6-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326102224.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20068; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17382; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ssh at clinet.fi
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-secsh-transport-00.txt
Date: Thu, 27 Mar 1997 09:55:06 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17382 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 Secure Shell Working Group
of the IETF.
Title : SSH Transport Layer Protocol
Author(s) : T. Ylonen
Filename : draft-ietf-secsh-transport-00.txt
Pages : 21
Date : 03/26/1997
This document describes the SSH transport layer protocol. The protocol can
be used as a basis for a number of secure network services. It provides
strong encryption, server authentication, and integrity protection.
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-secsh-transport-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-transport-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-secsh-transport-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: <19970326115213.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-transport-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-secsh-transport-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326115213.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20065; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17144; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-pkix at tandem.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pkix-ipki-part4-00.txt
Date: Thu, 27 Mar 1997 09:54:41 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17144 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Public-Key Infrastructure
(X.509) Working Group of the IETF.
Title : Internet Public Key Infrastructure Part IV: Certificate
Policy and Certification Practices Framework
Author(s) : S. Chokhani, W. Ford
Filename : draft-ietf-pkix-ipki-part4-00.txt
Pages : 42
Date : 03/26/1997
This document presents a framework to assist the writers of certificate
policies or certification practice statements for certification authorities
and public key infrastructures. In particular, the framework provides a
comprehensive list of topics that potentially (at the writer's discretion)
need to be covered in a certificate policy definition or a certification
practice statement. It is intended that this document, when fully
developed, be published as an Informational RFC.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-ipki-part4-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part4-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ipki-part4-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: <19970326113004.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-part4-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ipki-part4-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326113004.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20066; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17898; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-roamreq-03.txt
Date: Thu, 27 Mar 1997 09:56:14 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa17898 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : Dialup Roaming Requirements
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-roamops-roamreq-03.txt
Pages : 14
Date : 03/26/1997
This document describes the features required for the provision of "roaming
capability" for dialup Internet users, as well as offering some
suggestions for future protocol standardization work. "Roaming capability"
is defined as the ability to use any one of multiple Internet service
providers (ISPs), while maintaining a formal, customer-vendor relationship
with only one. Examples of cases where roaming capability might be
required include ISP "confederations" and ISP-provided corporate network
access support.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-roamreq-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-roamreq-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-roamreq-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: <19970326132608.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-roamreq-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-roamreq-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326132608.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20102; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17743; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-email-routing-ns-00.txt
Date: Thu, 27 Mar 1997 09:55:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17743 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : LDAP-based Routing of SMTP Messages: Approach Used by
Netscape
Author(s) : H. Lachman
Filename : draft-ietf-asid-email-routing-ns-00.txt
Pages : 13
Date : 03/26/1997
Directory services based on the Lightweight Directory Access Protocol
(LDAP) [1] and X.500 [2] provide a general-purpose means to store
information about users and other network entities. One of the many
possible uses of a directory service is to store information about users'
email accounts, such as their email addresses, and how messages addressed
to them should be routed. In the interest of interoperability, it is
desirable to have a common schema for such email-related information.
This document discusses some of the fundamental questions to be considered
in the development of a common schema for LDAP-based routing of SMTP [3]
messages, presents an approach that has been implemented and deployed, and
discusses possible extensions to that approach that may serve to make it
more complete and general. The intent is to provide information about an
existing implementation, and to stimulate discussion about whether and how
to standardize the relevant aspects of LDAP-based messaging management.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-email-routing-ns-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-email-routing-ns-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-email-routing-ns-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: <19970326130646.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-email-routing-ns-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-email-routing-ns-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326130646.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20067; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18209; 27 Mar 97 9:56 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-lanswitch-04.txt
Date: Thu, 27 Mar 1997 09:56:43 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa18209 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 : Benchmarking Terminology for LAN Switching Devices
Author(s) : B. Mandeville
Filename : draft-ietf-bmwg-lanswitch-04.txt
Pages : 13
Date : 03/26/1997
The purpose of this draft is to define and discuss benchmarking terminology
for local area switching devices. It is meant to extend the terminology
already defined for network interconnect devices in RFCs 1242 and 1944 by
the Benchmarking Methodology Working Group (BMWG) of the Internet
Engineering Task Force (IETF) and prepare the way for a discussion on
benchmarking methodology for local area switches.
LAN switches are one of the principal sources of new bandwidth
in the local area. The multiplicity of products brought to market
makes it desirable to define a set of terms to be used when evaluating
the performance characteristics of local area switching devices.
Well-defined terminology will help in providing the user community
with complete, reliable and comparable data on LAN switches.
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-lanswitch-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-lanswitch-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-bmwg-lanswitch-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: <19970326135834.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-bmwg-lanswitch-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bmwg-lanswitch-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326135834.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20103; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18660; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-hay-mcc-00.txt
Date: Thu, 27 Mar 1997 09:57:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18660 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Multicast Chat (MCC) Protocol
Author(s) : K. Hay
Filename : draft-hay-mcc-00.txt
Pages : 7
Date : 03/26/1997
This document is an rough draft for a proposed new Internet conferencing
protocol called multicast chat (MCC) which uses IP multicast for the
internet layer.
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-hay-mcc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hay-mcc-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-hay-mcc-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: <19970326153248.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hay-mcc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hay-mcc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326153248.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ad19651; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18528; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bierman-ptopo-mib-proto-00.txt
Date: Thu, 27 Mar 1997 09:57:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18528 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Physical Topology MIB and Discovery Protocol Proposal
Author(s) : A. Bierman, K. McCloghrie
Filename : draft-bierman-ptopo-mib-proto-00.txt
Pages : 38
Date : 03/26/1997
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet Base
(MIB) for use with network management protocols in the Internet managing
physical topology identification and discovery.
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-bierman-ptopo-mib-proto-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bierman-ptopo-mib-proto-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-bierman-ptopo-mib-proto-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: <19970326151251.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bierman-ptopo-mib-proto-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bierman-ptopo-mib-proto-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326151251.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20100; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17050; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ssh at cert.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-ssh-handbook-04.txt
Date: Thu, 27 Mar 1997 09:54:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17050 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 Site Security Handbook
Working Group of the IETF.
Title : Site Security Handbook
Author(s) : B. Fraser
Filename : draft-ietf-ssh-handbook-04.txt
Pages : 82
Date : 03/26/1997
This handbook is a guide to developing computer security policies and
procedures for sites that have systems on the Internet. The purpose of
this handbook is to provide practical guidance to administrators trying to
secure their information and services. The subjects covered include policy
content and formation, a broad range of technical system and network
security topics, and security incident response.
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-ssh-handbook-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ssh-handbook-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-ssh-handbook-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: <19970326105017.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ssh-handbook-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ssh-handbook-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326105017.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20106; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17047; 27 Mar 97 9:54 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-arch-00.txt
Date: Thu, 27 Mar 1997 09:54:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17047 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 : IP Version 6 Addressing Architecture
Author(s) : R. Hinden, S. Deering
Filename : draft-ietf-ipngwg-ipv6-arch-00.txt
Pages : 20
Date : 03/26/1997
This specification defines the addressing architecture of the IP Version 6
protocol [IPV6]. The document includes the IPv6 addressing model, text
representations of IPv6 addresses, definition of IPv6 unicast addresses,
anycast addresses, and multicast addresses, and an IPv6 nodes required
addresses.
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-arch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-arch-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-ipv6-arch-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: <19970326104451.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-arch-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326104451.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20104; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18582; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rtfm at auckland.ac.nz
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rtfm-new-traffic-flow-01.txt
Date: Thu, 27 Mar 1997 09:57:29 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18582 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 Realtime Traffic Flow
Measurement Working Group of the IETF.
Title : Real Time Flow Measurement Working Group - New
Attributes for Traffic Flow Measurement
Author(s) : S. Handelman, N. Brownlee, G. Ruth
Filename : draft-ietf-rtfm-new-traffic-flow-01.txt
Pages : 9
Date : 03/26/1997
The Real-time Traffic Flow Measurement (RTFM) working group has developed a
system for measuring and reporting information about traffic flows in the
Internet. This document explores the definition of extensions to the flow
measurements as currently defined in [1[ and [5]. The new attributes
described in this document will be useful for monitoring network
performance and expand the scope of RTFM beyond traffic measurement.
Performance attributes typically deal with throughput, packet loss, and
delays. We will explore the methods in which RTFM can extract values from
flows which measure these attributes. We will also look at capturing
information on jitter and congestion control.
The RTFM Working Group has defined the concept of a standardized meter
which records flows from a traffic stream according to Rule Sets
which are active in the meter[1].
Implementations of this meter have been done by Nevil Brownlee in the
University of Auckland, NZ, and Stephen Stibler and Sig Handelman at IBM in
Hawthorne, NY, USA. The RTFM WG has also discussed the Meter Reader
Program whose job is to fetch the completed group of flows active in the
Meter.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rtfm-new-traffic-flow-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rtfm-new-traffic-flow-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-rtfm-new-traffic-flow-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: <19970326152907.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rtfm-new-traffic-flow-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rtfm-new-traffic-flow-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326152907.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20109; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17559; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-url-00.txt
Date: Thu, 27 Mar 1997 09:55:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17559 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : The LDAP URL Format
Author(s) : T. Howes, M. Smith
Filename : draft-ietf-asid-ldapv3-url-00.txt
Pages : 5
Date : 03/26/1997
LDAP is the Lightweight Directory Access Protocol, defined in [2] and [3].
This document describes a format for an LDAP Uniform Resource Locator. The
format describes an LDAP search operation to perform to retrieve
information from an LDAP directory. This document replaces RFC 1959. It
updates the LDAP URL format for version 3 of LDAP and defines a way to
indicate whether the URL references a master or slave server. This document
also defines a second URL scheme prefix for LDAP running over the secure
sockets layer protocol.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-url-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-url-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-url-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: <19970326120923.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-url-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-url-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326120923.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20095; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18796; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-malachi-topology-terms-00.txt
Date: Thu, 27 Mar 1997 09:57:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18796 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Physical Topology Terminology
Author(s) : Y. Malachi
Filename : draft-malachi-topology-terms-00.txt
Pages : 6
Date : 03/26/1997
This draft proposes a common nomenclature for use by the Physical Topology
MIB Working Group. This glossary is based on the terms used in the various
Internet Drafts submitted to this working group as well as on some RFCs.
As we move forward with the definition of a common topology MIB this
glossary will evolve to reflect the new constructs in the MIB and this
draft will probably become a section in the Physical Topology MIB Internet
Draft. Although a topology MIB will include many terms we include here
only terms which are not well-defined elsewhere or might be confusing here.
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-malachi-topology-terms-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-malachi-topology-terms-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-malachi-topology-terms-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: <19970326161557.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-malachi-topology-terms-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-malachi-topology-terms-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326161557.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20132; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18931; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leach-cifs-rap-spec-00.txt
Date: Thu, 27 Mar 1997 09:58:10 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa18931 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : CIFS Remote Administration Protocol
Preliminary Draft
Author(s) : P. Leach, D. Naik
Filename : draft-leach-cifs-rap-spec-00.txt
Pages : 38
Date : 03/26/1997
This specification defines how an RPC like mechanism may be implemented
using the Common Internet File System (CIFS) Transact SMB. Specific
examples are provided of how a CIFS client may request a CIFS server to
execute a function. The examples show complete details of the request sent
by the CIFS client and the response from the CIFS server.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-leach-cifs-rap-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leach-cifs-rap-spec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leach-cifs-rap-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326164058.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leach-cifs-rap-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leach-cifs-rap-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326164058.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20094; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17814; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-murray-auth-ftp-ssl-01.txt
Date: Thu, 27 Mar 1997 09:56:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa17814 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Securing FTP with TLS
Author(s) : P. Ford-Hutchinson, T. Hudson, E. Murray
Filename : draft-murray-auth-ftp-ssl-01.txt
Pages : 25
Date : 03/26/1997
This document describes a mechanism that can be used by ftp clients and
servers to implement security and authentication using the TLS protocol
defined by the IETF TLS working group and the extensions to the ftp
protocol defined by the IETF CAT working group. It describes the subset of
the extensions that are required and the parameters to be used; discusses
some of the policy issues that clients and servers will need to take;
describes some of the implications of those policies and discusses some
expected behaviours of implementations to allow interoperation.
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-murray-auth-ftp-ssl-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-murray-auth-ftp-ssl-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-murray-auth-ftp-ssl-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: <19970326131834.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-murray-auth-ftp-ssl-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-murray-auth-ftp-ssl-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326131834.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ae19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18741; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tcp-impl at engr.sgi.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-tcpimp-prob-00.txt
Date: Thu, 27 Mar 1997 09:57:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18741 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TCP Implementation Working
Group of the IETF.
Title : Known TCP Implementation Problems
Author(s) : V. Paxson
Filename : draft-ietf-tcpimp-prob-00.txt
Pages : 9
Date : 03/26/1997
This memo catalogs a number of known TCP implementation problems. The goal
in doing so is to improve conditions in the existing Internet by enhancing
the quality of current TCP/IP 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-ietf-tcpimp-prob-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tcpimp-prob-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-tcpimp-prob-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: <19970326160504.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-tcpimp-prob-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tcpimp-prob-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326160504.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ag19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18823; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leach-cifs-v1-spec-00.txt
Date: Thu, 27 Mar 1997 09:57:56 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa18823 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Common Internet File System (CIFS/1.0) Protocol
Preliminary Draft
Author(s) : P. Leach, D. Naik
Filename : draft-leach-cifs-v1-spec-00.txt
Pages : 154
Date : 03/26/1997
This document describes the CIFS file sharing protocol, version 1.0. Client
systems use this protocol to request file and print services from server
systems over a network. It is based on the Server Message Block protocol
widely in use by personal computers and workstations running a wide variety
of operating systems.
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-leach-cifs-v1-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leach-cifs-v1-spec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leach-cifs-v1-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326162739.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leach-cifs-v1-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leach-cifs-v1-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326162739.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id af19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18766; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leach-cifs-logon-spec-00.txt
Date: Thu, 27 Mar 1997 09:57:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18766 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : CIFS Logon and Pass Through Authentication
Preliminary Draft
Author(s) : P. Leach, D. Naik
Filename : draft-leach-cifs-logon-spec-00.txt
Pages : 22
Date : 03/26/1997
This specification defines how a certain Common Internet File Systems
(CIFS) client accomplishes logging on to a CIFS server. The specification
also details how a CIFS server may accomplish pass through authentication.
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-leach-cifs-logon-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leach-cifs-logon-spec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leach-cifs-logon-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326161137.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leach-cifs-logon-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leach-cifs-logon-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326161137.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20558; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19021; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.edu, ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-isslow-mcml-01.txt
Date: Thu, 27 Mar 1997 09:58:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa19021 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 : The Multi-Class Extension to Multi-Link PPP
Author(s) : C. Bormann
Filename : draft-ietf-issll-isslow-mcml-01.txt
Pages : 10
Date : 03/26/1997
A companion document describes an architecture for providing integrated
services over low-bitrate links, such as modem lines, ISDN B-channels, and
sub-T1 links [1]. The main components of the architecture are: a real-time
encapsulation format for asynchronous and synchronous low-bitrate links, a
header compression architecture optimized for real-time flows, elements of
negotiation protocols used between routers (or between hosts and routers),
and announcement protocols used by applications to allow this negotiation
to take place.
This document proposes the fragment-oriented solution for the real-time
encapsulation format part of the architecture. The general approach is
to start from the PPP Multilink fragmentation protocol [2] and provide
a small number of extensions to add functionality and reduce the overhead.
This document is a product of the IETF ISSLL working group.
Comments are solicited and should be addressed to
the two working groups' mailing lists at issll at mercury.lcs.mit.edu and
ietf-ppp at merit.edu and/or the author.
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-isslow-mcml-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-isslow-mcml-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-isslow-mcml-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: <19970326165945.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-isslow-mcml-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-isslow-mcml-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326165945.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20619; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19041; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.edu, ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-isslow-rtf-00.txt
Date: Thu, 27 Mar 1997 09:58:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa19041 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 Integrated Services over
Specific Link Layers Working Group of the IETF.
Title : PPP in a real-time oriented HDLC-like framing
Author(s) : C. Bormann
Filename : draft-ietf-issll-isslow-rtf-00.txt
Pages : 10
Date : 03/26/1997
A companion document describes an architecture for providing integrated
services over low-bitrate links, such as modem lines, ISDN B-channels, and
sub-T1 links [1]. The main components of the architecture are: a real-time
encapsulation format for asynchronous and synchronous low-bitrate links, a
header compression architecture optimized for real-time flows, elements of
negotiation protocols used between routers (or between hosts and routers),
and announcement protocols used by applications to allow this negotiation
to take place.
This document proposes the suspend/resume-oriented solution for the
real-time encapsulation format part of the architecture. The general
approach is to start from the PPP Multilink fragmentation protocol [2]
and its multi-class extension [5] and add suspend/resume in a way
that is as compatible to existing hard- and firmware as possible.
This document is a product of the IETF ISSLL working group.
Comments are solicited and should be addressed to the two
working groups' mailing lists at issll at mercury.lcs.mit.edu and
ietf-ppp at merit.edu and/or the author.
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-isslow-rtf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-isslow-rtf-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-issll-isslow-rtf-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: <19970326170529.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-isslow-rtf-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-isslow-rtf-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326170529.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20697; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19434; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-viswanathan-aris-overview-00.txt
Date: Thu, 27 Mar 1997 09:58:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa19434 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ARIS: Aggregate Route-Based IP Switching
Author(s) : A. Viswanathan, N. Feldman, R. Boivie, R. Woundy
Filename : draft-viswanathan-aris-overview-00.txt
Pages : 19
Date : 03/26/1997
IP based networks use a number of routing protocols, including RIP, OSPF,
IS-IS, and BGP, to determine how packets ought to be routed. Among these
protocols, OSPF and BGP are IETF-recommended standards that have been
extensively deployed and exercised in many networks. In this memo, we
describe a mechanism which uses these protocols as the basis for switching
IP datagrams, by the addition of a simple protocol ("ARIS") that
establishes switched paths through a network. The ARIS protocol allows us
to leverage the advantages of switching technologies in an internet
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-viswanathan-aris-overview-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-viswanathan-aris-overview-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-viswanathan-aris-overview-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: <19970326171235.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-viswanathan-aris-overview-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-viswanathan-aris-overview-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326171235.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ai19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18906; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leach-cifs-print-spec-00.txt
Date: Thu, 27 Mar 1997 09:58:07 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa18906 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : CIFS Printing Specification
Preliminary Draft
Author(s) : P. Leach, D. Naik
Filename : draft-leach-cifs-print-spec-00.txt
Pages : 30
Date : 03/26/1997
This specification defines how clients may submit print requests to a
server using SMBs . The specification also details how clients may
administer printing of the print requests they create, using SMBs defined
in the Common Internet File System specification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-leach-cifs-print-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leach-cifs-print-spec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-leach-cifs-print-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326163752.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leach-cifs-print-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leach-cifs-print-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326163752.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aj19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19455; 27 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-feldman-aris-spec-00.txt
Date: Thu, 27 Mar 1997 09:58:58 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270959.aa19455 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ARIS Specification
Author(s) : N. Feldman, A. Viswanathan
Filename : draft-feldman-aris-spec-00.txt
Pages : 43
Date : 03/26/1997
ARIS (Aggregate Route-Based IP Switching) adds the advantages of high-speed
switching to a network based on routing protocols. It provides a means of
mapping network-layer routing information to link-layer switched paths,
enabling datagrams to traverse a network at media speeds. This memo
defines the ARIS protocol and its 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-feldman-aris-spec-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-feldman-aris-spec-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-feldman-aris-spec-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326172943.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-feldman-aris-spec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-feldman-aris-spec-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326172943.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20675; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18958; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: issll at mercury.lcs.mit.edu, ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-issll-isslow-01.txt
Date: Thu, 27 Mar 1997 09:58:14 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa18958 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 : Providing integrated services over low-bitrate links
Author(s) : C. Bormann
Filename : draft-ietf-issll-isslow-01.txt
Pages : 11
Date : 03/26/1997
This document describes an architecture for providing integrated services
over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1
links. It covers only the lower parts of the Internet Multimedia
Conferencing Architecture [1]; additional components required for
application services such as Internet Telephony (e.g., a session initiation
protocol) are outside the scope of this document. The main components of
the architecture are: a real-time encapsulation format for asynchronous and
synchronous low-bitrate links, a header compression architecture optimized
for real-time flows, elements of negotiation protocols used between routers
(or between hosts and routers), and announcement protocols used by
applications to allow this negotiation to take place.
This document is a product of the IETF ISSLL working group.
Comments are solicited and should be addressed to the
working group's mailing list at issll at mercury.lcs.mit.edu
and/or the author.
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-isslow-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-issll-isslow-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-isslow-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: <19970326165359.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-issll-isslow-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-issll-isslow-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326165359.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ak19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19460; 27 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-fielding-url-syntax-04.txt
Date: Thu, 27 Mar 1997 09:58:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270959.aa19460 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Uniform Resource Locators (URL): Generic Syntax and
Semantics
Author(s) : T. Berners-Lee, R. Fielding, L. Masinter
Filename : draft-fielding-url-syntax-04.txt
Pages : 23
Date : 03/26/1997
A Uniform Resource Locator (URL) is a compact string representation of a
location for use in identifying an abstract or physical resource. This
document defines the general syntax and semantics of URLs, including both
absolute and relative locators, and guidelines for their use. It revises
and replaces the generic definitions in RFC 1738 and RFC 1808.
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-fielding-url-syntax-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-fielding-url-syntax-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-fielding-url-syntax-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326173240.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-fielding-url-syntax-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fielding-url-syntax-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326173240.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id al19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19489; 27 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: aft at unify.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-aft-socks-pro-v5-00.txt
Date: Thu, 27 Mar 1997 09:59:02 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270959.aa19489 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Authenticated Firewall
Traversal Working Group of the IETF.
Title : SOCKS Protocol Version 5
Author(s) : M. Leech, M. Ganis, Y. Lee, R. Kuris,
D. Koblas, L. Jones, D. Blob, W. Lu
Filename : draft-ietf-aft-socks-pro-v5-00.txt
Pages : 10
Date : 03/26/1997
The use of network firewalls, systems that effectively isolate an
organizations internal network structure from an exterior network, such as
the INTERNET is becoming increasingly popular.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-aft-socks-pro-v5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-aft-socks-pro-v5-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-aft-socks-pro-v5-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: <19970326173823.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-aft-socks-pro-v5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-aft-socks-pro-v5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326173823.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id am19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19516; 27 Mar 97 9:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-calendar at imc.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-calsch-ical-01.txt
Date: Thu, 27 Mar 1997 09:59:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270959.aa19516 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 Calendaring and Scheduling
Working Group of the IETF.
Title : Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
Author(s) : F. Dawson, D. Stenerson
Filename : draft-ietf-calsch-ical-01.txt
Pages : 73
Date : 03/26/1997
There is a clear need to provide and deploy interoperable calendaring and
scheduling services for the Internet. Current group scheduling and Personal
Information Management (PIM) products are being extended for use across the
Internet, today, in proprietary ways. This document has been defined to
provide the a definition of a common format for openly exchanging
calendaring and scheduling information across the Internet.
This memo is formatted as a registration for a MIME media type per
[RFC 2048]. However, the format in this memo is equally applicable for
use outside of a MIME message content type.
The proposed media type value is "TEXT/CALENDAR". This string would label
a media type containing calendaring and scheduling information encoded
as text characters formatted in a manner outlined below.
This MIME media type provides a standard content type for capturing calendar
event and to-do information. It also can be used to convey free/busy time
information. The content type is suitable as a MIME message entity that
can be transferred over MIME based email systems or using HTTP.
In addition, the content type is useful as an object for
interactions between desktop applications using the operating system
clipboard, drag/drop or file systems capabilities.
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-calsch-ical-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-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-calsch-ical-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: <19970326174850.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-calsch-ical-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-calsch-ical-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326174850.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20862; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa19835; 27 Mar 97 9:59 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-model-00.txt
Date: Thu, 27 Mar 1997 09:59:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270959.aa19835 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 : Internet Printing Protocol/1.0: Model and Semantics
Author(s) : R. Debry, T. Hastings, R. Herriot,
S. Isaacson, P. Powell
Filename : draft-ietf-ipp-model-00.txt
Pages : 94
Date : 03/26/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
specifies the both end user and administrative features, IPP version 1.0
(v1.0)is focused only on 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-model-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-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-model-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: <19970326181017.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipp-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipp-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326181017.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20032; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17083; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-guerin-qos-routing-ospf-01.txt
Date: Thu, 27 Mar 1997 09:54:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17083 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : QoS Routing Mechanismsand OSPFExtensions
Author(s) : R. Guerin, S. Kamat, A. Orda,
T. Przygienda, D. Williams
Filename : draft-guerin-qos-routing-ospf-01.txt
Pages : 38
Date : 03/26/1997
This memo describes extensions to the OSPF [Moy94] protocol to support QoS
routes. The focus of the document is on the algorithms used to compute QoS
routes and on the necessary modifications to OSPF to support this function,
e.g., the information needed, its format, how it is distributed, and how it
is used by the QoS path selection process. Aspects related to how QoS
routes are established and managed are also discussed. The goal of this
document is to identify a framework and possible approaches to allow
deployment of QoS routing capabilities with the minimum possible impact to
the existing routing infrastructure.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-guerin-qos-routing-ospf-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-guerin-qos-routing-ospf-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-guerin-qos-routing-ospf-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: <19970326110716.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-guerin-qos-routing-ospf-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-guerin-qos-routing-ospf-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326110716.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20017; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18373; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ngtrans 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-ngtrans-6bone-registry-00.txt
Date: Thu, 27 Mar 1997 09:57:08 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18373 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 New Generation Transition
Working Group of the IETF.
Title : A proposal for an IPv6 site database object
Author(s) : D. Kessens, G. de Groot
Filename : draft-ietf-ngtrans-6bone-registry-00.txt
Pages : 9
Date : 03/26/1997
This proposal describes the proposed syntax of a new RIPE database object
that describes the several IPv6 sites in the world. The object and
resulting database collection will be used to facilitate the introduction
of IPv6 in the Internet.
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-ngtrans-6bone-registry-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ngtrans-6bone-registry-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-ngtrans-6bone-registry-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: <19970326150318.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ngtrans-6bone-registry-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ngtrans-6bone-registry-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326150318.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20027; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18066; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-aboba-unweb-00.txt
Date: Thu, 27 Mar 1997 09:56:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa18066 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for Unreliable Multicasting
of Web Resources
Author(s) : B. Aboba
Filename : draft-aboba-unweb-00.txt
Pages : 6
Date : 03/26/1997
This document discusses applications for unreliable multicasting of Web
resources as well as requirements for an unreliable multicast protocol
suitable for this use.
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-aboba-unweb-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-aboba-unweb-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-aboba-unweb-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: <19970326133452.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-aboba-unweb-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-aboba-unweb-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326133452.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac19651; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17709; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-fielding-http-age-00.txt
Date: Thu, 27 Mar 1997 09:55:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17709 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Age Header Field in HTTP/1.1
Author(s) : R. Fielding
Filename : draft-fielding-http-age-00.txt
Pages : 6
Date : 03/26/1997
The "Age" response-header field in HTTP/1.1 [RFC 2068] is intended to
provide a lower-bound for the estimation of a response message's age (time
since generation) by explicitly indicating the amount of time that is known
to have passed since the response message was retrieved or revalidated.
However, there has been considerable controversy over when the Age header
field should be added to a response. This document explains the issues and
provides a set of proposed changes for the revision of RFC 2068.
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-fielding-http-age-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-fielding-http-age-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-fielding-http-age-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: <19970326130054.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-fielding-http-age-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fielding-http-age-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326130054.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20079; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18333; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-stevens-advanced-api-02.txt
Date: Thu, 27 Mar 1997 09:57:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18333 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Advanced Sockets API for IPv6
Author(s) : W. Stevens, M. Thomas
Filename : draft-stevens-advanced-api-02.txt
Pages : 67
Date : 03/26/1997
Specifications are in progress for changes to the sockets API to support IP
version 6 [2]. These changes are for TCP and UDP-based applications and
will support most end-user applications in use today: Telnet and FTP
clients and servers, HTTP clients and servers, and the like.
But another class of applications exists that will also be run under IPv6.
We call these "advanced" applications and today this includes programs
such as Ping, Traceroute, routing daemons, multicast routing daemons,
router discovery daemons, and the like. The API feature typically
used by these programs that make them "advanced" is a raw socket to
access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet
header formats used by these protocols. To provide portability for
applications that use raw sockets under IPv6, some standardization
is needed for the advanced API features.
There are other features of IPv6 that some applications will need to
access: interface identification (specifying the outgoing interface
and determining the incoming interface) and IPv6 extension headers that are
not addressed in [2]: Hop-by-Hop options, Destination options, and the
Routing header (source routing). This document provides API access
to these features too.
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-stevens-advanced-api-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-stevens-advanced-api-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-stevens-advanced-api-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: <19970326145630.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-stevens-advanced-api-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-stevens-advanced-api-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326145630.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20084; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18011; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-roamops-auth-00.txt
Date: Thu, 27 Mar 1997 09:56:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa18011 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Roaming Operations Working
Group of the IETF.
Title : The Authentication and Authorization Problem in Roaming
Author(s) : B. Aboba
Filename : draft-ietf-roamops-auth-00.txt
Pages : 11
Date : 03/26/1997
This document describes the authentication and authorization problems that
arise in the provisioning of dialup roaming capabilities. These include
issues relating to authentication routing as well as non-repudiation of
Access-Accepts.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-roamops-auth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-auth-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-auth-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326133243.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-auth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-auth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326133243.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20057; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17628; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-asid-ldapv3-filter-00.txt
Date: Thu, 27 Mar 1997 09:55:45 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17628 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Access, Searching and
Indexing of Directories Working Group of the IETF.
Title : The String Representation of LDAP Search Filters
Author(s) : T. Howes
Filename : draft-ietf-asid-ldapv3-filter-00.txt
Pages : 5
Date : 03/26/1997
The Lightweight Directory Access Protocol (LDAP) [1] defines a network
representation of a search filter transmitted to an LDAP server. Some
applications may find it useful to have a common way of representing these
search filters in a human-readable form. This document defines a
human-readable string format for representing LDAP search filters.
This document replaces RFC 1960, extending the string LDAP filter
definition to include support for LDAP version 3 extended match filters,
and including support for representing the full range of
possible LDAP search filters.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-asid-ldapv3-filter-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-filter-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-asid-ldapv3-filter-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: <19970326121430.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-asid-ldapv3-filter-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-asid-ldapv3-filter-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326121430.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20083; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17435; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ssh at clinet.fi
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-secsh-connect-00.txt
Date: Thu, 27 Mar 1997 09:55:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17435 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 Secure Shell Working Group
of the IETF.
Title : Connect
Author(s) : T. Ylonen
Filename : draft-ietf-secsh-connect-00.txt
Pages : 15
Date : 03/26/1997
This document describes the SSH connection protocol. It runs over the SSH
user authentication layer, and performs management of forwarded connections
and the terminal session(s).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-secsh-connect-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-connect-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-secsh-connect-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: <19970326120036.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-connect-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-secsh-connect-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326120036.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20099; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17260; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-aal5-funi-00.txt
Date: Thu, 27 Mar 1997 09:54:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17260 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP over AAL5 and FUNI
Author(s) : M. Kaycee, G. Gross, A. Lin,
A. Malis, J. Stephens
Filename : draft-ietf-pppext-aal5-funi-00.txt
Pages : 7
Date : 03/26/1997
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. This
document describes the use of ATM Adaptation Layer 5 (AAL5) and Frame User
Network Interface (FUNI) for framing PPP encapsulated packets.
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-aal5-funi-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-aal5-funi-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-aal5-funi-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: <19970326114359.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-aal5-funi-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-aal5-funi-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326114359.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20092; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17021; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-avt-rtp-mib-00.txt
Date: Thu, 27 Mar 1997 09:54:15 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17021 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 Audio/Video Transport
Working Group of the IETF.
Title : Real-Time Transport Protocol Management Information Base
Author(s) : M. Baugher, J. Du, S. Naudus
Filename : draft-ietf-avt-rtp-mib-00.txt
Pages : 25
Date : 03/26/1997
This memo defines an experimental Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Real-Time Transport Protocol
Systems [1]. Comments should be made to the IETF Audio/Video Transport
Working Group.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-avt-rtp-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-mib-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-avt-rtp-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970326103143.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-avt-rtp-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-rtp-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326103143.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20098; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa17114; 27 Mar 97 9:54 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-hinden-vrrp-00.txt
Date: Thu, 27 Mar 1997 09:54:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17114 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Virtual Router Redundancy Protocol
Author(s) : S. Knight, D. Weaver, D. Whipple, R. Hinden
Filename : draft-hinden-vrrp-00.txt
Pages : 16
Date : 03/26/1997
The memo documents the Virtual Router Redundancy Protocol. This is a
protocol which allows several routers to utilize the same virtual IP
address. One router will be elected as a master, with X routers acting as
backups in case of failure of the master router. The primary advantage to
utilizing this protocol, is that host systems may be configured with a
single default gateway, rather than running an active routing protocol.
Each interface on each router within a VRRP cluster, will be configured
with a real IP address, and the virtual IP address for the particular
cluster. Overall, this protocol adds to the options for providing fault
redundancy for router networks.
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-hinden-vrrp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hinden-vrrp-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-hinden-vrrp-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: <19970326111335.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hinden-vrrp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hinden-vrrp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326111335.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20096; 27 Mar 97 10:00 EST
Received: from ietf.ietf.org by ietf.org id aa18104; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ogawa-receiver-shortcut-path-00.txt
Date: Thu, 27 Mar 1997 09:56:35 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa18104 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Receiver-Initiated Shortcut Path Protocol (RISP)
Author(s) : J. Ogawa, Y. Chen
Filename : draft-ogawa-receiver-shortcut-path-00.txt
Pages : 13
Date : 03/26/1997
This memo defines the Receiver Initiated Shortcut Path (RISP) protocol for
NBMA networks. The protocol extends the NHRP message set by adding
Callback Request and Reply messages to allow the destination host (or its
corresponding egress router) to establish a shortcut path for a data flow,
using the existing NBMA signaling protocols. Because of this
receiver-initiated mechanism, a shortcut-capable network can use just the
NBMA ARP servers, such as the ATMARP servers, instead of the more complex
Next Hop Servers. This draft also describes how to extend NHRP with the
new, receiver-initiated mechanism.
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-ogawa-receiver-shortcut-path-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ogawa-receiver-shortcut-path-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-ogawa-receiver-shortcut-path-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: <19970326133939.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ogawa-receiver-shortcut-path-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ogawa-receiver-shortcut-path-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326133939.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20097; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18677; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rps at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rps-appl-rpsl-00.txt, .ps
Date: Thu, 27 Mar 1997 09:57:39 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18677 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing Policy System
Working Group of the IETF.
Title : Application of Routing Policy Specification Language
(RPSL) on the Internet
Author(s) : C. Alaettinoglu, D. Meyer, J. Schmitz
Filename : draft-ietf-rps-appl-rpsl-00.txt, .ps
Pages : 17
Date : 03/26/1997
This document is a tutorial on using the Routing Policy Specification
Language (RPSL) to specify routing policies. It covers registering
policies in an Internet Routing Registry (IRR) using RPSL, and the use of
tools to generate vendor specific router configuration. It is targeted
towards an Internet/Network Service Provider (ISP/NSP) engineer who is new
to RPSL and to IRR. Readers are referred to the RPSL reference document
[1] for completeness. We recommend reading this document before reading
the reference document. We hope that for many cases, this document will be
sufficient.
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-rps-appl-rpsl-00.txt".
Or
"get draft-ietf-rps-appl-rpsl-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rps-appl-rpsl-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-rps-appl-rpsl-00.txt".
Or
"FILE /internet-drafts/draft-ietf-rps-appl-rpsl-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: <19970326160051.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rps-appl-rpsl-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rps-appl-rpsl-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326160051.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20107; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17789; 27 Mar 97 9:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ohta-sun-01.txt
Date: Thu, 27 Mar 1997 09:56:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270956.aa17789 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Unified Networking
Author(s) : M. Ohta
Filename : draft-ohta-sun-01.txt
Pages : 7
Date : 03/26/1997
The concept of LIS for IP over ATM causes a topology mismatch between the
link and the internetworking layer. While it introduces some inefficiency
with CATENET based operation, it is not so much a problem unless we try to
solve this minor problem.
Short-cutting attempts such as NHRP can't solve the inefficiency issue
at all even though, or, just because, it utterly destroys the
CATENET model, which resulted in inelegant modifications of
existing protocols, which, in turn, causes scalability problems.
Moreover, the creation of short-cut VCs itself suffers a
scalability issue.
But, CSRs (Cell Switching Routers), or RSVP-signaled ATM switches,
make it possible to have end-to-end cell-by-cell relaying
over IP routers. That is, there is no reason to have LISes and there is no
inefficiency
The way to go for the Internet is Simple Unified Networking with
the CATENET model.
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-ohta-sun-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ohta-sun-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-ohta-sun-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: <19970326131236.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ohta-sun-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ohta-sun-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326131236.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20108; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa17660; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: spki at c2.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-spki-cert-structure-01.txt
Date: Thu, 27 Mar 1997 09:55:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270955.aa17660 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 Simple Public Key
Infrastructure Working Group of the IETF.
Title : Simple Public Key Certificate
Author(s) : C. Ellison, W. Frantz, B. Thomas
Filename : draft-ietf-spki-cert-structure-01.txt
Pages : 39
Date : 03/26/1997
With the proliferation of public key cryptography on the Internet, there
arises a need for certification of keys. In the literature, the word
"certificate" has been generally taken to mean "identity certificate" -- a
signed statement which binds a key to the name of an individual and has the
intended meaning of delegating authority from that named individual to the
public key. (See, for example, RFC 1422.) This process is designed to
transfer a relationship between two entities from the physical world into
the digital world.
The Internet itself changed the world from the one in which
identity certificates were considered necessary. As Internet use
increases, we increasingly interact with people or companies with whom we
have no relationship in the physical world. A transfer of relationship
from the physical world to the digital world is meaningless in such cases.
Instead, we need to establish relationships directly in the digital world
through an instrument which assigns attributes (authority, permission, ...)
to the digital principal. We call that an "authorization certificate".
SPKI certificates were designed to perform that function by directly
specifying the <auth,key> binding which is of interest
in the digital world.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-spki-cert-structure-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-spki-cert-structure-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-spki-cert-structure-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: <19970326125414.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-spki-cert-structure-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-spki-cert-structure-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326125414.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ah19651; 27 Mar 97 10:01 EST
Received: from ietf.ietf.org by ietf.org id aa18847; 27 Mar 97 9:58 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-leach-asid-ds-email-00.txt
Date: Thu, 27 Mar 1997 09:58:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270958.aa18847 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Locating DS Entries by E-mail Address
Preliminary Draft
Author(s) : P. Leach
Filename : draft-leach-asid-ds-email-00.txt
Pages : 4
Date : 03/26/1997
The LDAPv3 protocol (as specified in [1]) is designed to be a lightweight
access protocol for directory services supporting X.500 models. In
addition, in an Internet context, many of the names about which users seek
information are Internet email addresses. A native LDAP based directory
service for the Internet should make it convenient to process such names --
there is a huge social investment spanning two decades to get to the point
where names like "john.doe at somewhere.com" can appear in newspaper articles,
TV commercials, and on billboards and millions of people understand what do
with them.
This draft defines a very simple convention for looking up information
associated with people identified by Internet email addresses -
really nothing more than identifying an existing capability of LDAP,
in the hopes that the convention can become widespread.
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-leach-asid-ds-email-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-leach-asid-ds-email-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-leach-asid-ds-email-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: <19970326163313.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-leach-asid-ds-email-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-leach-asid-ds-email-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326163313.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21174; 27 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa17143; 27 Mar 97 9:54 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-hit-metering-02.txt
Date: Thu, 27 Mar 1997 09:54:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270954.aa17143 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Title : Simple Hit-Metering and Usage-Limiting for HTTP
Author(s) : J. Mogul, P. Leach
Filename : draft-ietf-http-hit-metering-02.txt
Pages : 34
Date : 03/26/1997
This document proposes a simple extension to HTTP, using a new ``Meter''
header, which permits a limited form of demographic information
(colloquially called ``hit-counts'') to be reported by caches to origin
servers, in a more efficient manner than the ``cache-busting'' techniques
currently used. It also permits an origin server to control the number of
times a cache uses a cached response, and outlines a technique that origin
servers can use to capture referral information without ``cache-busting.''
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-hit-metering-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-hit-metering-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-hit-metering-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: <19970326112517.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-hit-metering-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-hit-metering-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326112517.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab21174; 27 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa18287; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ftp-wg at hops.ag.utk.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ftpext-mlst-00.txt
Date: Thu, 27 Mar 1997 09:56:57 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18287 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 Extensions to FTP Working
Group of the IETF.
Title : MLST Command and Extensions to FTP
Author(s) : P. Hethmon, R. Elz
Filename : draft-ietf-ftpext-mlst-00.txt
Pages : 19
Date : 03/26/1997
In order to overcome the problems inherent in the current FTP LIST output,
a new command is needed to transfer standardized listing information from
Server-FTP to Client-FTP. In addition, a way for the Server-FTP to let the
Client-FTP know of this capability without imposing on the Client-FTP to
randomly try new commands is needed. This proposal meets both of these
requirements.
This proposal also extends the FTP protocol to allow character sets other
than US-ASCII[1] by allowing the transmission of 8-bit characters and the
recommended use of UTF-8[2] encoding.
This version of the document corrects some aspects of the previous draft,
which was filed as: draft-hethmon-mlst-command-ftp-01.txt in particular
some of the details of the ABNF used. It also adds some editorial notes
where questions to be resolved still exist. This paragraph will be deleted
from the final version of this document.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ftpext-mlst-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ftpext-mlst-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-ftpext-mlst-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: <19970326144724.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ftpext-mlst-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ftpext-mlst-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326144724.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac21174; 27 Mar 97 10:06 EST
Received: from ietf.ietf.org by ietf.org id aa18565; 27 Mar 97 9:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rps at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rps-rpsl-01.txt
Date: Thu, 27 Mar 1997 09:57:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703270957.aa18565 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 Routing Policy System
Working Group of the IETF.
Title : Routing Policy Specification Language (RPSL)
Author(s) : C. Alaettinoglu, T. Bates, E. Gerich,
D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar
Filename : draft-ietf-rps-rpsl-01.txt
Pages : 42
Date : 03/26/1997
This Internet Draft is the reference document for the Routing Policy
Specification Language (RPSL). RPSL allows a network operator to be able to
specify routing policies at various levels in the Internet hierarchy; for
example at the Autonomous System (AS) level. At the same time, policies
can be specified with sufficient detail in RPSL so that low level router
configurations can be generated from them. RPSL is extensible; new routing
protocols and new protocol features can be introduced at any time.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rps-rpsl-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rps-rpsl-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-rps-rpsl-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: <19970326151742.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rps-rpsl-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rps-rpsl-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970326151742.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa27189; 27 Mar 97 12:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa15437;
27 Mar 97 12:07 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <OAA02370 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 14:50:15 GMT
Message-Id: <199703271448.AA20401 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
To: Marc H <marc at cygnus.com>
Date: Thu, 27 Mar 1997 09:48:54 -0500 (EST)
Cc: tytso at mit.edu, cat-ietf at mit.edu
In-Reply-To: <t53sp1im6qh.fsf at rover.cygnus.com> from "Marc H" at Mar 26, 97 09:03:18 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 H wrote:
> Martin Rex <martin.rex at sap-ag.de> writes:
> >> As an application provider, I'd really like to save the administrators
> >> and users from having to configure *ANY* nametypes. I do accept the
> >> currently defined "generic" nametypes, but from the discussion on
> >> the list I have to conclude that they're not really useful:
>
> I think it is simply asking too much to expect to be able to isolate
> the administrators from having to configure name types.
No, it's not. If there is one such name, it shouldn't have
to be configured in the application, it should be compiled into
the gssapi mechanism.
>
> Perhaps we should have an interface to convert from a human-readable
> form (like "hostbased_service_name") to an oid. This would make
> configuration less obscure, since you could at least isolate the
> administrator from OIDs.
>
> >> Personally, I'd either like to see all mechanisms use their native
> >> name format for import_name( name_type=GSS_C_NO_OID ) for gssapi v2,
> >> or a new explicit generic nametype which indicates "the mechanisms
> >> native name format".
>
> I don't think that "native name format" necessarily has a single
> distinguished meaning for every mechanism.
Maybe not for every conceivable mechanism, but it will definitely work
for more mechanisms than any of the existing "generic" name types.
In addition to the Kerberos-familiy of mechanisms, such a nametype
would also work for SPKM and similar public key based mechanisms,
where hostbased service names DO NOT work.
-Martin
Received: from cnri by ietf.org id aa29315; 27 Mar 97 12:55 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa16551;
27 Mar 97 12:55 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA03885 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 15:26:16 GMT
Message-Id: <9703271513.AA08452 at us1rmc.bb.dec.com>
Date: Thu, 27 Mar 97 10:14:16 EST
From: "John Wray, Digital DPE, 508/486-5210 27-Mar-1997 1009" <wray at tuxedo.enet.dec.com>
To: marc at cygnus.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at MIT.EDU, marc at cygnus.com
Subject: RE: gss_accept_sec_context and gss_display_status
Precedence: bulk
Marc writes:
>RFC2078 says:
>
> The mech_type return value indicates the specific mechanism employed
> on the context, is valid only along with major_status GSS_S_COMPLETE,
> and will never indicate the value for "default".
>
>So, if gss_accept_sec_context returns an error, it is impossible to
>portably determine the mech oid to pass to gss_display_status to
>convert the minor status into a usable form. This seems like a bug.
Yep. looks like a bug to me too.
>A multimechanism acceptor will determine the mechanism from the mech
>oid included in first initiator token. It would be possible and
>desirable for the gssapi to require mechanism implementations to
>return an oid in the mech_name output after each call, not just with
>GSS_S_COMPLETE.
>
>For the benefit of negotiation mechanisms, we could allow this output
>to change, reflecting the mechanism which generated the minor status
>code. When GSS_S_COMPLETE is returned, the mech_type would identify
>the mechanism which was negotiated, completed, and is to be used for
>per-message protection.
>
>If the the mech oid is unknown, then GSS_S_BAD_MECH is returned:
>
> o GSS_S_BAD_MECH indicates receipt of a context establishment token
> specifying a mechanism unsupported by the local system or with
> the caller's active credentials.
>
>Since this implies that there is no mechanism, the concept of a
>mechanism-specific minor status is meaningless. The mechanism must
>return a zero minor status code, and the application should ignore the
>minor status code.
That sounds right, although it should also be specified that
gss_accept_sec_context() should return the unrecognized mech-type OID in this
case, as the app will probably want to display it or put in in an audit log.
The spec currently leaves this decision to the implementation.
John
Received: from cnri by ietf.org id aa00317; 27 Mar 97 13:21 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17111;
27 Mar 97 13:21 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <PAA03496 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 15:16:04 GMT
Message-Id: <9703271504.AA07842 at us1rmc.bb.dec.com>
Date: Thu, 27 Mar 97 10:04:50 EST
From: "John Wray, Digital DPE, 508/486-5210 27-Mar-1997 0941" <wray at tuxedo.enet.dec.com>
To: tytso at mit.edu
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, tytso at mit.edu
Subject: Re: Name type issues
Precedence: bulk
Ted writes:
> From: "John Wray, Digital DPE, 508/486-5210 26-Mar-1997 1434" <wray at tuxedo.ENET.dec.com>
>
> If we're going to require default initiator (and I think we should),
> I don't see why we can't also mandate support of a default acceptor.
> The final option ("otherwise a user-configurable default identity
> shall be used") allows for the very low-cost method of having a
> configuration-file that GSSAPI can use to determine what the default
> identity is, so it's certainly not onerous on implementors to support
> this.
>
>... and what error should the GSSAPI system return if the configuration
>file isn't present? I'm somewhat nervous about assuming the existence
>of a configuration file; Kerberos might have one, but not all mechanism
>implementation may.
>
>This may also encourage application programmers to assume that the
>configuration file will take care of things for them. Which may be fine
>if you only need to run one application on a host, but what if you need
>to run multiple applications on the same host with different identities,
>and you only have one configuration file?
I didn't mean to require a configuration file, and certainly nota single
system-wide one. A configuration file was simply an example of one low-cost
way that an implementation could implement the last of the four ordered options
for default acceptor behavior.
The situation for the default acceptor credential should be analagous to that
for default initiator credentials. To define the default initiator, we assume
that the user has done something like a login operation prior to invoking the
client GSSAPI application, and that this operation has left some persistent
data around in some platform-specific location. Using Kerberos as an example,
the user's probably done a kinit which has left a ticket in a credential cache.
When GSSAPI needs to determine the default initiator identity, it will look in
that credential cache and use the ticket for the default principal therein.
I'm suggesting that the acceptor behavior should be defined in pretty much the
same way. The server administrator should be responsible for creating the
acceptor credential (in kerberos terms, placing the server key in a key-table).
There should be a platform-specific management operation (analagous to kinit)
that lets the GSSAPI within the server application know where to look for that
keytable (and since I don't think Kerberos has a place within a keytable to set
the "default" key, the platform-specific operation would also have to set that
[but see below]). My suggestion of a configuration file was simply one way to
tell GSSAPI; a simpler way might be to use an environment variable.
For Kerberos, I don't really think there's any need to do more than provide a
way to point GSSAPI towards the appropriate keytable, since Kerberos can look
at the incoming ticket to determine the target principal, and then look in the
specified keytable to see if there's a key for that principal (this corresponds
to the second option in the GSSAPI specs for default acceptor behavior). Doing
this is much more flexible than either the server app or GSSAPI picking a
single acceptor identity ahead of time.
Just as the client's identity isn't built-in to a typical client application,
but is instead derived from the environment within which that client is
executed, for maximum portability we should do the same for servers - i.e.
allow their identities to be defined by their administrators, rather than
building them into the server code.
John
Received: from ietf.org by ietf.org id aa00458; 27 Mar 97 13:26 EST
Received: from dfw-ix9.ix.netcom.com by ietf.org id aa00159; 27 Mar 97 13:18 EST
Received: (from smap at localhost)
by dfw-ix9.ix.netcom.com (8.8.4/8.8.4)
id MAA28400 for <ietf at ietf.org>; Thu, 27 Mar 1997 12:15:01 -0600 (CST)
Received: from aus-tx4-16.ix.netcom.com(199.35.201.144) by dfw-ix9.ix.netcom.com via smap (V1.3)
id sma028360; Thu Mar 27 12:14:50 1997
Message-ID: <33396786.558B at acm.org>
Date: Wed, 26 Mar 1997 12:14:30 -0600
Sender:ietf-request at ietf.org
From: Ken Copeland <kcopelan at acm.org>
Organization: personal mailbox
X-Mailer: Mozilla 4.0b2 (Win95; I)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Re: Memphis hotel situation quite dire!
X-Priority: 3 (Normal)
References: <9703271208.AA04815 at karpov.wfa.digital.ie>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by dfw-ix9.ix.netcom.com id MAA28400
Source-Info: From (or Sender) name not authenticated.
Dermot Tynan wrote:
>=20
> Anne Bennett wrote:
> >
> > I, a secretary, and a travel agent have been trying
> > for a few weeks now to find something better, and have been having no
> > luck.
>=20
> All this talk of availability of rooms at the Memphis Peabody is making
> me extremely nervous. Long after this discussion started, I got
> clearance to travel to IETF, and AmEx Travel Services got me a room at
> the Memphis Peabody without any difficulty. Why do I have this awful
> feeling that I'm booked into the wrong hotel, or that after zillions
> of hours of travelling, the desk clerk will look at me strangely and
> claim to have never heard of me. How many "Memphis Peabody" hotels
> are there? Should I be worried??
> - Der
> --
> Dermot Tynan +353 91 754608
> dtynan at wfa.digital.ie DTN: 822-4608
>=20
> AltaVista Internet Software, Galway, Ireland
Apologies for the earlier post in HTML format. Once more:
I made a reservation for the Memphis Peabody on 12/17 and have a
confirmation number. At the time I made the reservation I guaranteed
with an American Express card. I=A0called back recently to see if they ha=
d
government rates available. I was told they had a computer malfunction
in December and that my reservation was lost. They did offer me an
exorbitant rate for 2 nights though.=20
I ended up making reservations at the Hampton Inn at 1180 Union Ave.
(901-276-1175). I had to also get a rental car, but the combination of
the 2 was cheaper than the conference rate at the Memphis Peabody.=20
If anyone else decides to stay at the Hampton Inn on Union, they are
welcome to ride back and forth with me when I come and go. I=A0will be
checking in Sunday and leaving Friday. - ken=20
--=20
Ken Copeland--------------------Senior Computer Systems Analyst =09
email: kcopelan at acm.org--------U.S. Department of Veterans Affairs
phone: 512-326-6607------------1615 Woodward Street, MC (91D)
fax: 512-326-7445--------------Austin, TX 78772
homepage: http://www.geocities.com/CollegePark/6627
Received: from ietf.org by ietf.org id aa00595; 27 Mar 97 13:26 EST
Received: from gateway.fedex.com by ietf.org id aa00492; 27 Mar 97 13:25 EST
Received: by gateway.fedex.com id AA04672
(InterLock SMTP Gateway 3.0 for ietf at ietf.org);
Thu, 27 Mar 1997 12:22:49 -0600
Message-Id: <199703271822.AA04672 at gateway.fedex.com>
Received: by gateway.fedex.com (Internal Mail Agent-1);
Thu, 27 Mar 1997 12:22:49 -0600
X-Sender: jwc at id4.telecom.fedex.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 27 Mar 1997 12:21:46 -0600
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Joe Cutrell <joe.cutrell at fedex.com>
Subject: IP Addresses for Memphis
Cc: Private_User at fedex.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
Let me know if you will need a specific IP address for your laptop in the
terminal room. If you would like to be offered the address via DHCP, include
your MAC address.
For your info, the network addresses in use will be:
199.81.218.0
199.81.219.0
199.81.220.0
199.81.221.0
199.81.222.0
199.81.223.0
Joe Cutrell joe at fedex.com
Received: from cnri by ietf.org id aa05653; 27 Mar 97 15:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa19348;
27 Mar 97 15:04 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <RAA09483 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 17:33:45 GMT
Message-Id: <199703271733.MAA19916 at gza-client1.cam.ov.com>
X-Mailer: exmh version 1.6.9 8/22/96
To: D.Pinkas at frcl.bull.fr
Cc: CAT-IETF WG <cat-ietf at mit.edu>, linn at cam.ov.com
Subject: Re: SNEGO
In-Reply-To: Your message of "Wed, 26 Mar 1997 08:59:14 PST."
<333955E2.11B4 at frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 27 Mar 1997 12:33:38 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
WG members:
Thanks to Denis for the revised draft now in draft-ietf-cat-snego-03.txt
and for this summary. As a reminder to all, a WG last call
period on the predecessor draft, snego-02, was announced on 13 March
and extends through tomorrow, 28 March. Given that the changes
as described are specific responses to comments included within
this WG last call, I believe that this date applies properly
to snego-03 as well. Other than comments related to optimistic
negotiation, I believe that the only other issue which has been raised
relative to the snego document was Mike Eisler's 15 March
question re negotiation of support for particular QOP values and
confidentiality services. There's been other discussion about the
interaction between OIDs representing negotiated mechanisms and
name processing routines, but I don't believe that these issues bear
on the specifics of the negotiation facility itself.
--jl
> I have revised the SNEGO draft to add the "optimistic" negotiation
> proposed by Peter Brundrett. While doing this, I have taken a slightly
> different option from the one proposed by Peter. This applies for the
> response from the target.
>
> If the optimistic negotiation succeeds and involves the transfer of a
> mechanism specific token back to the initiator (e.g. mutual
> authentication has been requested or the unilateral authentication
> involves the transfer of multiple tokens) the proposal was to carry it
> in the mechanism specific info. I believe it is more appropriate to
> carry it separately in a different data structure: the initiator's
> calling application may then extract directly the inner token and may
> also extract the mechanism specific info (e.g. a chain of certificates)
> in order to process that inner token. Look on page 6 at section 4.2 for
> the structure of NegTokenRep.
>
> NegTokenRep ::= SEQUENCE {
> negResult [0] ENUMERATED { accept (0), reject (1) }
> supportedMech [1] MechType OPTIONAL
> MechSpecInfo [2] OCTET STRING OPTIONAL
> preferredToken [3] OCTET STRING OPTIONAL
>
>
>
> Denis
>
>
>
> --
>
> Denis Pinkas Bull S.A. E-mail : D.Pinkas at frcl.bull.fr
> Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
> 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21
>
Received: from cnri by ietf.org id aa10227; 27 Mar 97 15:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa20721;
27 Mar 97 15:59 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <SAA13021 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 18:56:02 GMT
Date: Thu, 27 Mar 1997 13:55:55 -0500
Message-Id: <9703271855.AA22351 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: marc at cygnus.com, cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Thu, 27 Mar 1997 09:48:54 -0500 (EST),
<199703271448.AA20401 at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Thu, 27 Mar 1997 09:48:54 -0500 (EST)
Maybe not for every conceivable mechanism, but it will definitely work
for more mechanisms than any of the existing "generic" name types.
In addition to the Kerberos-familiy of mechanisms, such a nametype
would also work for SPKM and similar public key based mechanisms,
where hostbased service names DO NOT work.
Why wouldn't host-based service names not work for public-key based
mechanism? You might need a more complicated mapping function to deduce
the correct X.509 name; however, even with Kerberos you need to consult
a database or a configuration file to determine what's the proper
Kerberos realm for a particular host. This is a problem which we've had
to deal with already, and there are solutions.....
- Ted
Received: from cnri by ietf.org id aa14391; 27 Mar 97 16:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22129;
27 Mar 97 16:59 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA15007 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 19:42:45 GMT
To: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: gss_accept_sec_context and gss_display_status
References: <9703271513.AA08452 at us1rmc.bb.dec.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 27 Mar 1997 14:42:42 -0500
In-Reply-To: "John Wray, Digital DPE, 508/486-5210 27-Mar-1997 1009"'s message of Thu, 27 Mar 97 10:14:16 EST
Message-Id: <t534tdxyvd9.fsf at rover.cygnus.com>
Lines: 19
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
"John Wray, Digital DPE, 508/486-5210 27-Mar-1997 1009" <wray at tuxedo.ENET.dec.com> writes:
>> >Since this implies that there is no mechanism, the concept of a
>> >mechanism-specific minor status is meaningless. The mechanism must
>> >return a zero minor status code, and the application should ignore the
>> >minor status code.
>>
>> That sounds right, although it should also be specified that
>> gss_accept_sec_context() should return the unrecognized mech-type
>> OID in this case, as the app will probably want to display it or
>> put in in an audit log. The spec currently leaves this decision to
>> the implementation.
Unfortunately, we can't do that, as returned OID's need to be static.
A random OID from the net is unlikely to be statically available. The
app could pull apart the token header itself, but that's a lot of
work.
Marc
Received: from cnri by ietf.org id aa15773; 27 Mar 97 17:17 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa22608;
27 Mar 97 17:17 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA13936 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 19:15:54 GMT
Message-Id: <199703271915.OAA20285 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: comments re draft-ietf-cat-snego-03.txt
Date: Thu, 27 Mar 1997 14:15:45 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
I've collected a small number of comments on
draft-ietf-cat-snego-03.txt. Some are purely editorial/typographic
(segregated as such below); there are one or two which might raise
technical points depending on interpretation.
p. 3, re excerpted para:
>The target negotiation reply contains the result of the negotiation
>(accept or reject) and, in case of accept, the agreed security
>mechanism along with optional mechanism specific information. It may
>also include the response to the initial security token, when the first
>proposed mechanism has been selected. Not all targets must be able to
>respond to the initial security token for the desired mechanism when
>it is present. The target can simply ignore it and complete the
>negotiation handshake without it. Implementations that can piggyback
>the initial token will be rewarded by faster connection setup.
Suggest clarifying addition to final sentence: ", when interoperating
with peers which also process piggybacked tokens.".
Excerpting from p. 4:
>(d) The GSS-API target deposits the token through invoking
>GSS_Accept_sec_context. The target GSS-API implementation emits a
>negotiation token containing which if any of the proposed mechanisms
>it supports (or has selected).
>
>If the preferred mechanism selected by the target matches the preferred
>mechanism identified by the initiator and the initiator provides a
>preferredToken, the negotiation token response may contain also the
>initial security token from that mechanism.
>
>If the preferred mechanism is accepted, GSS_Accept_sec_context()
>indicates GSS_COMPLETE when unilateral authentication has been
>performed and involves a single token.
Suggest clarifying rewording to avoid possible misinterpretation that
a single-hop unilateral context establishment at the level of the
preferred mechanism will, if selected through negotiation, result in
transfer of only a single token from initiator to target (which can't
be applicable for this case, since the initiator would still be
pending in CONTINUE_NEEDED state):
"If the preferred mechanism is accepted and a unilateral
authentication is performed with a single token at the level of the
preferred mechanism, GSS_Accept_sec_context() indicates GSS_COMPLETE.
A negotiation-level response token is returned to the initiator in all
cases."
>If the proposed mechanism(s) are accepted, or the preferred mechanism
>is accepted but involves multiple exchanges (e.g. mutual
>authentication), then GSS_Accept_sec_context()indicates
>GSS_CONTINUE_NEEDED status.
This seems arbitrary in one aspect: in the event that the preferred
and selected mechanism supports (and the initiator's preferred token
attempts to initiate) a two-token mutual authentication exchange, why
wouldn't GSS_Accept_sec_context() return GSS_COMPLETE at this point in
the transaction rather than requiring a later follow-up token from
initiator to target?
p. 12, para after status code listing: suggest adding, after "may be
negotiated": "with a particular credential".
p. 12, references, #1: is there a reason not to update this citation
from RFC-1508 to RFC-2078?
Pure editorial/typographic:
p. 1, final para, 4th line, "credential" -> "credentials".
p. 4, 1st line, "negotion" -> "negotiation".
p. 7, 4th line, "preferedToken" -> "preferredToken".
p. 11, 1st para, 4th line, "additionnal" -> "additional".
--jl
Received: from cnri by ietf.org id aa17492; 27 Mar 97 17:42 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23145;
27 Mar 97 17:42 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA17008 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 20:25:50 GMT
To: John Linn <linn at cam.ov.com>
Cc: D.Pinkas at frcl.bull.fr, CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SNEGO
References: <199703271733.MAA19916 at gza-client1.cam.ov.com>
From: Marc Horowitz <marc at cygnus.com>
Date: 27 Mar 1997 15:25:07 -0500
In-Reply-To: John Linn's message of Thu, 27 Mar 1997 12:33:38 -0500
Message-Id: <t53zpvpxeu4.fsf at rover.cygnus.com>
Lines: 22
X-Mailer: Gnus v5.3/Emacs 19.34
Precedence: bulk
John Linn <linn at cam.ov.com> writes:
>> Other than comments related to optimistic negotiation, I believe
>> that the only other issue which has been raised relative to the
>> snego document was Mike Eisler's 15 March question re negotiation
>> of support for particular QOP values and confidentiality services.
This might be too little too late, but I don't want to let it go
unsaid.
There is still the objection, raised by myself and others, is that
snego does not provide any protection at all from rollback attacks.
While this sort of attack is impossible to prevent completely, it is
not impossible to make it harder.
While I was lame, and did not issue a protected negotiation draft in
January, I have since written one, and although I did not finish it by
the cutoff (I submitted it at 6pm, not realizing that the cutoff was
at 5pm), I am willing to make it available to the WG (and anyone else)
if people are interested.
Marc
Received: from cnri by ietf.org id aa19480; 27 Mar 97 18:21 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23968;
27 Mar 97 18:21 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA15464 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 19:54:34 GMT
Date: Thu, 27 Mar 1997 14:54:30 -0500
Message-Id: <9703271954.AA22426 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: "John Wray, Digital DPE, 508/486-5210 27-Mar-1997 0941" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
In-Reply-To: John Wray, Digital DPE, 508/486-5210 27-Mar-1997 0941's message
of Thu, 27 Mar 97 10:04:50 EST, <9703271504.AA07842 at us1rmc.bb.dec.com>
Subject: Re: Name type issues
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Thu, 27 Mar 97 10:04:50 EST
From: "John Wray, Digital DPE, 508/486-5210 27-Mar-1997 0941" <wray at tuxedo.ENET.dec.com>
I'm suggesting that the acceptor behavior should be defined in pretty
much the same way. The server administrator should be responsible
for creating the acceptor credential (in kerberos terms, placing the
server key in a key-table). There should be a platform-specific
management operation (analagous to kinit) that lets the GSSAPI within
the server application know where to look for that keytable (and
since I don't think Kerberos has a place within a keytable to set the
"default" key, the platform-specific operation would also have to set
that [but see below]). My suggestion of a configuration file was
simply one way to tell GSSAPI; a simpler way might be to use an
environment variable.
What would the implementation do if the environment variable weren't
set? Would it be acceptable to return GSS_S_NO_CRED in that
cirucmstance?
- Ted
Received: from cnri by ietf.org id aa20832; 27 Mar 97 18:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24499;
27 Mar 97 18:53 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <WAA21016 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 22:06:12 GMT
Message-Id: <199703272205.RAA04991 at thunk.ch.apollo.hp.com>
X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs
To: Marc Horowitz <marc at cygnus.com>
Cc: John Linn <linn at cam.ov.com>, D.Pinkas at frcl.bull.fr,
CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SNEGO
In-Reply-To: marc's message of 27 Mar 1997 15:25:07 -0500.
<t53zpvpxeu4.fsf at rover.cygnus.com>
Date: Thu, 27 Mar 1997 17:05:50 -0500
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
Precedence: bulk
I have to agree with Marc that the adoption of optimistic negotiation
fixes only one of the two problems I have with snego.
The other problem -- the lack of protection in the negotiation -- was
discussed at great length in San Jose, and I came away from that
discussion believing that there was rough consensus that such
protection was both desirable and easy to accomplish.
I'd like to see Marc publish his pnego draft to the WG, and I'm also
going to look into proposing a tweak to snego to allow it to protect
the negotiation.
- Bill
Received: from cnri by ietf.org id aa20868; 27 Mar 97 18:58 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24592;
27 Mar 97 18:58 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <UAA16085 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 20:08:38 GMT
Message-Id: <199703272008.AA16103 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: name type issues
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Thu, 27 Mar 1997 15:08:13 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703271855.AA22351 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 27, 97 01:55:55 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
>
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Thu, 27 Mar 1997 09:48:54 -0500 (EST)
>
> Maybe not for every conceivable mechanism, but it will definitely work
> for more mechanisms than any of the existing "generic" name types.
> In addition to the Kerberos-familiy of mechanisms, such a nametype
> would also work for SPKM and similar public key based mechanisms,
> where hostbased service names DO NOT work.
>
> Why wouldn't host-based service names not work for public-key based
> mechanism? You might need a more complicated mapping function to deduce
> the correct X.509 name; however, even with Kerberos you need to consult
> a database or a configuration file to determine what's the proper
> Kerberos realm for a particular host. This is a problem which we've had
> to deal with already, and there are solutions.....
RFC2025: The SPKM gssapi mechanism
defines GSS_SPKM_NT_USER_NAME, GSS_SPKM_NT_STRING_UID and
GSS_SPKM_NT_MACHINE_UID as optional name forms, it doesn't define
a hostbased service name.
What acutally puzzles me somewhat:
When dealing with X.509(v3) certificates, you don't authenticate Subject
names, but (Certification-Authority, Certificate-Serial-Number).
I don't know anything about this stuff so far, but from what my colleagues
told me, the Subject name may be anything, and it may well be from a different
hierarchy altogether. It doesn't need to be unique either. I hope
that public key based mechanisms and SSL define&require certain policies
on the Subject name, so that authorization based on the subject name
instead of (Certification-Authority, Certificate-Serial-Number)
will not cause any security problems.
PKCS#7 seems to not contain the Subject name in the framing for a
similar reason.
-Martin
Received: from cnri by ietf.org id aa21809; 27 Mar 97 19:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa25497;
27 Mar 97 19:53 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <TAA14680 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 19:35:33 GMT
Message-Id: <199703271934.AA14582 at sap-ag.de>
From: Martin Rex <martin.rex at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
To: "Theodore Y. Ts'o" <tytso at mit.edu>
Date: Thu, 27 Mar 1997 14:34:48 -0500 (EST)
Cc: cat-ietf at mit.edu
In-Reply-To: <9703271855.AA22351 at dcl.MIT.EDU> from "Theodore Y. Ts'o" at Mar 27, 97 01:55:55 pm
Reply-To: Martin.Rex at sap-ag.de
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Theodore Y. Ts'o wrote:
>
> From: Martin Rex <martin.rex at sap-ag.de>
> Date: Thu, 27 Mar 1997 09:48:54 -0500 (EST)
>
> Maybe not for every conceivable mechanism, but it will definitely work
> for more mechanisms than any of the existing "generic" name types.
> In addition to the Kerberos-familiy of mechanisms, such a nametype
> would also work for SPKM and similar public key based mechanisms,
> where hostbased service names DO NOT work.
>
> Why wouldn't host-based service names not work for public-key based
> mechanism? You might need a more complicated mapping function to deduce
> the correct X.509 name; however, even with Kerberos you need to consult
> a database or a configuration file to determine what's the proper
> Kerberos realm for a particular host. This is a problem which we've had
> to deal with already, and there are solutions.....
(1) because there is no mapping, no hostnames and no lookup (not even
a user database) for certain implementations.
(2) because it doesn't work for applications that do not use hostnames
for opening the transport connection. This even applies to
Kerberos if I choose to (ab)use it in reversed operation.
For some implementations you may carry around your personalized security
environment on a smartcard, sit down somewhere and connect to your home
site across a dozen firewalls. There won't be a local configuration.
The local admin will show you a "way out", he will point you one or more
alternative "ways across", you will have to use your knowledge about
the "way in" just to establish the transport link, and then you will
use the service name as the target. NO HOSTNAMES! IP/TCP is not the only
way to travel, and GSS-API is supposed to be transport independent!
Use your imagination.
Don't make assumptions.
;-)
-Martin
Received: from cnri by ietf.org id aa22538; 27 Mar 97 20:41 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26411;
27 Mar 97 20:41 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <XAA25875 at pad-thai.cam.ov.com>; Thu, 27 Mar 1997 23:37:10 GMT
Message-Id: <9703272337.AA01244 at dns.sprintcorp.com>
From: "Ashraf Madoukh - (913) 534-3137" <ashraf at dns.sprintcorp.com>
To: cat-ietf at mit.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: unsubscribe
Date: Thu, 27 Mar 1997 17:36:50 -0600
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: bulk
unsubscribe
Ashraf Madoukh
Received: from cnri by ietf.org id aa01116; 27 Mar 97 23:36 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa00711;
27 Mar 97 23:36 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <CAA03316 at pad-thai.cam.ov.com>; Fri, 28 Mar 1997 02:59:35 GMT
Message-Id: <199703280259.SAA05154 at imo.plaintalk.bellevue.wa.us>
Content-Type: text/plain
Mime-Version: 1.0 (NeXT Mail 3.3 v118.2)
From: Dennis Glatting <dennis.glatting at plaintalk.bellevue.wa.us>
Date: Thu, 27 Mar 97 18:59:17 -0800
To: CAT-IETF WG <cat-ietf at mit.edu>
Subject: Re: SNEGO
Reply-To: dennis.glatting at plaintalk.bellevue.wa.us
References: <199703272205.RAA04991 at thunk.ch.apollo.hp.com>
Precedence: bulk
> Date: Thu, 27 Mar 1997 17:05:50 -0500
> From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
>
> [ snip ]
>
> I'd like to see Marc publish his pnego draft to the WG...
>
Agreed.
-dpg
Received: from cnri by ietf.org id aa02001; 28 Mar 97 0:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02024;
28 Mar 97 0:53 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <DAA05288 at pad-thai.cam.ov.com>; Fri, 28 Mar 1997 03:56:24 GMT
Date: Thu, 27 Mar 1997 22:56:16 -0500
Message-Id: <9703280356.AA22561 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu
In-Reply-To: Martin Rex's message of Thu, 27 Mar 1997 14:34:48 -0500 (EST),
<199703271934.AA14582 at sap-ag.de>
Subject: Re: default creds (was Re: name type issues)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
From: Martin Rex <martin.rex at sap-ag.de>
Date: Thu, 27 Mar 1997 14:34:48 -0500 (EST)
(1) because there is no mapping, no hostnames and no lookup (not even
a user database) for certain implementations.
If someone didn't implement the mapping function for Kerberos, we'd have
the same problem with host-based name types as well. I will claim that
an implementation that doesn't have this mapping function is missing a
significant piece of functionality which makes it pretty much useless.
(How do you know where you're going if you can't name it?)
If you think users are going to type and configure potentially thousands
of arbitrary X.500 DN's each time they want to access a some
service on the net, you've got another think coming.....
For some implementations you may carry around your personalized security
environment on a smartcard, sit down somewhere and connect to your home
site across a dozen firewalls. There won't be a local configuration.
The local admin will show you a "way out", he will point you one or more
alternative "ways across", you will have to use your knowledge about
the "way in" just to establish the transport link, and then you will
use the service name as the target. NO HOSTNAMES! IP/TCP is not the only
way to travel, and GSS-API is supposed to be transport independent!
GSSAPI may be transport independent, but in order for a system to be
useful, there *must* be a transport-dependent way of naming your
targets. Otherwise, when you try to access some target, you'll have to
name it twice --- once for your transport layer (whatever it is), and
once for your security system. Users aren't going to be particularly
happy with that....
- Ted
Received: from ietf.org by ietf.org id aa04726; 28 Mar 97 2:37 EST
Received: from cnri by ietf.org id aa04500; 28 Mar 97 2:30 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03421;
28 Mar 97 2:30 EST
Received: from ha1.ntr.net by venera.isi.edu (5.65c/5.61+local-26)
id <AA16571>; Thu, 27 Mar 1997 23:27:47 -0800
Received: from mail.ntr.net (ACCS-AS38-DP14.ATLN.grid.net [206.80.179.126]) by ha1.ntr.net (NTR*NET 2.1.0) with SMTP id CAA23599; Fri, 28 Mar 1997 02:24:54 -0500 (EST)
Sender:ietf-request at ietf.org
From: mail at mkljk.com
Received: from mailhost.mkljk.com (alt.mkljk.com (202.8.92.33)) by mkljk.com (8.8.5/8.6.5) with SMTP id GAA01423 for <mail at mkljk.com>; Fri, 28 Mar 1997 02:22:12 -0600 (EST)
To: mail at mkljk.com
Message-Id: <801496278473.HHG25220 at mkljk.com>
Date: Fri, 28 Mar 97 02:22:12 EST
Subject: Mutual Link Proposal
Reply-To: mail at mkljk.com
X-Pmflags: 128 0
X-Uidl: 4992584441l30uhg3h250lbn362f2d4t
Comments: Authenticated sender is <mail at mkljk.com>
Source-Info: From (or Sender) name not authenticated.
Hello, my name is Guy W. Rochefort, President of Dino Jump International.
I found your address through YAHOO. Dino Jump International are specialists
in manufacturing and distribution of Interactive Inflatables worldwide. My
lines have been featured in Walt Disney productions, NFL shows, and NBA
events. Our product lines include moonwalkers, bouncehouses, and castles.
I am interested in mutual links on our respective webpages beneficial to
both our businesses. Additionally, I am interested in opening dialog on
mutual beneficial business dealings as far as wholesale/retail efforts for
manufactured products from my factory and/or resale distribution at
competitive pricing. Please come visit my site at http://www.dinojump.com
or email sales1 at dinojump.com or call me at 1-800-570-3466 or 619-754-5186.
If this email is intrusive I apologize and you will not hear further from
me. Thank you again and I am looking forward to doing business with you.
Guy
Received: from cnri by ietf.org id aa06491; 28 Mar 97 3:33 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa04364;
28 Mar 97 3:33 EST
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id DAA11810
for uri-out; Fri, 28 Mar 1997 03:21:45 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with SMTP id DAA11789;
Fri, 28 Mar 1997 03:21:37 -0500 (EST)
Received: from www44.inria.fr by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA14157 (mail destined for urn-ietf at services.bunyip.com); Fri, 28 Mar 97 03:21:33 -0500
Received: by www44.inria.fr (8.8.5/8.6.12) id JAA20297; Fri, 28 Mar 1997 09:21:30 +0100 (MET)
To: urn-ietf at bunyip.com
Path: usenet
From: Dan Connolly <connolly at w3.org>
Newsgroups: w3c.urn
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
Date: Fri, 28 Mar 1997 02:21:28 -0600
Organization: World Wide Web Consortium
Lines: 49
Message-Id: <333B7F88.914876B at w3.org>
References: <1997Mar26.224102.9231 at sophia.inria.fr>
Nntp-Posting-Host: beach.w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
To: Patrik Faltstrom <paf at swip.net>, uri at bunyip.com, ietf-url at imc.org
Sender: owner-uri at bunyip.com
Precedence: bulk
I'm trying to get up to speed on all the UR* drafts
and such for Memphis. Some of this stuff is pretty exciting
(NAPTR and RRs and all that) but some of it is confusing.
First of all, what's the relationship between mailing
lists and charters?
urn-ietf at bunyip.com ->
http://www.ietf.org/html.charters/urn-charter.html
uri at bunyip.com -->
??? (defunct URI WG; anything else?)
ietf-url at imc.org
??? (new URL syntax/process WG? Is this
a real WG? It's not listed at:
http://www.ietf.org/html.charters/wg-dir.html)
Now... about this document:
Patrik Faltstrom wrote:
> draft-ietf-urn-nid-req-01.txt
> Namespace Identifier Requirements for URN Services
> Introduction:
> =============
>
> The Uniform Resource Name (URN) Working Group has defined mechanisms
> for both the syntax [4] and resolution of URNs [1,2]. An framework
> for URN discovery systems has also been outlined [3]. This draft
> discusses and recommends the requirements for entities that wish
> to act as Namespace Identifiers (NIDs) within the URN system.
Making new NIDs seems exactly analagous to the process of making
new URL schemes.
Compare with:
------------
http://www.imc.org/draft-masinter-url-process
This document provides guidelines for the definition of new URL
schemes and describes the process by which they are registered.
------------
Is it really necessary/useful to go through this exercise twice?
--
Dan Connolly, W3C Architecture Domain Lead
<connolly at w3.org> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
Received: from cnri by ietf.org id aa06588; 28 Mar 97 3:43 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa04527;
28 Mar 97 3:43 EST
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id DAA12603
for uri-out; Fri, 28 Mar 1997 03:33:29 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with SMTP id DAA12598;
Fri, 28 Mar 1997 03:33:26 -0500 (EST)
Received: from nix.swip.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA14226 (mail destined for uri at services.bunyip.com); Fri, 28 Mar 97 03:33:24 -0500
Received: from localhost (paf at localhost)
by nix.swip.net (8.8.2/8.8.2) with SMTP
id JAA13957;
Fri, 28 Mar 1997 09:33:15 +0100 (MET)
Date: Fri, 28 Mar 1997 09:33:14 +0100 (MET)
From: Patrik Faltstrom <paf at swip.net>
To: Dan Connolly <connolly at w3.org>
Cc: uri at bunyip.com, ietf-url at imc.org, urn-ietf at bunyip.com
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
In-Reply-To: <333B7F88.914876B at w3.org>
Message-Id: <Pine.SUN.3.95.970328093057.12871J-100000 at nix.swip.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-uri at bunyip.com
Precedence: bulk
On Fri, 28 Mar 1997, Dan Connolly wrote:
> > Introduction:
> > =============
> >
> > The Uniform Resource Name (URN) Working Group has defined mechanisms
> > for both the syntax [4] and resolution of URNs [1,2]. An framework
> > for URN discovery systems has also been outlined [3]. This draft
> > discusses and recommends the requirements for entities that wish
> > to act as Namespace Identifiers (NIDs) within the URN system.
>
> Making new NIDs seems exactly analagous to the process of making
> new URL schemes.
>
> Compare with:
>
> ------------
> http://www.imc.org/draft-masinter-url-process
> This document provides guidelines for the definition of new URL
> schemes and describes the process by which they are registered.
> ------------
I think I and Renato should have looked at this document closer before
typing in the text we wrote. I think personally that the process can be
handled the same way. I.e. handle a new NID as a new URL-scheme.
> Is it really necessary/useful to go through this exercise twice?
A namespace is definitely not the same thing as a URL scheme. Two
different things, but the _process_ can be similar, just like the
processes defined for MIME-types.
Patrik
Received: from cnri by ietf.org id aa06927; 28 Mar 97 4:10 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa04970;
28 Mar 97 4:10 EST
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id EAA13244
for uri-out; Fri, 28 Mar 1997 04:01:41 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with SMTP id EAA13222;
Fri, 28 Mar 1997 04:01:34 -0500 (EST)
Received: from www44.inria.fr by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA14290 (mail destined for urn-ietf at services.bunyip.com); Fri, 28 Mar 97 04:01:30 -0500
Received: by www44.inria.fr (8.8.5/8.6.12) id KAA21229; Fri, 28 Mar 1997 10:01:30 +0100 (MET)
To: urn-ietf at bunyip.com
Path: usenet
From: Dan Connolly <connolly at w3.org>
Newsgroups: w3c.urn
Subject: Re: [URN] I-D ACTION:draft-ietf-urn-naptr-04.txt
Date: Fri, 28 Mar 1997 03:01:27 -0600
Organization: World Wide Web Consortium
Lines: 53
Message-Id: <333B88E7.441B19E0 at w3.org>
References: <1997Mar24.170639.8002 at sophia.inria.fr>
Nntp-Posting-Host: beach.w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
To: uri at bunyip.com
Sender: owner-uri at bunyip.com
Precedence: bulk
Internet-Drafts at ietf.org wrote:
> Title : Resolution of Uniform Resource Identifiers using the
> Domain Name System
> Author(s) : R. Daniel, M. Mealling
> Filename : draft-ietf-urn-naptr-04.txt
> Pages : 14
> Date : 03/21/1997
This NAPTR stuff is cool: it's an interesting point in
the design space between the old path: scheme and MX
records.
A few comments:
>In conjunction
>with a long TTL for *.urn.net records, the average number of probes to
>DNS for resolving DUNS URNs would approach one.
I would very much like to see the full argument behind that
sentence -- it appeals to my intuition, but I want to
study the details. Are they available somewhere?
> sprintf(key, "%s.urn.net", extractNS(URN));
er... where's the specificaiton of extractNS? That seems
absolutely critical to the whole thing, and yet I don't
see it specified anywhere except the three examples
(which I assume are non-normative, per standards tradition).
Based on the examples, the algorithm seems to be
"grab the stuff before the :; if it's urn:,
grab everything up to the _next_ :."
Why the special case for the urn: prefix? I seem to
be asking that a lot. But I'm just applying occam's
razor: unless there's a darn good reason for special-casing urn:,
we should not.
Hmm... whoever administers urn.net seems to be able
to introduce new URL schemes at will. That should
certainly be discussed in the URL process document!
I thought I
saw a document specifying the policies for urn.net,
but I can't seem to find it now.
--
Dan Connolly, W3C Architecture Domain Lead
<connolly at w3.org> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
Received: from cnri by ietf.org id aa07091; 28 Mar 97 4:23 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa05186;
28 Mar 97 4:23 EST
Received: (from daemon at localhost)
by services.bunyip.com (8.8.5/8.8.5) id EAA13309
for uri-out; Fri, 28 Mar 1997 04:13:30 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with SMTP id EAA13304;
Fri, 28 Mar 1997 04:13:26 -0500 (EST)
Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA14340 (mail destined for uri at services.bunyip.com); Fri, 28 Mar 97 04:13:25 -0500
Received: from beach.w3.org (beach.w3.org [207.8.37.250])
by beach.w3.org (8.8.4/8.8.4) with SMTP
id DAA12169; Fri, 28 Mar 1997 03:13:23 -0600
Message-Id: <333B8BB2.7F4108BC at w3.org>
Date: Fri, 28 Mar 1997 03:13:22 -0600
From: Dan Connolly <connolly at w3.org>
Organization: World Wide Web Consortium
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: Patrik Faltstrom <paf at swip.net>
Cc: uri at bunyip.com, ietf-url at imc.org, urn-ietf at bunyip.com
Subject: Re: [URN] draft-ietf-urn-nid-req-01.txt
References: <Pine.SUN.3.95.970328093057.12871J-100000 at nix.swip.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-uri at bunyip.com
Precedence: bulk
Patrik Faltstrom wrote:
> > Is it really necessary/useful to go through this exercise twice?
>
> A namespace is definitely not the same thing as a URL scheme. Two
> different things, but the _process_ can be similar, just like the
> processes defined for MIME-types.
Hmm... argument by assertion. I can play that game too:
A namespace definitely IS the same thing as a URL scheme.
I don't have any logical argument, but I can cite the
intent of the designer of URLs:
-------------
http://www.w3.org/pub/WWW/DesignIssues/Naming.html
TimBL, circa 1990
The WWW scheme uses a prefix to give the addressing sub-scheme, and
then a syntax dependent on the prefix used, in order to be open to any
new naming systems.
--------------
See also, RFC1630 (informational) and TimBL's more recent writings:
http://www.w3.org/pub/WWW/DesignIssues/NameMyth.html
including a very intersting and relavent bit
about "Naming: A social and contracual Issue."
As a trump card, I'll play occam's razor, which places
the burden on you to show that they're different.
--
Dan Connolly, W3C Architecture Domain Lead
<connolly at w3.org> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
Received: from cnri by ietf.org id aa07866; 28 Mar 97 5:36 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06173;
28 Mar 97 5:36 EST
Received: (daemon at localhost) by pad-thai.cam.ov.com (8.8.5/)
id <IAA17412 at pad-thai.cam.ov.com>; Fri, 28 Mar 1997 08:35:10 GMT
Date: Fri, 28 Mar 1997 03:35:05 -0500
Message-Id: <9703280835.AA25738 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: cat-ietf at mit.edu
Subject: Potential problem in specificaion of the exported name object...
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
In the specification of the exported name object in RFC 2078, we
neglected to specify the byte order of the integer length fields:
Length Name Description
2 TOK_ID Token Identifier
For exported name objects, this
must be hex 04 01.
2 MECH_OID_LEN Length of the Mechanism OID
MECH_OID_LEN MECH_OID Mechanism OID, in DER
4 NAME_LEN Length of name
NAME_LEN NAME Exported name; format defined in
applicable mechanism draft.
I am coding my implementation to use network byte order (i.e., most
significant byte first), but we really should make this explicit. Are
there others which may have chosen to use least significant byte first?
If so, what was your reasoning for choosing what you did?
- Ted
Received: from ietf.org by ietf.org id aa13442; 28 Mar 97 10:04 EST
Received: from ietf.ietf.org by ietf.org id aa12908; 28 Mar 97 10:02 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-thomas-ipv6-esd-00.txt
Date: Fri, 28 Mar 1997 10:02:33 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703281002.aa12908 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Use of End System Designators in IPv6
Author(s) : M. Thomas
Filename : draft-thomas-ipv6-esd-00.txt
Pages : 6
Date : 03/27/1997
There is a proposal to split unicast IPv6 addresses into two 8 byte
quantities. The first 8 bytes will contain routing information which is
used to reach a subnetwork. The last 8 bytes will contain a identifier of
a node on that subnet. This identifier is globally unique and is called an
End System Designator (ESD). The ESD (not the entire 16 byte address) will
be used to accept packets and identify connections, among other things.
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-thomas-ipv6-esd-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-thomas-ipv6-esd-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-thomas-ipv6-esd-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: <19970327161423.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-thomas-ipv6-esd-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-thomas-ipv6-esd-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970327161423.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13131; 28 Mar 97 10:04 EST
Received: from ietf.ietf.org by ietf.org id aa12270; 28 Mar 97 9:58 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-atm-support-03.txt, .ps
Date: Fri, 28 Mar 1997 09:58:00 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9703280958.aa12270 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 : IP Integrated Services with RSVP over ATM
Author(s) : S. Berson, L. Berger
Filename : draft-ietf-issll-atm-support-03.txt, .ps
Pages : 24
Date : 03/26/1997
This draft describes a method for providing IP Integrated Services with
RSVP over ATM switched virtual circuits (SVCs). It provides an overall
approach to the problem as well as a specific method for running over
today's ATM networks. There are two parts of this problem. This draft
provides guidelines for using ATM VCs with QoS as part of an Integrated
Services Internet. A related draft[6] describes service mappings between
IP Integrated Services and ATM services.
Authors' Note
The postscript version of this document contains figures that are not
included in the text version, so it is best to use the postscript version.
Figures will be converted to ASCII in a future version.
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&qu 
