job opportunity at InterDigital
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
job opportunity at InterDigital
- To: end2end-interest at isi.edu, f-troup at aurora.cis.upenn.edu, ietf at isi.edu, ir-l%uccvma.bitnet at cunyvm.cuny.edu, rem-conf-request at es.net, rem-conf at es.net, sig11 at roses.stanford.edu, sound at pascal.acm.org, tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com
- Subject: job opportunity at InterDigital
- From: Zhensheng Zhang <zhang at ctr.columbia.edu>
- Date: Mon, 1 Aug 1994 23:06:22 -0400
- Sender: ietf-archive-request at IETF.CNRI.Reston.VA.US
InterDigital
Join the team that's developing the communication technology of the future.
We are a leading edge, high technology wireless communications firm with
proven technical leadership skills.
Experience in Communication System Engineering is required, with an emphasis
on Spread Spectrum and Cellular Telephony. The ideal candidate shall have
background in one or more of the following area: Communication Nets and
Protocols, ATM, Switching and Mobility Management, Systems Analysis and
Simulation, Detection, Estimation and Filtering, Operation Research. Our
aggressive technical agenda requires motivated people with excellent
communications skills. Commercial product development experience is desired.
MS or equivalent experience required, Ph.D preferred.
Individuals please send resume to
Dr. Emmannuel Kanterakis
InterDigital Communications Corporation
833 Northern Boulevard
Great Neck, NY 11021
Fax: (516) 466-0766
Equal Opportunity Employer
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21049;
2 Aug 94 0:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21037;
2 Aug 94 0:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24231;
2 Aug 94 0:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21019;
2 Aug 94 0:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20934;
1 Aug 94 23:59 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa24191;
1 Aug 94 23:59 EDT
Received: from glare.cisco.com by venera.isi.edu (5.65c/5.61+local-14)
id <AA12602>; Mon, 1 Aug 1994 20:54:03 -0700
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA09843; Mon, 1 Aug 1994 20:53:25 -0700
Message-Id: <199408020353.UAA09843 at glare.cisco.com>
X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol
To: Zhensheng Zhang <zhang at ctr.columbia.edu>
Cc: end2end-interest at isi.edu, f-troup at aurora.cis.upenn.edu, ietf at isi.edu,
ir-l%uccvma.bitnet at cunyvm.cuny.edu, rem-conf-request at es.net,
rem-conf at es.net, sig11 at roses.stanford.edu, sound at pascal.acm.org,
tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com
Subject: Re: job opportunity at InterDigital
In-Reply-To: Your message of "Mon, 01 Aug 1994 23:06:22 EDT."
<199408020306.XAA21834 at gauss.ctr.columbia.edu>
Date: Mon, 01 Aug 1994 20:53:24 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Getchell <getchell at cisco.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02623;
2 Aug 94 9:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02615;
2 Aug 94 9:10 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05467;
2 Aug 94 9:10 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA21566 at pad-thai.aktis.com>; Tue, 2 Aug 1994 08:49:56 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA02778; Tue, 2 Aug 94 08:48:33 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <07244-0 at relay1.pipex.net>; Tue, 2 Aug 1994 13:47:57 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA20673; Tue, 2 Aug 94 13:50:18 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA13929;
Tue, 2 Aug 94 13:47:29 BST
Message-Id: <9408021249.AA02505 at getafix.oasis.icl.co.uk>
Date: Tue, 2 Aug 94 13:49:02 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: Re: Query re work on GSS-API extensions for store-and-fwd support
To: rsalz at osf.org
Cc: cat-ietf at mit.edu
Cc: gomberg at smiley.mitre.org
> >We need to include a model and interfaces and mechanisms to cover the
> >store and forward cases.
>
> I'm sure nobody will be surprised when they read that I'm about to mention
> DCE. :-) DCE RPC is currently on-track to be the ISO-standard RPC, albeit
Is this relevant to the SC21/WG8 workitem referred to? I understood
it was for protocol independent security services.
> without security. The DCE Security Spec is on X/Open fast-track, and I
When was the DCE Security Spec resubmitted to X/Open? Sorry, I may
have missed the announcement. I thought it had been pulled, and
was still being revised due to the volume of revisions?
> would not be surprised if it made it into ISO at some point.
- pvm
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02924;
2 Aug 94 9:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02915;
2 Aug 94 9:30 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa06299;
2 Aug 94 9:30 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA21951 at pad-thai.aktis.com>; Tue, 2 Aug 1994 09:08:58 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA03675; Tue, 2 Aug 94 09:07:39 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA21947 at pad-thai.aktis.com>; Tue, 2 Aug 1994 09:08:53 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA08657; Tue, 2 Aug 94 09:08:51 EDT
Message-Id: <9408021308.AA08657 at winkl.aktis.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: rsalz at osf.org, cat-ietf at mit.edu, gomberg at smiley.mitre.org,
linn at cam.ov.com
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Tue, 02 Aug 1994 13:49:02 -0000."
<9408021249.AA02505 at getafix.oasis.icl.co.uk>
Date: Tue, 02 Aug 1994 09:08:49 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
I was also somewhat confused by the context of Rich's message. If
there's a direct relationship between the selection of a particular
RPC protocol and interface primitives for store-and-forward
messaging support (which was the focus of Dave Gomberg's query),
it's escaping me.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05572;
2 Aug 94 11:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05564;
2 Aug 94 11:43 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa09239;
2 Aug 94 11:43 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <LAA24833 at pad-thai.aktis.com>; Tue, 2 Aug 1994 11:13:38 -0400
Received: from mwunix.mitre.org by MIT.EDU with SMTP
id AA11984; Tue, 2 Aug 94 11:12:06 EDT
Received: from smiley.mitre.org.sit (smiley.mitre.org [128.29.140.20]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id LAA19755; Tue, 2 Aug 1994 11:11:54 -0400
Received: from [128.29.78.21] (gomberg-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1)
id AA24358; Tue, 2 Aug 94 11:12:34 EDT
Message-Id: <9408021512.AA24358 at smiley.mitre.org.sit>
X-Sender: gomberg at smiley.mitre.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 2 Aug 1994 11:13:08 -0500
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk, rsalz at osf.org
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Gomberg <gomberg at mitre.org>
Subject: RE: Re: Query re work on GSS-API extensions for store-and-fwd support
Cc: cat-ietf at mit.edu
At 1:49 PM 8/2/94 +0100, p.v.mcmahon.rea0803 at oasis.icl.co.uk wrote:
>> >We need to include a model and interfaces and mechanisms to cover the
>> >store and forward cases.
>>
>> I'm sure nobody will be surprised when they read that I'm about to mention
>> DCE. :-) DCE RPC is currently on-track to be the ISO-standard RPC, albeit
>
>Is this relevant to the SC21/WG8 workitem referred to? I understood
>it was for protocol independent security services.
Let me speak to the scope of the WG8 project. There are actually several
facets to it, only one of which is to provide "protocol independent
security services". We are interested in showing how applications can use
various
security services/mechanisms through standard interfaces, using standard
protocols. There are really three different APIs in our initial model,
each
of which hides something else from the stuff above it. (Before anyone has
a heart attack, not all the APIs are necessarily used in every case.)
One interface hides all but generic services. The next (the GSS-API) hides
the mechanism (mechanism is used here in the GSS-API sense, which is different
than the IS 7498-2 sense). The last APIs (purposefully plural here) are those
that get called locally to get a specific function performed for the mechanism
invoked by the GSS-API. (There might be several of these for a particular
mechanism.) We aren't concerned with the protocols that might be used by
these functions, but that doesn't preclude someone from using standard
protocols. We are concerned particularly with the protocols used by the
entities called through the service independent API (or by the application
itself if it invokes the GSS-API itself). Here we are proposing that the
choice be the GULS SESE. Not all the details are clear yet and things may
change as we go, but that is the shape of things at the moment. For those
of you who may be interested in seeing the current state of things (quite
rough, I assure you), when the editor (Dale Walters at NIST) gets the output
of the Southampton meeting distributed in electronic form, I will be willing
to forward it to you. Send me an e-mail request. (The plan is to distribute
it in MS Word for Windows 2.0 RTF, uuencoded. I know not everyone can handle
this, and if enough of you ask, I might consider converting it to PostScript.)
Dave Gomberg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11234;
2 Aug 94 14:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11225;
2 Aug 94 14:41 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa13451;
2 Aug 94 14:41 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA29134 at pad-thai.aktis.com>; Tue, 2 Aug 1994 14:18:30 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vipin.Samar at eng.sun.com
Received: from [192.9.9.1] by MIT.EDU with SMTP
id AA22367; Tue, 2 Aug 94 13:38:15 EDT
Received: from Eng.Sun.COM (mxchange.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AB23276; Tue, 2 Aug 94 10:37:40 PDT
Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (8.6.9/SMI-4.1)
id KAA13922; Tue, 2 Aug 1994 10:37:40 -0700
Received: from tiny.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
id AA24538; Tue, 2 Aug 1994 10:37:39 -0700
Received: by tiny.Eng.Sun.COM (5.x/SMI-SVR4)
id AA05139; Tue, 2 Aug 1994 10:38:13 -0700
Date: Tue, 2 Aug 1994 10:38:13 -0700
Message-Id: <9408021738.AA05139 at tiny.Eng.Sun.COM>
To: cat-ietf at mit.edu
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
X-Sun-Charset: US-ASCII
linn at cam.ov.com writes:
>My view is that store-and-forward
>protection facilities (probably operating directly with credentials
>rather than security contexts, given that security contexts aren't
>multicast and are designed for association-oriented, timely delivery
>environments) would be well-formed additions for use with GSS-API, but
>I don't know what level of interest exists within CAT or the broader
>IETF to pursue this. Comments hereby solicited.
>
I agree that it is a good idea to add this to GSSAPI for the reasons
you listed above.
On a more practical side of things, if GSS-API is not
extended to support store and forward types of facilities, others
(such as this ISO WG) would certainly step up and introduce yet
another entirely new set of APIs to solve this problem; and this
should be avoided to reduce confusion.
vipin
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14860;
2 Aug 94 18:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14852;
2 Aug 94 18:31 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa18830;
2 Aug 94 18:31 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <SAA04765 at pad-thai.aktis.com>; Tue, 2 Aug 1994 18:10:35 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA19663; Tue, 2 Aug 94 18:09:15 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <01762-0 at relay1.pipex.net>; Tue, 2 Aug 1994 23:08:53 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA27634; Tue, 2 Aug 94 23:11:22 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA20307;
Tue, 2 Aug 94 23:08:37 BST
Message-Id: <9408022210.AA01725 at getafix.oasis.icl.co.uk>
Date: Tue, 2 Aug 94 23:10:08 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
To: vipin.samar at eng.sun.com
Cc: cat-ietf at mit.edu
> >I don't know what level of interest exists within CAT or the broader
> >IETF to pursue this. Comments hereby solicited.
>
> I agree that it is a good idea to add this to GSSAPI for the reasons
> you listed above.
>
> On a more practical side of things, if GSS-API is not
> extended to support store and forward types of facilities, others
> (such as this ISO WG) would certainly step up and introduce yet
> another entirely new set of APIs to solve this problem; and this
> should be avoided to reduce confusion.
I too think that such an interface would be a good thing. But, being
devil's advocate, what Internet applications would be potential
consumers of such APIs? While EDI and email are two obvious candidates,
doesn't the existence of existing specifications and/or implementations of
store-and-forward security embedded within such applications (PEM, PGP,
X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a
new generic, and possibly non-interoperable, paradigm for implementing
the same services?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15875;
2 Aug 94 19:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15862;
2 Aug 94 19:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20271;
2 Aug 94 19:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15847;
2 Aug 94 19:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15704;
2 Aug 94 19:44 EDT
Received: from pluto.dss.com by CNRI.Reston.VA.US id aa20105; 2 Aug 94 19:44 EDT
Received: by pluto.dss.com (4.1/SMI-4.0)
id AA20981; Tue, 2 Aug 94 19:39:42 EDT
Date: Tue, 2 Aug 94 19:39:42 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joachim Martillo <martillo at pluto.dss.com>
Message-Id: <9408022339.AA20981 at pluto.dss.com>
To: big-internet at munnari.oz.au
Cc: ietf at CNRI.Reston.VA.US, martillo at pluto.dss.com
Subject: Re: IPng recommendation
After noticing some of the discussion of IPng criteria, I ftp'd over
the criteria. Exactly how to interpret this document is unclear.
ISO, CCITT, ANSI and IEEE documents can have problems, but the authors
usually are attempting to be serious and precise. This document seems
to attempt humor with cutesy section titles, but calculations of a
need to support 10**15 end-hosts (about 250,000 per human) make the
document rather risible.
>INTERNET DRAFT
>Technical Criteria for Choosing
>IP:The Next Generation (IPng)
>draft-kastenholz-ipng-criteria-02.txt
>25 May 1994
>Frank Kastenholz
>FTP Software, Inc
>2 High Street
>North Andover, Mass 01845-2620 USA
>kasten at ftp.com
>Craig Partridge
>BBN Systems and Technologies
>craig at aland.bbn.com
>1. Introduction
>This memo presents a set of criteria that the authors' believe
>should be used to help evaluate protocols being proposed for
>adoption as the next generation of IP.
>4.2. One Protocol to Bind Them All
>One of the most important aspects of The Internet is that it
>provides global IP-layer connectivity. The IP layer provides
>the point of commonality among all of the nodes on the
>Internet. In effect, the main goal of the Internet is to
>provide an IP Connectivity Service to all who wish it.
>This does NOT say that the Internet is a One-Protocol
>Internet. The Internet is today, and shall remain in the
>future, a Multi-Protocol Internet. Multi-Protocol operations
>are required to allow for continued testing, experimentation,
>and development and because service providers' customers
>clearly want to be able to run protocols such as CLNP, DECNET,
>and Novell over their Internet connections.
This point is reasonable because as a manufacturing regime the IETF
should not produce standards
1) which cause problems in a multiprotocol environment,
2) which favor IP to the detriment of multiprotocol interworking or
3) which in other ways discourage cost-effective, productive use of
multiprotocol internetworks.
>5.3. Performance
>CRITERION
>A state of the art, commercial grade router must be able
>to process and forward IPng traffic at speeds capable of
>fully utilizing common, commercially available, high-
>speed media at the time. Furthermore, at a minimum, a
>host must be able to achieve data transfer rates with
>IPng comparable to the rates achieved with IPv4, using
>similar levels of host resources.
Since poor router performance can affect a whole internet rather than
simply an individual host, the criterion should have concentrated
attention on router performance. After all, it is conceiveable that
an individual host with a single interface can achieve full bandwidth
utilization but the performance of a router with many interfaces might
suffer tremendously from misdesign of a next generation IP. The
converse case seems unlikely where a router with many interfaces might
achieve full bandwidth utilization while an individual host with a
single interface might perform miserably.
>DISCUSSION
>Network media speeds are constantly increasing. It is
>essential that the Internet's switching elements
>(routers) be able to keep up with the media speeds.
>We limit this requirement to commercially available
>routers and media. If some network site can obtain a
>particular media technology "off the shelf", then it
>should also be able to obtain the needed routing
>technology "off the shelf." One can always go into some
>laboratory or research center and find newer, faster,
>technologies for network media and for routing. We do
>believe, however, that IPng should be routable at a speed
>sufficient to fully utilize the fastest available media,
>though that might require specially built, custom,
>devices.
This comment suggests that the new address structure should enable the
quickest possible route look-up. The quickest possible route look-up
means that a network number should conveniently correspond to a
natural register size on common communications computers and that
accesses to slower processor external memory should be minimized.
Such needs and 16 byte addresses are hard to reconcile with current
router technology.
>We expect that more and more services will be available
>over the Internet. It is not unreasonable, therefore, to
>expect that the ratio of "local" traffic (i.e. the
>traffic that stays on one's local network) to "export"
>traffic (i.e. traffic destined to or sourced from a
>network other than one's own local network) will change,
>and the percent of export traffic will increase.
This observation is not obviously true. As file servers, database
servers, multimedia servers and other network resources become
cheaper, such resources are likely to become increasingly available
locally. While export traffic apparently increases absolutely, the
ratio of export traffic to local traffic actually decreases.
Anticipating such results in 1987-1988, Tony Bono and I designed the
Constellation Series packet switches to be configureable as
shake-and-bake IMPs, wire-speed LAN switches, fully powered-bridges
and multiprotocol routers or any mixed combination thereof in order to
serve all possible network needs. IPng must be conducive of such
designs in order to meet user needs flexibly and cost-effectively. A
concentration on export traffic in the design of IPng would be
misguided.
>We note that the host performance requirement should not
>be taken to imply that IPng need only be as good as IPv4.
>If an IPng candidate can achieve better performance with
>equivalent resources (or equivalent transfer rates with
>fewer resources) vis-a-vis IPv4 then so much the better.
>We also observe that many researchers believe that a
>proper IPng router should be capable of routing IPng
>traffic over links at speeds that are capable of fully
>utilizing an ATM switch on the link.
ATM is yet another fad technology whose fad may be approaching its
end. I have recently read that several companies which had started
ATM development efforts had abandoned these efforts as pointless. A
better targer might be wire-speed routing in the context of a LAN
switch using fast Ethernet or CDDI.
BTW, after groveling through numerous packet switching implementations
and network drivers, almost invariably I have found that bottlenecks
and low performance have been due not to protocol design but poor
software implementations or (often even more importantly) due to the
host OS architecture. The protocol design has generally been an
extremely minor component of network/packet-switching performance.
>Processing of the IPng header, and subsequent headers
>(such as the transport header), can be made more
>efficient by aligning fields on their natural boundaries
>and making header lengths integral multiples of typical
>word lengths (32, 64, and 128 bits have been suggested)
>in order to preserve alignment in following headers.
>We point out that optimizing the header's fields and
>lengths only to today's processors may not be sufficient
>for the long term. Processor word and cache-line
>lengths, and memory widths are constantly increasing.
This comment suggests that IPng should not be designed to optimal
performance on today's processors because it is better to design for
optimal performance on tomorrow's processors. Thus if IPng is a dead
dog with fleas on today's processors, that level of performance is
okay because in 10 years it might be a screamer. Of course, a system
which is a dead dog with fleas is hardly going to acrue any installed
base. If such be the case, maybe we should not take this document
seriously at all.
> In
>doing header optimizations, the designer should predict
>word-widths one or two CPU generations into the future
>and optimize accordingly. If IPv4 and TCP had been
>optimized for processors common when they were designed,
>they would be very efficient for 6502s and Z-80s.
Actually IPv4 and TCP were designed for processors common at the time
in the environments where the designers worked. Such processors
included 36 bit Honeywell, 24 bit BBN and other reasonably powered
machines with reasonably large real or virtual address spaces. Such
machines were rather more powerful than 6502s and Z-80s. IPv4 and TCP
transitted well to today's microprocessor systems not because of
scaleability inherent in the original design, which targeted the
machines available to the developers at that time, but because
microprocessor systems became reasonably powerful with reasonably
large real and virtual address spaces comparable to the machines on
which early IP and TCP development took place.
>5.4. Robust Service
>CRITERION
>The network service and its associated routing and
>control protocols must be robust.
Would anyone want a network service and routing protocols which broke
all the time?
>DISCUSSION
>Murphy's Law applies to networking.
And of course as a corollary the Peter Principle applies to those
organizations which endeavor to develop networking standards.
>Some predictions have been made that, as the Internet
>grows and as more and more technically less-sophisticated
>sites get connected, there will be more failures in the
>network. These failures may be a combination of simple
>size; if the size of the network goes up by a factor of n
>then the total number of failures in the network can be
>expected to increase by some function of n. Also, as the
>network's users become less sophisticated, it can be
>assumed that they will make more, innocent and well
>meaning, mistakes, either in configuration or use of
>their systems.
This comment is just the typical obnoxious snobbishness of
communications software engineers. If anything, the level of
sophistication will probably increase with an increase in the number
of sites which connect to the internet. Nowadays, someone who knows a
little is a guru and technical wizard who feels obligated to produce
reams of IETF draft documents. When lots of people have set up and
run multiprotocol internetworks, a little knowledge will hardly
impress anybody.
>Time Frame
>Protection against Byzantine failure modes is not needed
>immediately. A proposed architecture for it should be
>done immediately.
Is enough known today about the Byzantine failure modes of the not
yet realized IPng to create such a architecture immediately?
> Prototype development should be
>completed in 12-18 months, with final deployment as
>needed.
One would think there might be a need for a reasonable testing plan
and test period after such prototype development.
>5.5. Transition
>CRITERION
>The protocol must have a straightforward transition plan
>from the current IPv4.
>DISCUSSION
>A smooth, orderly, transition from IPv4 to IPng is
>needed. If we can't transition to the new protocol, then
>no matter how wonderful it is, we'll never get to it.
>We believe that it is not possible to have a "flag-day"
>form of transition in which all hosts and routers must
>change over at once. The size, complexity, and
>distributed administration of the Internet make such a
>cutover impossible.
>The transition plan should address the issue of cost
>distribution. That is, it should identify what tasks are
>required of the service providers, of the end users, of
>the backbones and so on.
This comment is rather scary. The IETF collectively has no obvious
expertise in public finance, accounting or political economics.
The one area where the IETF has tried to distribute costs is network
management, and in this case the IETF has managed to make small
installations subsidize the development of SNMP on behalf of a few
large network providers even though the small installations have no
real need of such a thing.
>Time Frame
>A transition plan is required immediately.
Whenever DECNET was transitioned from one Phase to the next, DEC
provided a transition plan and strategy, studying how DECNET and other
similar networking suites in similar situations were transitioned in
the past might provide insights how to transition IP efficiently and
with minimal dislocation and cost.
>5.8. Configuration, Administration, and Operation
This section is confusing.
>CRITERION
>The protocol must permit easy and largely distributed
>configuration and operation. Automatic configuration of
>hosts and routers is required.
>DISCUSSION
>People complain that IP is hard to manage. We cannot
>plug and play. We must fix that problem.
>We require that a node be able to dynamically obtain all
>of its operational, IP-level parameters at boot time via
>a dynamic configuration mechanism.
Being able to obtain network level parameters at boot time
and full plug-and-play are quite different concepts.
If the boot server has to be configured, that requirement makes the
device which needs the boot server something other than plug and play.
In addition, a host may not be able to find out its routers until long
after boot time. In fact, if a new router is added to a network with
new network numbers, all the hosts might have to forget their old
networks and learn new networks and addresses.
The boot parameters issue is almost completely orthogonal to
plug-and-play auto-configurability.
>Also, a strength of IPv4 has been its ability to be used
>on isolated subnets. IPng hosts must be able to work on
>networks without routers present.
Who designs a networking suite which requires routers on a single
communications subet?
>5.12. Multicast
>CRITERION
>The protocol must support both unicast and multicast
>packet transmission. Part of the multicast capability is
>a requirement to be able to send to "all IP hosts on a
>given subnetwork". Dynamic and automatic routing of
>multicasts is also required.
>DISCUSSION
>IPv4 has made heavy use of the ability to multicast
>requests to all IPv4 hosts on a subnet, especially for
>autoconfiguration. This ability must be retained in
>IPng.
>Unfortunately, IPv4 currently uses the local media
>broadcast address to multicast to all IP hosts. This
>behavior is anti-social in mixed-protocol networks and
>should be fixed in IPng. There's no good reason for IPng
>to send to all hosts on a subnet when it only wishes to
>send to all IPng hosts. The protocol must make
>allowances for media that do not support true
>multicasting.
The above comment is idiotic. Exactly how a network layer multicast
is resolved to a MAC layer address for some arbitrary medium is not
obviously part of the network layer design. In any case, if a medium
only supported a single broadcast and physical addresses, network
multicasts would have to use the broadcast. Furthermore, as Appletalk
has abundantly shown a protocol that uses multicast exclusively can
certainly be antisocial in the sense of burning up a lot of bandwidth.
>5.17. Private Networks
>CRITERION
>IPng must allow users to build private internetworks on
>top of the basic Internet Infrastructure. Both private
>IP-based internetworks and private non-IP-based (e.g.,
>CLNP or Appletalk) internetworks must be supported.
>DISCUSSION
>We note that, today in the IPv4 Internet, tunneling is
>widely used to provide these capabilities.
Because of the inefficiencies associated with routing via tunnels and
because of the difficulties associated with debugging tunneled
networks, tunneling is an extremely problematic approach to use or to
encourage. Because multiprotocol routers are so common today,
tunneling non-IP suites through IP is just silly except in cases of
router misdesign in which case a new router should probably be
obtained.
In providing IPv4 end-host to IPng end-host connectivity, the DECNET
phase III to phase IV approach which interconverts phase III and phase
IV packets where possible and when needed probably makes more sense.
>5.18. Things We Chose Not to Require
>Fragmentation
>The technology exists for path MTU discovery.
>Presumably, IPng will continue to provide this
>technology. Therefore, we believe that IPng
>Fragmentation and Reassembly, as provided in IPv4, is not
>necessary. We note that fragmentation has been shown to
>be detrimental to network performance and strongly
>recommend that it be avoided.
In some circumstances fragmentation and reassembly can cost something
(but not always -- the Constellation X.25 fragmentation and reassembly
routines are costless), but fragmentation provides a fairly
straightforward means to deal with a serious internetworking problem.
I am not sure how MTU discovery overcomes the need for fragmentation
unless MTU discovery is performed before each packet is sent and
strict source routing is employed. OSPF and IGRP load share on equal
cost paths (IGRP will actually share proportionately on non-equal cost
paths). Unless all equal cost (or near equal cost) paths have the
same MTU, not fragmenting could easily
1) lead to non-obvious transitory network failures,
2) force all networks to resort to the use of least common denominator
packet sizes or
3) compel continuous redetermination of MTU to a specific destination
host.
Load sharing over equal cost paths is probably unnecessary for the
occurrence of such problems. These problems might occur in a
sufficiently large network with complex topology where path changes
happened fairly frequently.
>IP Header Checksum
>There has been discussion indicating that the IP Checksum
>does not provide enough error protection to warrant its
>performance impact. The argument states that there is
>almost always a stronger datalink level CRC, and that
>end-to-end protection is provided by the TCP checksum.
>Therefore we believe that an IPng checksum is not
>required per-se.
The IP header checksum is not intended to provide end-to-end data
integrity but rather provides local address integrity. Few routers
provide EDAC. Stuck bits in the wrong place after receive datalink
CRC is calculated could easily cause some poor neighboring router to
be inundated with misdirected packets whose lack of data integrity
might not be detected until much later or even never (if the new
address corresponds to no actual address). This problem could be
particularly serious in the cases of applications which rarely or
infrequently require acknowledgement of transmitted data packets.
Doing away with IP header checksum is probably bad. I think I
understand the motivation. Because many routers are inefficiently
coded, many routers (but not the Constellation series) steal back some
cycles by ignoring IP header checksum. The developers of such routers
would like the IETF to legitimize the unsavory behavior of these
routers.
>6. Routing
>Routing is a very critical part of the Internet. In fact, the
>Internet Engineering Task Force has a separate Area which is
>chartered to deal only with routing issues. This Area is
>separate from the more general Internet Area.
>We see that routing is also a critical component of IPng.
>There are several criteria, such as Scaling, Addressing, and
>Network Services, which are intimately entwined with routing.
Shouldn't routing performance be included among these critical
components? Of course if we worried about performance, would we not
have some questions about performance on lower speed WAN connections
as well as the ability to support the latest and greatest high speed
media?
For instance, everyone is so concerned about the effect of headers on
WAN performance, but the currently proposed IPng has a single network
address field which is 16 bytes and which is therefore only 4 bytes
less than the whole standard IPv4 header.
>In order to stress the critical nature and importance of
>routing, we have chosen to devote a separate chapter to
>specifically enumerating some of the requirements and issues
>that IPng routing must address. All of these issues, we
>believe, fall out of the general criteria presented in the
>previous chapter.
>6.5. Stability
>With the addition of additional data into the routing system
>(i.e. routes are based not only on connectivity, as in IPv4,
>but also on policies, service grades, and so on), the
>stability of the routes may suffer. We offer as evidence the
>early Arpanet which experimented with load-based routing.
>Routes would remain in flux, changing from one saturated link,
>to another, unused, link.
>This must not be allowed to happen. If anything, routes
>should be even more stable under IPng's routing architecture
>than under the current architecture.
Does this mean load sharing between equal cost and near equal cost
routes (IGRP) is to be dropped from the architecture?
In summary, there are lots of problems with this IPng criteria
document. Did people really seriously use it to deliberate on
the various proposals for the new IP?
Joachim Martillo
Manager of Internetworking Research
Penril Datability Networks
Penril Datability Advanced Communications Research Center
190 N. Main St.
Natick, MA 01760
VOICE 508-653-5313
FAX 508-653-6415
EMAIL martillo at dss.com
martillo at penril.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16945;
2 Aug 94 21:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16941;
2 Aug 94 21:55 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa21914;
2 Aug 94 21:55 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id LAA08196; Wed, 3 Aug 1994 11:20:56 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id LAA08182; Wed, 3 Aug 1994 11:10:31 +1000
Precedence: list
Received: from pluto.dss.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA15600; Wed, 3 Aug 1994 09:43:45 +1000 (from martillo at pluto.dss.com)
Received: by pluto.dss.com (4.1/SMI-4.0)
id AA20981; Tue, 2 Aug 94 19:39:42 EDT
Date: Tue, 2 Aug 94 19:39:42 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joachim Martillo <martillo at pluto.dss.com>
Message-Id: <9408022339.AA20981 at pluto.dss.com>
To: big-internet at munnari.oz.au
Cc: ietf at CNRI.Reston.VA.US, martillo at pluto.dss.com
Subject: Re: IPng recommendation
After noticing some of the discussion of IPng criteria, I ftp'd over
the criteria. Exactly how to interpret this document is unclear.
ISO, CCITT, ANSI and IEEE documents can have problems, but the authors
usually are attempting to be serious and precise. This document seems
to attempt humor with cutesy section titles, but calculations of a
need to support 10**15 end-hosts (about 250,000 per human) make the
document rather risible.
>INTERNET DRAFT
>Technical Criteria for Choosing
>IP:The Next Generation (IPng)
>draft-kastenholz-ipng-criteria-02.txt
>25 May 1994
>Frank Kastenholz
>FTP Software, Inc
>2 High Street
>North Andover, Mass 01845-2620 USA
>kasten at ftp.com
>Craig Partridge
>BBN Systems and Technologies
>craig at aland.bbn.com
>1. Introduction
>This memo presents a set of criteria that the authors' believe
>should be used to help evaluate protocols being proposed for
>adoption as the next generation of IP.
>4.2. One Protocol to Bind Them All
>One of the most important aspects of The Internet is that it
>provides global IP-layer connectivity. The IP layer provides
>the point of commonality among all of the nodes on the
>Internet. In effect, the main goal of the Internet is to
>provide an IP Connectivity Service to all who wish it.
>This does NOT say that the Internet is a One-Protocol
>Internet. The Internet is today, and shall remain in the
>future, a Multi-Protocol Internet. Multi-Protocol operations
>are required to allow for continued testing, experimentation,
>and development and because service providers' customers
>clearly want to be able to run protocols such as CLNP, DECNET,
>and Novell over their Internet connections.
This point is reasonable because as a manufacturing regime the IETF
should not produce standards
1) which cause problems in a multiprotocol environment,
2) which favor IP to the detriment of multiprotocol interworking or
3) which in other ways discourage cost-effective, productive use of
multiprotocol internetworks.
>5.3. Performance
>CRITERION
>A state of the art, commercial grade router must be able
>to process and forward IPng traffic at speeds capable of
>fully utilizing common, commercially available, high-
>speed media at the time. Furthermore, at a minimum, a
>host must be able to achieve data transfer rates with
>IPng comparable to the rates achieved with IPv4, using
>similar levels of host resources.
Since poor router performance can affect a whole internet rather than
simply an individual host, the criterion should have concentrated
attention on router performance. After all, it is conceiveable that
an individual host with a single interface can achieve full bandwidth
utilization but the performance of a router with many interfaces might
suffer tremendously from misdesign of a next generation IP. The
converse case seems unlikely where a router with many interfaces might
achieve full bandwidth utilization while an individual host with a
single interface might perform miserably.
>DISCUSSION
>Network media speeds are constantly increasing. It is
>essential that the Internet's switching elements
>(routers) be able to keep up with the media speeds.
>We limit this requirement to commercially available
>routers and media. If some network site can obtain a
>particular media technology "off the shelf", then it
>should also be able to obtain the needed routing
>technology "off the shelf." One can always go into some
>laboratory or research center and find newer, faster,
>technologies for network media and for routing. We do
>believe, however, that IPng should be routable at a speed
>sufficient to fully utilize the fastest available media,
>though that might require specially built, custom,
>devices.
This comment suggests that the new address structure should enable the
quickest possible route look-up. The quickest possible route look-up
means that a network number should conveniently correspond to a
natural register size on common communications computers and that
accesses to slower processor external memory should be minimized.
Such needs and 16 byte addresses are hard to reconcile with current
router technology.
>We expect that more and more services will be available
>over the Internet. It is not unreasonable, therefore, to
>expect that the ratio of "local" traffic (i.e. the
>traffic that stays on one's local network) to "export"
>traffic (i.e. traffic destined to or sourced from a
>network other than one's own local network) will change,
>and the percent of export traffic will increase.
This observation is not obviously true. As file servers, database
servers, multimedia servers and other network resources become
cheaper, such resources are likely to become increasingly available
locally. While export traffic apparently increases absolutely, the
ratio of export traffic to local traffic actually decreases.
Anticipating such results in 1987-1988, Tony Bono and I designed the
Constellation Series packet switches to be configureable as
shake-and-bake IMPs, wire-speed LAN switches, fully powered-bridges
and multiprotocol routers or any mixed combination thereof in order to
serve all possible network needs. IPng must be conducive of such
designs in order to meet user needs flexibly and cost-effectively. A
concentration on export traffic in the design of IPng would be
misguided.
>We note that the host performance requirement should not
>be taken to imply that IPng need only be as good as IPv4.
>If an IPng candidate can achieve better performance with
>equivalent resources (or equivalent transfer rates with
>fewer resources) vis-a-vis IPv4 then so much the better.
>We also observe that many researchers believe that a
>proper IPng router should be capable of routing IPng
>traffic over links at speeds that are capable of fully
>utilizing an ATM switch on the link.
ATM is yet another fad technology whose fad may be approaching its
end. I have recently read that several companies which had started
ATM development efforts had abandoned these efforts as pointless. A
better targer might be wire-speed routing in the context of a LAN
switch using fast Ethernet or CDDI.
BTW, after groveling through numerous packet switching implementations
and network drivers, almost invariably I have found that bottlenecks
and low performance have been due not to protocol design but poor
software implementations or (often even more importantly) due to the
host OS architecture. The protocol design has generally been an
extremely minor component of network/packet-switching performance.
>Processing of the IPng header, and subsequent headers
>(such as the transport header), can be made more
>efficient by aligning fields on their natural boundaries
>and making header lengths integral multiples of typical
>word lengths (32, 64, and 128 bits have been suggested)
>in order to preserve alignment in following headers.
>We point out that optimizing the header's fields and
>lengths only to today's processors may not be sufficient
>for the long term. Processor word and cache-line
>lengths, and memory widths are constantly increasing.
This comment suggests that IPng should not be designed to optimal
performance on today's processors because it is better to design for
optimal performance on tomorrow's processors. Thus if IPng is a dead
dog with fleas on today's processors, that level of performance is
okay because in 10 years it might be a screamer. Of course, a system
which is a dead dog with fleas is hardly going to acrue any installed
base. If such be the case, maybe we should not take this document
seriously at all.
> In
>doing header optimizations, the designer should predict
>word-widths one or two CPU generations into the future
>and optimize accordingly. If IPv4 and TCP had been
>optimized for processors common when they were designed,
>they would be very efficient for 6502s and Z-80s.
Actually IPv4 and TCP were designed for processors common at the time
in the environments where the designers worked. Such processors
included 36 bit Honeywell, 24 bit BBN and other reasonably powered
machines with reasonably large real or virtual address spaces. Such
machines were rather more powerful than 6502s and Z-80s. IPv4 and TCP
transitted well to today's microprocessor systems not because of
scaleability inherent in the original design, which targeted the
machines available to the developers at that time, but because
microprocessor systems became reasonably powerful with reasonably
large real and virtual address spaces comparable to the machines on
which early IP and TCP development took place.
>5.4. Robust Service
>CRITERION
>The network service and its associated routing and
>control protocols must be robust.
Would anyone want a network service and routing protocols which broke
all the time?
>DISCUSSION
>Murphy's Law applies to networking.
And of course as a corollary the Peter Principle applies to those
organizations which endeavor to develop networking standards.
>Some predictions have been made that, as the Internet
>grows and as more and more technically less-sophisticated
>sites get connected, there will be more failures in the
>network. These failures may be a combination of simple
>size; if the size of the network goes up by a factor of n
>then the total number of failures in the network can be
>expected to increase by some function of n. Also, as the
>network's users become less sophisticated, it can be
>assumed that they will make more, innocent and well
>meaning, mistakes, either in configuration or use of
>their systems.
This comment is just the typical obnoxious snobbishness of
communications software engineers. If anything, the level of
sophistication will probably increase with an increase in the number
of sites which connect to the internet. Nowadays, someone who knows a
little is a guru and technical wizard who feels obligated to produce
reams of IETF draft documents. When lots of people have set up and
run multiprotocol internetworks, a little knowledge will hardly
impress anybody.
>Time Frame
>Protection against Byzantine failure modes is not needed
>immediately. A proposed architecture for it should be
>done immediately.
Is enough known today about the Byzantine failure modes of the not
yet realized IPng to create such a architecture immediately?
> Prototype development should be
>completed in 12-18 months, with final deployment as
>needed.
One would think there might be a need for a reasonable testing plan
and test period after such prototype development.
>5.5. Transition
>CRITERION
>The protocol must have a straightforward transition plan
>from the current IPv4.
>DISCUSSION
>A smooth, orderly, transition from IPv4 to IPng is
>needed. If we can't transition to the new protocol, then
>no matter how wonderful it is, we'll never get to it.
>We believe that it is not possible to have a "flag-day"
>form of transition in which all hosts and routers must
>change over at once. The size, complexity, and
>distributed administration of the Internet make such a
>cutover impossible.
>The transition plan should address the issue of cost
>distribution. That is, it should identify what tasks are
>required of the service providers, of the end users, of
>the backbones and so on.
This comment is rather scary. The IETF collectively has no obvious
expertise in public finance, accounting or political economics.
The one area where the IETF has tried to distribute costs is network
management, and in this case the IETF has managed to make small
installations subsidize the development of SNMP on behalf of a few
large network providers even though the small installations have no
real need of such a thing.
>Time Frame
>A transition plan is required immediately.
Whenever DECNET was transitioned from one Phase to the next, DEC
provided a transition plan and strategy, studying how DECNET and other
similar networking suites in similar situations were transitioned in
the past might provide insights how to transition IP efficiently and
with minimal dislocation and cost.
>5.8. Configuration, Administration, and Operation
This section is confusing.
>CRITERION
>The protocol must permit easy and largely distributed
>configuration and operation. Automatic configuration of
>hosts and routers is required.
>DISCUSSION
>People complain that IP is hard to manage. We cannot
>plug and play. We must fix that problem.
>We require that a node be able to dynamically obtain all
>of its operational, IP-level parameters at boot time via
>a dynamic configuration mechanism.
Being able to obtain network level parameters at boot time
and full plug-and-play are quite different concepts.
If the boot server has to be configured, that requirement makes the
device which needs the boot server something other than plug and play.
In addition, a host may not be able to find out its routers until long
after boot time. In fact, if a new router is added to a network with
new network numbers, all the hosts might have to forget their old
networks and learn new networks and addresses.
The boot parameters issue is almost completely orthogonal to
plug-and-play auto-configurability.
>Also, a strength of IPv4 has been its ability to be used
>on isolated subnets. IPng hosts must be able to work on
>networks without routers present.
Who designs a networking suite which requires routers on a single
communications subet?
>5.12. Multicast
>CRITERION
>The protocol must support both unicast and multicast
>packet transmission. Part of the multicast capability is
>a requirement to be able to send to "all IP hosts on a
>given subnetwork". Dynamic and automatic routing of
>multicasts is also required.
>DISCUSSION
>IPv4 has made heavy use of the ability to multicast
>requests to all IPv4 hosts on a subnet, especially for
>autoconfiguration. This ability must be retained in
>IPng.
>Unfortunately, IPv4 currently uses the local media
>broadcast address to multicast to all IP hosts. This
>behavior is anti-social in mixed-protocol networks and
>should be fixed in IPng. There's no good reason for IPng
>to send to all hosts on a subnet when it only wishes to
>send to all IPng hosts. The protocol must make
>allowances for media that do not support true
>multicasting.
The above comment is idiotic. Exactly how a network layer multicast
is resolved to a MAC layer address for some arbitrary medium is not
obviously part of the network layer design. In any case, if a medium
only supported a single broadcast and physical addresses, network
multicasts would have to use the broadcast. Furthermore, as Appletalk
has abundantly shown a protocol that uses multicast exclusively can
certainly be antisocial in the sense of burning up a lot of bandwidth.
>5.17. Private Networks
>CRITERION
>IPng must allow users to build private internetworks on
>top of the basic Internet Infrastructure. Both private
>IP-based internetworks and private non-IP-based (e.g.,
>CLNP or Appletalk) internetworks must be supported.
>DISCUSSION
>We note that, today in the IPv4 Internet, tunneling is
>widely used to provide these capabilities.
Because of the inefficiencies associated with routing via tunnels and
because of the difficulties associated with debugging tunneled
networks, tunneling is an extremely problematic approach to use or to
encourage. Because multiprotocol routers are so common today,
tunneling non-IP suites through IP is just silly except in cases of
router misdesign in which case a new router should probably be
obtained.
In providing IPv4 end-host to IPng end-host connectivity, the DECNET
phase III to phase IV approach which interconverts phase III and phase
IV packets where possible and when needed probably makes more sense.
>5.18. Things We Chose Not to Require
>Fragmentation
>The technology exists for path MTU discovery.
>Presumably, IPng will continue to provide this
>technology. Therefore, we believe that IPng
>Fragmentation and Reassembly, as provided in IPv4, is not
>necessary. We note that fragmentation has been shown to
>be detrimental to network performance and strongly
>recommend that it be avoided.
In some circumstances fragmentation and reassembly can cost something
(but not always -- the Constellation X.25 fragmentation and reassembly
routines are costless), but fragmentation provides a fairly
straightforward means to deal with a serious internetworking problem.
I am not sure how MTU discovery overcomes the need for fragmentation
unless MTU discovery is performed before each packet is sent and
strict source routing is employed. OSPF and IGRP load share on equal
cost paths (IGRP will actually share proportionately on non-equal cost
paths). Unless all equal cost (or near equal cost) paths have the
same MTU, not fragmenting could easily
1) lead to non-obvious transitory network failures,
2) force all networks to resort to the use of least common denominator
packet sizes or
3) compel continuous redetermination of MTU to a specific destination
host.
Load sharing over equal cost paths is probably unnecessary for the
occurrence of such problems. These problems might occur in a
sufficiently large network with complex topology where path changes
happened fairly frequently.
>IP Header Checksum
>There has been discussion indicating that the IP Checksum
>does not provide enough error protection to warrant its
>performance impact. The argument states that there is
>almost always a stronger datalink level CRC, and that
>end-to-end protection is provided by the TCP checksum.
>Therefore we believe that an IPng checksum is not
>required per-se.
The IP header checksum is not intended to provide end-to-end data
integrity but rather provides local address integrity. Few routers
provide EDAC. Stuck bits in the wrong place after receive datalink
CRC is calculated could easily cause some poor neighboring router to
be inundated with misdirected packets whose lack of data integrity
might not be detected until much later or even never (if the new
address corresponds to no actual address). This problem could be
particularly serious in the cases of applications which rarely or
infrequently require acknowledgement of transmitted data packets.
Doing away with IP header checksum is probably bad. I think I
understand the motivation. Because many routers are inefficiently
coded, many routers (but not the Constellation series) steal back some
cycles by ignoring IP header checksum. The developers of such routers
would like the IETF to legitimize the unsavory behavior of these
routers.
>6. Routing
>Routing is a very critical part of the Internet. In fact, the
>Internet Engineering Task Force has a separate Area which is
>chartered to deal only with routing issues. This Area is
>separate from the more general Internet Area.
>We see that routing is also a critical component of IPng.
>There are several criteria, such as Scaling, Addressing, and
>Network Services, which are intimately entwined with routing.
Shouldn't routing performance be included among these critical
components? Of course if we worried about performance, would we not
have some questions about performance on lower speed WAN connections
as well as the ability to support the latest and greatest high speed
media?
For instance, everyone is so concerned about the effect of headers on
WAN performance, but the currently proposed IPng has a single network
address field which is 16 bytes and which is therefore only 4 bytes
less than the whole standard IPv4 header.
>In order to stress the critical nature and importance of
>routing, we have chosen to devote a separate chapter to
>specifically enumerating some of the requirements and issues
>that IPng routing must address. All of these issues, we
>believe, fall out of the general criteria presented in the
>previous chapter.
>6.5. Stability
>With the addition of additional data into the routing system
>(i.e. routes are based not only on connectivity, as in IPv4,
>but also on policies, service grades, and so on), the
>stability of the routes may suffer. We offer as evidence the
>early Arpanet which experimented with load-based routing.
>Routes would remain in flux, changing from one saturated link,
>to another, unused, link.
>This must not be allowed to happen. If anything, routes
>should be even more stable under IPng's routing architecture
>than under the current architecture.
Does this mean load sharing between equal cost and near equal cost
routes (IGRP) is to be dropped from the architecture?
In summary, there are lots of problems with this IPng criteria
document. Did people really seriously use it to deliberate on
the various proposals for the new IP?
Joachim Martillo
Manager of Internetworking Research
Penril Datability Networks
Penril Datability Advanced Communications Research Center
190 N. Main St.
Natick, MA 01760
VOICE 508-653-5313
FAX 508-653-6415
EMAIL martillo at dss.com
martillo at penril.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17156;
2 Aug 94 22:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17146;
2 Aug 94 22:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22139;
2 Aug 94 22:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17135;
2 Aug 94 22:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17077;
2 Aug 94 22:11 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa22113;
2 Aug 94 22:11 EDT
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id TAA21430; Tue, 2 Aug 1994 19:10:58 -0700
Message-Id: <aa64acb903021023bd1e at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 2 Aug 1994 19:11:04 -0700
To: Joachim Martillo <martillo at pluto.dss.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng recommendation
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US,
martillo at pluto.dss.com
Joachim,
I, for one, would like to thank you for your timely contribution to the
IPng discussions.
d/
-----
Dave Crocker <dcrocker at mordor.stanford.edu>
675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205
Sunnyvale, CA 94086 (USA)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18711;
2 Aug 94 23:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18707;
2 Aug 94 23:09 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa22901;
2 Aug 94 23:09 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id MAA08330; Wed, 3 Aug 1994 12:55:53 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id MAA08276; Wed, 3 Aug 1994 12:48:05 +1000
Precedence: list
Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA21223; Wed, 3 Aug 1994 12:11:14 +1000 (from dcrocker at mordor.stanford.edu)
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id TAA21430; Tue, 2 Aug 1994 19:10:58 -0700
Message-Id: <aa64acb903021023bd1e at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 2 Aug 1994 19:11:04 -0700
To: Joachim Martillo <martillo at pluto.dss.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng recommendation
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US,
martillo at pluto.dss.com
Joachim,
I, for one, would like to thank you for your timely contribution to the
IPng discussions.
d/
-----
Dave Crocker <dcrocker at mordor.stanford.edu>
675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205
Sunnyvale, CA 94086 (USA)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18743;
2 Aug 94 23:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18735;
2 Aug 94 23:11 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa22939;
2 Aug 94 23:11 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <WAA09535 at pad-thai.aktis.com>; Tue, 2 Aug 1994 22:54:02 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA02051; Tue, 2 Aug 94 22:52:38 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA03428; Tue, 2 Aug 94 22:52:31 EDT
Date: Tue, 2 Aug 94 22:52:31 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408030252.AA03428 at tsx-11.MIT.EDU>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: vipin.samar at eng.sun.com, cat-ietf at mit.edu
In-Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk's message of Tue, 2 Aug 94 23:10:08 BST,
<9408022210.AA01725 at getafix.oasis.icl.co.uk>
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Date: Tue, 2 Aug 94 23:10:08 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
I too think that such an interface would be a good thing. But, being
devil's advocate, what Internet applications would be potential
consumers of such APIs? While EDI and email are two obvious candidates,
doesn't the existence of existing specifications and/or implementations of
store-and-forward security embedded within such applications (PEM, PGP,
X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a
new generic, and possibly non-interoperable, paradigm for implementing
the same services?
Well, a generic API that defined how to take a blob of data and creating
a PEM or PGP encrypted (and possibly ASCII armored) message would be
quite useful. I don't think this would necessarily be a new,
non-interoperable paradigm, since there generally isn't a commonly used
API in use now for these services that's callable from other programs.
(Right now, there's just a command-line interface for PEM and PGP.)
I'm assuming here that the packet formats of PEM, PGP, etc. would not
change under this new API.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24787;
2 Aug 94 23:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24777;
2 Aug 94 23:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23456;
2 Aug 94 23:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24750;
2 Aug 94 23:48 EDT
Received: from netcom9.netcom.com by IETF.CNRI.Reston.VA.US id aa24726;
2 Aug 94 23:47 EDT
Received: by netcom9.netcom.com (8.6.8.1/Netcom)
id UAA25800; Tue, 2 Aug 1994 20:48:50 -0700
Date: Tue, 2 Aug 1994 20:48:50 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: allyn <allyn at netcom.com>
Message-Id: <199408030348.UAA25800 at netcom9.netcom.com>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: 25th Aniversity of Internet
Does anyone know of a rumored celebration of the 25th aniversity
of the Internet? Like where, who is putting it on, etc?
Thanks
Mark Allyn
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25845;
3 Aug 94 0:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25835;
3 Aug 94 0:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24538;
3 Aug 94 0:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25820;
3 Aug 94 0:56 EDT
Received: from feta.cisco.com by IETF.CNRI.Reston.VA.US id aa25790;
3 Aug 94 0:54 EDT
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA21101; Tue, 2 Aug 1994 21:53:46 -0700
Date: Tue, 2 Aug 1994 21:53:46 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408030453.VAA21101 at feta.cisco.com>
To: allyn at netcom.com
Cc: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: allyn's message of Tue, 2 Aug 1994 20:48:50 -0700 <199408030348.UAA25800 at netcom9.netcom.com>
Subject: 25th Aniversity of Internet
According to the August 8 issue of Newsweek (where else would you get
such news?), BBN is throwing an ARPANET 25th anniversary shindig
sometime next month in Boston. No word of who's invited. There's
also a nice picture of Vint, Jon, and Steve with a tin-can-and-
zucchini simulation of the early ARPANET.
Date: Tue, 2 Aug 1994 20:48:50 -0700
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: allyn <allyn at netcom.com>
Does anyone know of a rumored celebration of the 25th aniversity
of the Internet? Like where, who is putting it on, etc?
Thanks
Mark Allyn
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25942;
3 Aug 94 1:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25932;
3 Aug 94 1:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24630;
3 Aug 94 1:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25921;
3 Aug 94 1:01 EDT
Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa25888; 3 Aug 94 1:00 EDT
Received: from Eng.Sun.COM (mxchange.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA00984; Tue, 2 Aug 94 22:00:36 PDT
Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (8.6.9/SMI-4.1)
id WAA00830; Tue, 2 Aug 1994 22:00:42 -0700
Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
id AA04956; Tue, 2 Aug 1994 22:00:26 -0700
Date: Tue, 2 Aug 1994 22:00:26 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Hinden <Bob.Hinden at eng.sun.com>
Message-Id: <9408030500.AA04956 at jurassic.Eng.Sun.COM>
To: allyn <allyn at netcom.com>
Cc: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <199408030348.UAA25800 at netcom9.netcom.com>
Subject: 25th Aniversity of Internet
> Does anyone know of a rumored celebration of the 25th aniversity
> of the Internet? Like where, who is putting it on, etc?
I think there may be an 25th anniversary of the Arpanet celebration. I
don't think the Internet is 25 yet :-)
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03421;
3 Aug 94 9:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03408;
3 Aug 94 9:29 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05930;
3 Aug 94 9:28 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA17607 at pad-thai.aktis.com>; Wed, 3 Aug 1994 08:17:13 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA14319; Wed, 3 Aug 94 08:15:39 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA17602 at pad-thai.aktis.com>; Wed, 3 Aug 1994 08:16:54 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09176; Wed, 3 Aug 94 08:16:51 EDT
Message-Id: <9408031216.AA09176 at winkl.aktis.com>
To: Theodore Ts'o <tytso at mit.edu>
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, vipin.samar at eng.sun.com,
cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Tue, 02 Aug 1994 22:52:31 EDT."
<9408030252.AA03428 at tsx-11.MIT.EDU>
Date: Wed, 03 Aug 1994 08:16:50 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Piers and Ted write:
> From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
> Date: Tue, 2 Aug 94 23:10:08 BST
> Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
>
> I too think that such an interface would be a good thing. But, being
> devil's advocate, what Internet applications would be potential
> consumers of such APIs? While EDI and email are two obvious candidates,
> doesn't the existence of existing specifications and/or implementations of
> store-and-forward security embedded within such applications (PEM, PGP,
> X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a
> new generic, and possibly non-interoperable, paradigm for implementing
> the same services?
>
>Well, a generic API that defined how to take a blob of data and creating
>a PEM or PGP encrypted (and possibly ASCII armored) message would be
>quite useful. I don't think this would necessarily be a new,
>non-interoperable paradigm, since there generally isn't a commonly used
>API in use now for these services that's callable from other programs.
>(Right now, there's just a command-line interface for PEM and PGP.)
>
>I'm assuming here that the packet formats of PEM, PGP, etc. would not
>change under this new API.
Clearly, introducing non-interoperability is a non-useful thing.
This implies to me that messaging support primitives would
want to accept input selector parameters to prescribe which of
a set of already-defined encapsulation formats (e.g., PEM, PGP,
PEM-MIME, ...) they're to output or process as input. Each of
these formats would correspond (loosely) to a GSS-API mechanism,
and this seems to me like a useful means to construct
messaging toolkits allowing applications to use multiple protection
formats.
We appear to have consensus that S&F GSS-API extensions would be
a useful idea; now, we need to decide if and how to progress this
as a work item. Ted, Piers: would it be OK with you if I forwarded
this message to the pem-dev list, as a vehicle to involve interested
members of the PEM development community who may not previously have
been concerned with GSS-API?
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03851;
3 Aug 94 9:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03841;
3 Aug 94 9:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06126;
3 Aug 94 9:38 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03819;
3 Aug 94 9:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03689;
3 Aug 94 9:35 EDT
Received: from pax.cavebear.com by CNRI.Reston.VA.US id aa06053;
3 Aug 94 9:35 EDT
Received: by cavebear.com (4.1/SMI-4.1)
id AA01652; Wed, 3 Aug 94 06:35:33 PDT
Date: Wed, 3 Aug 1994 06:35:32 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chris Wellens <chrisw at pax.cavebear.com>
Subject: dod-test mailing list
To: ietf at CNRI.Reston.VA.US
Message-Id: <Pine.3.89.9408030646.A1634-0100000 at pax.cavebear.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
The Joint Interoperability Test Center OSE Conformance Testing Laboratory
held a Birds of a Feather session at the recent IETF meeting in Toronto
to discuss their Internet Protocols Testing Program.
To continue the discussions at the BOF, the attendees decided to begin a
mailing list. To subscribe to the list, please send email to:
dod-test-request at cavebear.com
with your email address in the body of the message.
It will probably take one week to receive and enter new subscribers.
Therefore, if you have something to post to the list, please wait
until August 10th, and then send your posting to: dod-test at cavebear.com
Some selected excerpts from the BOF Handout:
"DOD as a primary TCP/IP customer, wants conformance testing, to reduce
the risk of non-interoperability because of the great need for 'plug and
play' operation."
"How will test results be used?
Implementations of TCP, IP, Telnet, ftp, and SMTP which meet all the
requirements of the testing program will be added to the register of
validated TCP/IP products.
The register will be available for procurement agents when selecting TCP/IP
products."
"The FTP server with public access for the registers and related documents:
huachuca-jitcosi at army.mil
login: anonymous
password: your complete email address "
If you have questions and interest, please subscribe and post your
questions to the mail list (after August 10th). Do not send email to me,
as InterWorking Labs agreed to set up the list as a public service to the
Internet community, and is not affiliated with the government program.
Chris Wellens
InterWorking Labs, Inc.
218 Carbonera Drive, Suite 102
Santa Cruz, CA 95060-1500
Tel: +1 408 459 9817
Fax: +1 408 459 9768
Email: chrisw at cavebear.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04539;
3 Aug 94 9:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04531;
3 Aug 94 9:59 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa06758;
3 Aug 94 9:59 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA00873 at pad-thai.aktis.com>; Wed, 3 Aug 1994 09:40:46 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA15554; Wed, 3 Aug 94 08:45:45 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <00887-0 at relay1.pipex.net>; Wed, 3 Aug 1994 13:45:04 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA06163; Wed, 3 Aug 94 13:47:13 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA27884;
Wed, 3 Aug 94 13:44:27 BST
Message-Id: <9408031245.AA11995 at getafix.oasis.icl.co.uk>
Date: Wed, 3 Aug 94 13:45:53 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu
Priority: URGENT
> Clearly, introducing non-interoperability is a non-useful thing.
I was obliquely referring to a relevant clause in RFC1508:
Development of GSS-API support primitives based on a particular
underlying cryptographic technique and protocol does not necessarily
imply that GSS-API callers invoking that GSS-API mechanism type will
be able to interoperate with peers invoking the same technique and
protocol outside the GSS-API paradigm. For example, the format of
GSS-API tokens defined in conjunction with a particular mechanism,
and the techniques used to integrate those tokens into callers'
protocols, may not be the same as those used by non-GSS-API callers
of the same underlying technique.
> This implies to me that messaging support primitives would
> want to accept input selector parameters to prescribe which of
> a set of already-defined encapsulation formats (e.g., PEM, PGP,
> PEM-MIME, ...) they're to output or process as input. Each of
> these formats would correspond (loosely) to a GSS-API mechanism,
So it follows that there could not be any generic encapsulating
"wrapper", as in the GSS-API specification for on-line security
mechanisms.
Hence a potential store-and-forward GSS-API would be a programmatic
construct only (i.e. the analogues of Appendices B and C of
RFC1508 couldn't apply).
> and this seems to me like a useful means to construct
> messaging toolkits allowing applications to use multiple protection
> formats.
>
> We appear to have consensus that S&F GSS-API extensions would be
> a useful idea; now, we need to decide if and how to progress this
> as a work item. Ted, Piers: would it be OK with you if I forwarded
> this message to the pem-dev list, as a vehicle to involve interested
> members of the PEM development community who may not previously have
> been concerned with GSS-API?
ok with me.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04582;
3 Aug 94 10:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04571;
3 Aug 94 10:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06790;
3 Aug 94 10:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04548;
3 Aug 94 10:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04437;
3 Aug 94 9:57 EDT
Received: from gatekeeper.mcimail.com by CNRI.Reston.VA.US id aa06713;
3 Aug 94 9:57 EDT
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
id AA18809; Wed, 3 Aug 94 09:00:20 -0500
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ai12812;
3 Aug 94 13:54 GMT
Date: Wed, 3 Aug 94 08:52 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "RND Inc." <0004393582 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: unsubscribe
Message-Id: <22940803135222/0004393582NA3EM at mcimail.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05053;
3 Aug 94 10:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05043;
3 Aug 94 10:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07425;
3 Aug 94 10:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05030;
3 Aug 94 10:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04972;
3 Aug 94 10:18 EDT
Received: from wd40.ftp.com by CNRI.Reston.VA.US id aa07289; 3 Aug 94 10:18 EDT
Received: from ftp.com by ftp.com ; Wed, 3 Aug 1994 10:18:26 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 3 Aug 1994 10:18:26 -0400
Received: by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA02333; Wed, 3 Aug 94 10:15:56 EDT
Date: Wed, 3 Aug 94 10:15:56 EDT
Message-Id: <9408031415.AA02333 at mailserv-D.ftp.com>
To: martillo at pluto.dss.com
Subject: Re: IPng recommendation
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Content-Length: 13031
Joachim,
First of all, comments would have been preferred during the debate.
Certainly before the IPng choice. Comments now are roughly akin to
locking the barn door after the horse has run off, though since there
is still IPNG development work to be done, I am sure that the IPng
developers will carefully consider your points.
Second, one of the 'principles' which Craig and I started using in
refining the criteria was what has been called 'In your face'
requirements. If the criteria were set at a relatively 'safe' or
'low' level, then that is all we might get. You mention, for example,
10**15 end nodes. If we had set, for example, 10**10 end nodes, then
that is possibly all we would get. By setting a higher level, we may
still get only 10**10, but we might also get more. Furthermore, by
saying 10**15, the developers (and the rest of the community) may
think more about what a truly ubiquious global internetwork might
need and what it could do.
> After noticing some of the discussion of IPng criteria, I ftp'd over
> the criteria. Exactly how to interpret this document is unclear.
This document, in its final form, was considered as a framework (not
the only one) about which discussions of the various IPNG candidates
could be held by the IPng directorate. You might, in effect, consider
the section headings to be an 'agenda' of items to be evaluated in
the various proposals.
> >5.3. Performance
>
> >Furthermore, at a minimum, a
> >host must be able to achieve data transfer rates with
> >IPng comparable to the rates achieved with IPv4, using
> >similar levels of host resources.
>
> Since poor router performance can affect a whole internet rather than
> simply an individual host, the criterion should have concentrated
> attention on router performance.
It originally did. However, it was also pointed out that if IPng made
host performance 'very bad' then, even if the routers were blindingly
fast, IPng would be a loser. Furthermore, IPng really should not be
perceived as a step backwards wrt IPv4. If IPng made hosts
significantly slower then it would be just such a step.
Now, this might all seem trivial, obvious, irrelevant, and
motherhood. But, on the other hand, host performance was a major
factor in the discussion about addressing on the big-i list. If host
performance wasn't critical then that discussion may well have had a
different outcome.
> >We limit this requirement to commercially available
> >routers and media. If some network site can obtain a
> >particular media technology "off the shelf", then it
> >should also be able to obtain the needed routing
> >technology "off the shelf." One can always go into some
> >laboratory or research center and find newer, faster,
> >technologies for network media and for routing. We do
> >believe, however, that IPng should be routable at a speed
> >sufficient to fully utilize the fastest available media,
> >though that might require specially built, custom,
> >devices.
>
> This comment suggests that the new address structure should enable the
> quickest possible route look-up. The quickest possible route look-up
> means that a network number should conveniently correspond to a
> natural register size on common communications computers and that
> accesses to slower processor external memory should be minimized.
> Such needs and 16 byte addresses are hard to reconcile with current
> router technology.
First, we attempted to stay as far away from dictating implementation
as we could. Your comment implies that we should have said, for
example, that addresses must have a 4-byte (or whatever number)
network number field. This would be dangerously close to specifying
the implementation, and not pointing out the problems that were to be
solved. (By pointing out the problem, we in theory allowed for a qide
variety of solutions.)
Second, some people are envisioning that a majority of traffic in the
future internet will be forwarded not based on topological
information carried around in the packet, but rather on a smaller,
more easily handled, 'flow-id' which would have the properties you
talk about. I note that SIPP has such a flowid.
> >We expect that more and more services will be available
> >over the Internet. It is not unreasonable, therefore, to
> >expect that the ratio of "local" traffic (i.e. the
> >traffic that stays on one's local network) to "export"
> >traffic (i.e. traffic destined to or sourced from a
> >network other than one's own local network) will change,
> >and the percent of export traffic will increase.
>
> This observation is not obviously true... A
> concentration on export traffic in the design of IPng would be
> misguided.
Possibly. It also raises the possibility of new models of use for a
commercial service Internet. Consider things like a home computer, or
doing cable TV via the Internet. In these cases, ALL network traffic
would be exported. Our hope is that the criteria document spurred
some people to think about the future and what it might bring.
> >We also observe that many researchers believe that a
> >proper IPng router should be capable of routing IPng
> >traffic over links at speeds that are capable of fully
> >utilizing an ATM switch on the link.
>
> ATM is yet another fad technology whose fad may be approaching its
> end...A better targer might be wire-speed routing in the context of a LAN
> switch using fast Ethernet or CDDI.
The base criterion does not mention any specific technology. We felt
that we could not accurately predict what technology would be the
'right' technology in 5 or 10 years. After all, wrt your observation
on ATM, only 1 or 2 years ago, many people were predicting that ATM
would take over the world. We make the criterion apply to 'common
commercial technology' which allows it to be flexible and to change
over time for the next 10-20 years.
> >Some predictions have been made that, as the Internet
> >grows and as more and more technically less-sophisticated
> >sites get connected, there will be more failures in the
> >network. These failures may be a combination of simple
> >size; if the size of the network goes up by a factor of n
> >then the total number of failures in the network can be
> >expected to increase by some function of n. Also, as the
> >network's users become less sophisticated, it can be
> >assumed that they will make more, innocent and well
> >meaning, mistakes, either in configuration or use of
> >their systems.
>
> This comment is just the typical obnoxious snobbishness of
> communications software engineers. If anything, the level of
> sophistication will probably increase with an increase in the number
> of sites which connect to the internet....When lots of people have
> set up and
> run multiprotocol internetworks, a little knowledge will hardly
> impress anybody.
Perhaps. However, history may be against you. I recall an IETF in
recent history (less than 2 years ago) where the terminal room was
set up by a major organization. They couldn't understand _why_ we
wanted domain name service available for the terminals and laptops.
Also, we are envisioning a future where the entities who connect to
the Internet will not be like they are today. They will be sites that
are non-technical (in the networking sense) and probably will not
have the system operations staff that current sites have. Imagine a
dentist's office connecting to the network. This is also the reason
why we are stressing a 'plug-and-play' configuration ability. The
less that has to be configured, the less chance of making such errors.
> >5.5. Transition
> >The transition plan should address the issue of cost
> >distribution. That is, it should identify what tasks are
> >required of the service providers, of the end users, of
> >the backbones and so on.
>
> This comment is rather scary. The IETF collectively has no obvious
> expertise in public finance, accounting or political economics.
The first step in figuring out the 'public finance, accounting or
political economics' issues it to determine exactly what has to be
done. That's all we are saying.
> >5.12. Multicast
>
> >CRITERION
> >The protocol must support both unicast and multicast
> >packet transmission. Part of the multicast capability is
> >a requirement to be able to send to "all IP hosts on a
> >given subnetwork". Dynamic and automatic routing of
> >multicasts is also required.
>
> >DISCUSSION
> >IPv4 has made heavy use of the ability to multicast
> >requests to all IPv4 hosts on a subnet, especially for
> >autoconfiguration. This ability must be retained in
> >IPng.
>
> >Unfortunately, IPv4 currently uses the local media
> >broadcast address to multicast to all IP hosts. This
> >behavior is anti-social in mixed-protocol networks and
> >should be fixed in IPng. There's no good reason for IPng
> >to send to all hosts on a subnet when it only wishes to
> >send to all IPng hosts. The protocol must make
> >allowances for media that do not support true
> >multicasting.
>
> The above comment is idiotic. Exactly how a network layer multicast
> is resolved to a MAC layer address for some arbitrary medium is not
> obviously part of the network layer design.
It says 'When mac-layer multicasting is available, use it in preference
to broadcasts.'
> Furthermore, as Appletalk
> has abundantly shown a protocol that uses multicast exclusively can
> certainly be antisocial in the sense of burning up a lot of bandwidth.
This criterion does not say that one should use multicasts instead of
unicasts. There are certain types of applications (eg multi-person
conferencing, finding servers) where using unicasts is not the best
way to go. If the existance of these applications is a given, then we
have a choice of using MAC-level multicasts or broadcasts (where
mcasts are available). We believe that multicasts are preferred in
these situations.
> >5.17. Private Networks
> >DISCUSSION
> >We note that, today in the IPv4 Internet, tunneling is
> >widely used to provide these capabilities.
>
> Because multiprotocol routers are so common today,
> tunneling non-IP suites through IP is just silly except in cases of
> router misdesign in which case a new router should probably be
> obtained.
Maybe one is not tunneling non-IP traffic. Perhaps one is building a
private IP network on top of the IP Internet to, for example,
cooperatively develop and test new routing protocols.
> >6. Routing
>
> >Routing is a very critical part of the Internet. In fact, the
> >Internet Engineering Task Force has a separate Area which is
> >chartered to deal only with routing issues. This Area is
> >separate from the more general Internet Area.
>
> >We see that routing is also a critical component of IPng.
> >There are several criteria, such as Scaling, Addressing, and
> >Network Services, which are intimately entwined with routing.
>
> Shouldn't routing performance be included among these critical
> components?
What exactly is routing performance? There are at least three
separate functions that are commonly subsumed under the term
'routing' and the performance could apply to any of the three. We
believe that we have performance of Forwarding packets well covered.
The other functions, information distribution (i.e. the routing
protocols) and route calculation are harder to specify. Should we say
that the 'Routing Protocols should be efficient' and 'Route
calculation should be fast'? This seems too nebulous.
> >6.5. Stability
> >This must not be allowed to happen. If anything, routes
> >should be even more stable under IPng's routing architecture
> >than under the current architecture.
>
> Does this mean load sharing between equal cost and near equal cost
> routes (IGRP) is to be dropped from the architecture?
I don't see switching packets between the several paths of a
multi-path route as route-flapping. I consider the paths of a a
multi-path route as a single 'route' for the purposes of this
discussion. The main reason that route flapping is considered 'bad'
is that route setup in the future may take into account things other
than mere reachability (see the work on integrated services). For a
multi-path route to fit into this model, all paths would have to have
the required service levels so swapping between any of the paths is
really not an issue. The issue arises when the routing subsystems
select a new path based on reachability but the necessary service
levels are not available.
The other problem with route flapping is that one may never get a
route. The 'primary' route goes down. The routing subsystem starts
to reconfigure to use an 'alternate' route and then the 'primary'
comes back up. The routing subsystem then re-reconfigures to use the
primary and it goes down again. Repeat. In doing multipath, this
isn't really an issue since both paths are already 'active'.
--
Frank Kastenholz
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06977;
3 Aug 94 11:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06969;
3 Aug 94 11:47 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa09252;
3 Aug 94 11:47 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <LAA03617 at pad-thai.aktis.com>; Wed, 3 Aug 1994 11:26:31 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA26007; Wed, 3 Aug 94 11:25:14 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <LAA03612 at pad-thai.aktis.com>; Wed, 3 Aug 1994 11:26:24 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09378; Wed, 3 Aug 94 11:26:22 EDT
Message-Id: <9408031526.AA09378 at winkl.aktis.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Draft minutes for Toronto CAT sessions
Date: Wed, 03 Aug 1994 11:26:21 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT fanciers:
Attached are my draft minutes recording our discussions in Toronto. If
you have any clarifications or changes to suggest, please send them to the
list no later than next Tuesday, 9 August, so that I can reflect them
before sending them to the IETF secretariat later next week.
Thanks, ...
--jl
-----Draft minutes follow; cut here-----
COMMON AUTHENTICATION TECHNOLOGY (CAT) MINUTES, TORONTO, JULY 1994
Minutes compiled by John Linn (OpenVision).
The Common Authentication Technology (CAT) WG met for two sessions in
Toronto, with a total of 59 rostered attendees. Approximately half
the attendees had attended one or more previous CAT meetings, and
approximately one third were subscribed to the WG mailing list.
Carlisle Adams (BNR) gave a presentation on the Simple Public-Key
Mechanism (SPKM), a proposed GSS-API mechanism based on public-key
technology, offering 2-way and 3-way authentication exchange variants,
generalized use of OIDs for flexibility, parameter negotiation, and
provisions for non-repudiation services. We reached rough consensus
on outstanding issues of GSS-API buffer sizes, continuation processing
of long messages, and context expiration, pending review by the
mailing list. Advancement of FTP security is pending on revision of
the Internet-Draft. We also received a presentation on IMAP
authentication by by John Myers (CMU).
Topics receiving significant discussion, summarized in
later sections of these minutes, included:
- The Simple Public-Key Mechanism (SPKM)
- Interactive Mail Access Protocol (IMAP) authentication
- Context expiration in Kerberos V5 mechanism and GSS-API
- Continuation processing and large message handling in GSS-API
SHORT TOPICS
In opening agenda discussion, P. Rajaram (Bellcore) asked whether discussion
of authorization extensions to GSS-API, such as those proposed in X/Open
by Project SESAME, was an appropriate topic for CAT WG discussion. Piers
McMahon (ICL) commented that the SESAME work was outside the CAT WG's
current scope. It was also noted that a separate IETF Authorization and
Access Control (aac) WG exists and is chartered to pursue such activities,
but that the aac WG has not met recently.
Other topics, discussed briefly, included:
Kerberos principal object support; WG members were asked to review
the text in draft-ietf-cat-kerb5gss-01.txt proposing routines for
import and export of non-printable name objects and to consider
whether these routines should be migrated to successors to RFCs 1508
and 1509.
Negotiated mechanism: Don Stephenson (Sun) and P. Rajaram
to investigate reactivation of former work, possible availability of
code; any added application requirements for negotiation solicited
(one desirable: be able to make the negotiation messages compact for
insertion within existing size-limited protocols; another, enable
ordered preferences to be specified)
"SERVICE:"; prefix for service names: Ted Ts'o to send note to list,
summarizing issues and background. This prefix had been used to
distinguish service entities, in conjunction with a null mechanism
type. Its use now appears redundant along with the service name type,
(as described in the current draft), which serves as a hint to
gss_import_name() as to how to process a name in the course of
importation. There are some backward compatibility issues with
existing code. We need to decide how, and whether, to preserve use of
this convention.
Store-and-forward support service extensions to GSS-API: no consensus
within group on pursuing this topic at the meeting, but discussion is
proceeding on the mailing list. P. Kirstein (UCL) and P. McMahon
(ICL) noted that the European Community's TDP consortium is interested
in using (or defining, if needed) GSS-API compatible extensions in
this area, and that there would be interest in any work which might
emerge from the IETF.
Service-to-client one-way authentication (as desired, e.g., by Mosaic):
at present, best available approach is to authenticate mutually from
accessing client to server, even though the client-server path isn't
an application requirement.
Buffer sizes across GSS-API interface: It was believed that the 2Kbyte
threshold included in draft-ietf-kerb5gss-01.txt was smaller than
desirable, and that a change to 16Kbytes would be acceptable to known
implementors and would permit more efficient operation. It is
therefore proposed that the limit be increased to 16Kbytes.
Stream support ("CATS" protocol) - Ted Ts'o (MIT) to resend working
notes to list.
Status of FTP security draft - pending revision in response to posted
comments.
SPKM PRESENTATION
Carlisle Adams (BNR) gave a presentation on a proposed Simple
Public-Key Mechanism (SPKM), as described in Internet-Draft
draft-ietf-cat-spkmgss-00.txt. SPKM is based on a public key
infrastructure, offers (as separate mechanisms with different OIDs)
2-way and 3-way mutual authentication (thereby available to
environments without secure time); uses OIDs wherever possible to
allow maximum flexibility and growth; uses negotiation at context
establishment time to allow interoperability between environments (for
SPKM-specific parameter negotiation, within the mechanism); QOP
parameter (from application) selects the data integrity mechanism to
be used; non-repudiation can be applied to context if desired.
BNR's work began with an interface for store-and-forward messaging
support, subsequently generalized for on-line, association-oriented
operation. BNR intends to offer the proposal as the basis for an
Internet standards track protocol. The development and distribution
status of a reference implementation for SPKM is not currently known,
but implementation is underway at Northern Telecom and/or BNR, and
feedback on the proposed approach is solicited.
Example tokens and exchanges were presented: A Req_Token initiates all
exchanges. The token structure is X.509-compliant, with some elements
optional. A key establishment OID's value describes the exchange
which is to follow. Context_Data provides the parameters describing a
context. The Seal token bears OIDs for each of the integrity,
sequence, and confidentiality algorithms: it carries an explicit OID
if the parameters established at context initiation allow more than
one, and is otherwise NULL. Questions about alignment and padding of
variable-length fields were raised and discussed.
Issue: how do you handle later validation of a long-term signature,
once the context handle is no longer valid? Long-term signing was an
interest and a design consideration but is not a requirement.
Carlisle's conclusions slide summarized the following observations:
SPKM has advantages over alternatives, in terms of flexibility,
non-repudiation, negotiation support, and no required reliance on
secure timestamps.
IMAP AUTHENTICATION
In the CAT WG's second session, John Myers (CMU) led a discussion on
Interactive Mail Access Protocol (IMAP) authentication. This
approach, currently in last call for advancement to Proposed Standard,
implements an IMAP4 AUTHENTICATE command, based on FTP security's
AUTH/ADAT commands. It identifies authentication mechanisms by name,
and supports an arbitrary number of base64-encoded exchanges. Privacy
and integrity protection are supported; the authorization userid is
independent of the authentication ID. In contrast to FTP security,
there is no separate data vs. control channel. User-ID, protection
mechanism, and buffer size are negotiated during the authentication
exchange. Use of a protection mechanism is optional. IMAP
authentication has no interaction with plaintext login.
Examples were shown using Kerberos V4 and S/Key; a GSS-API mechanism
is defined as well (protecting option exchange with GSS_Seal()).
GSS-API and S/Key mechanisms are not yet implemented; Ted Ts'o
expressed interest in integrating with the Kerberos V5 development
stream via GSS-API if the IMAP code is distributable. In the IMAP
Kerberos mechanism, the client closes out the exchange by mutually
authenticating back to the server and declaring accepted service
options. Design intentionally uses server-issued challenges, so as to
protect against replays even within the Kerberos 5 minute timestamp
window. Couldn't use S/Key with FTP security as it stands, since the
FTP security draft demands integrity on negotiation. It was suggested
that we consider changing the FTP security draft to enable conformant
use of S/Key.
DISCUSSION OF PROPOSED GSS-API CONTINUATION PROCESSING OF
LONG MESSAGES
During the course of the SPKM presentation slot, Carlisle Adams
suggested a GSS-API extension to accept segments of long buffers with
continuation flag parameters: add to gss_seal an "end_flag" which can
accept GSS_S_CONTINUE_NEEDED and add to gss_unseal the ability to
indicate that non-final vs. final segments are being emitted. Ted
Ts'o noted that the primary problem in the area of long message
processing is that the sender doesn't know how big a token the
receiver can handle. Carlisle was more concerned with the local
interface issue than with the issue of sizes supported by remote
peers. Bill Sommerfeld (HP) observed that application and GSS-API
should "cooperate" in terms of segment sizes.
The argument was made that the use of sequencing mechanisms and
per-message integrity vs. a single binding signature spanning multiple
data units is sufficient within the scope of an association-oriented
context; the binding signature might be more valuable in a
store-and-forward document scenario.
Three possible measures present themselves:
(1) Application calls a new GSS-API facility to find out how big a
token it can pass in in order to get an output token no bigger than
the maximum acceptable size. Compression can introduces variability
in the output size which will result for different data of the same
input size. The new facility needs to accept as input the QOP value
which is to be requested for data protection. Action: Incorporate
this facility for GSSV2.
(2) Constrain mechanisms so that arbitrary fragments, split within the
GSS-API or below, can be independently validated. (This had been a
discussion topic at the Seattle meeting, with Steve Lunt and others.)
We agreed not to impose this constraint.
(3) There was interest in a facility to distinguish an ordered stream
of non-initial segments from a final segment. P. Rajaram argued that
this would resolve the issue of not having enough memory to process
the data unit as a whole. Controversy revolved around whether this
was an appropriate facility at the level of the interface rather than
an application-specific issue above the interface. In Ted Ts'o's
proposed CATS package, connection close was indicated explicitly by
the CATS protocol, rendering moot the need to distinguish a final
message at the level of the GSS-API interface. After discussion, we
resolved (pending mailing list confirmation) not to incorporate
interface-level message continuation facilities.
CONTEXT EXPIRATION
We discussed context expiration within the Kerberos mechanism,
distinguishing enforced expiration (disabling per-message protection
when expiration time is reached) vs. advisory expiration (continuing
to perform per-message protection operations, with informatory status)
vs. no expiration. Advisory and enforced expiration cases can be
further subdivided into uniformly-performed expiration vs. expiration
performed only if requested by a caller at context expiration time.
Much of the interest in application-selectable expiration relates to
use as a trigger to garbage-collect keys and related data. Possible
inputs to an expiration policy would include (some combination of)
user-requested time, expiration time(s) of relevant tickets, local
configuration data, and input received from a peer.
In any of these scenarios, except "no expiration", applications must
be able to accomodate the occurrence of a no-longer-valid context,
effectively renewing by initiating a new one. It was suggested as a
possibly useful extension for init_context or an alternative routine
thereto to be able to accept an existing context handle as input for
renewal through establishment of a new context, but no detailed
exploration or conclusion on this suggestion was reached.
A prospect of "soft expiration", where advisory errors would be
received at a point in time before the context no longer operated, was
discussed but rejected as introducing unneeded complexity and being
ineffective for recovery after a context has been idle across both of
its "soft" and "hard" expiration times (e.g., after a user walks away
from a terminal, returns sometime later, and attempts to resume a
session). It was also observed that an application desiring a "soft"
warning could easily pass a time value appropriately less than the
context_time output as received from init_sec_context to an
OS-specific timer facility outside GSS-API.
In initial discussion relative to the Kerberos mechanism, popular
sentiment favored no expiration, but a range of views were expressed.
Bill Sommerfeld noted that DCE enforces hard expiration (with some
time windowing), but that this appeared more feasible in the DCE RPC
environment where RPC calls are typically short-lived than in the
general GSS-API case. In DCE RPC, expiration is enforced only for
call establishment, not within an already-established call. Ted Ts'o
asserted that expiration should not be enforced for at least the class
of rlogin-like applications, to avoid disrupting outstanding
associations. P. Rajaram also argued that enforced expiration was
unacceptably disruptive, and that advisory expiration wasn't a useful
service for GSS-API to provide; Bill Sommerfeld observed that advisory
expiration could be a convenient timing service, but that the
motivation didn't appear compelling. Piers McMahon observed that
context expiration didn't enable a useful policy enforcement
mechanism, recognizing that use of all GSS-API facilities is at an
application's discretion. Jeff Schiller (MIT) proposed that no
context should last forever, and that for the Kerberos mechanism the
expiration time should be no later than the expiration of the
ticket(s) which are used to establish the context. After active
discussion, this was accepted as our working proposal.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07748;
3 Aug 94 12:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07744;
3 Aug 94 12:33 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa10295;
3 Aug 94 12:33 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id CAA09234; Thu, 4 Aug 1994 02:16:46 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id CAA09209; Thu, 4 Aug 1994 02:07:50 +1000
Precedence: list
Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA17701; Thu, 4 Aug 1994 00:18:29 +1000 (from kasten at mailserv-D.ftp.com)
Received: from ftp.com by ftp.com ; Wed, 3 Aug 1994 10:18:26 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 3 Aug 1994 10:18:26 -0400
Received: by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA02333; Wed, 3 Aug 94 10:15:56 EDT
Date: Wed, 3 Aug 94 10:15:56 EDT
Message-Id: <9408031415.AA02333 at mailserv-D.ftp.com>
To: martillo at pluto.dss.com
Subject: Re: IPng recommendation
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Content-Length: 13031
Joachim,
First of all, comments would have been preferred during the debate.
Certainly before the IPng choice. Comments now are roughly akin to
locking the barn door after the horse has run off, though since there
is still IPNG development work to be done, I am sure that the IPng
developers will carefully consider your points.
Second, one of the 'principles' which Craig and I started using in
refining the criteria was what has been called 'In your face'
requirements. If the criteria were set at a relatively 'safe' or
'low' level, then that is all we might get. You mention, for example,
10**15 end nodes. If we had set, for example, 10**10 end nodes, then
that is possibly all we would get. By setting a higher level, we may
still get only 10**10, but we might also get more. Furthermore, by
saying 10**15, the developers (and the rest of the community) may
think more about what a truly ubiquious global internetwork might
need and what it could do.
> After noticing some of the discussion of IPng criteria, I ftp'd over
> the criteria. Exactly how to interpret this document is unclear.
This document, in its final form, was considered as a framework (not
the only one) about which discussions of the various IPNG candidates
could be held by the IPng directorate. You might, in effect, consider
the section headings to be an 'agenda' of items to be evaluated in
the various proposals.
> >5.3. Performance
>
> >Furthermore, at a minimum, a
> >host must be able to achieve data transfer rates with
> >IPng comparable to the rates achieved with IPv4, using
> >similar levels of host resources.
>
> Since poor router performance can affect a whole internet rather than
> simply an individual host, the criterion should have concentrated
> attention on router performance.
It originally did. However, it was also pointed out that if IPng made
host performance 'very bad' then, even if the routers were blindingly
fast, IPng would be a loser. Furthermore, IPng really should not be
perceived as a step backwards wrt IPv4. If IPng made hosts
significantly slower then it would be just such a step.
Now, this might all seem trivial, obvious, irrelevant, and
motherhood. But, on the other hand, host performance was a major
factor in the discussion about addressing on the big-i list. If host
performance wasn't critical then that discussion may well have had a
different outcome.
> >We limit this requirement to commercially available
> >routers and media. If some network site can obtain a
> >particular media technology "off the shelf", then it
> >should also be able to obtain the needed routing
> >technology "off the shelf." One can always go into some
> >laboratory or research center and find newer, faster,
> >technologies for network media and for routing. We do
> >believe, however, that IPng should be routable at a speed
> >sufficient to fully utilize the fastest available media,
> >though that might require specially built, custom,
> >devices.
>
> This comment suggests that the new address structure should enable the
> quickest possible route look-up. The quickest possible route look-up
> means that a network number should conveniently correspond to a
> natural register size on common communications computers and that
> accesses to slower processor external memory should be minimized.
> Such needs and 16 byte addresses are hard to reconcile with current
> router technology.
First, we attempted to stay as far away from dictating implementation
as we could. Your comment implies that we should have said, for
example, that addresses must have a 4-byte (or whatever number)
network number field. This would be dangerously close to specifying
the implementation, and not pointing out the problems that were to be
solved. (By pointing out the problem, we in theory allowed for a qide
variety of solutions.)
Second, some people are envisioning that a majority of traffic in the
future internet will be forwarded not based on topological
information carried around in the packet, but rather on a smaller,
more easily handled, 'flow-id' which would have the properties you
talk about. I note that SIPP has such a flowid.
> >We expect that more and more services will be available
> >over the Internet. It is not unreasonable, therefore, to
> >expect that the ratio of "local" traffic (i.e. the
> >traffic that stays on one's local network) to "export"
> >traffic (i.e. traffic destined to or sourced from a
> >network other than one's own local network) will change,
> >and the percent of export traffic will increase.
>
> This observation is not obviously true... A
> concentration on export traffic in the design of IPng would be
> misguided.
Possibly. It also raises the possibility of new models of use for a
commercial service Internet. Consider things like a home computer, or
doing cable TV via the Internet. In these cases, ALL network traffic
would be exported. Our hope is that the criteria document spurred
some people to think about the future and what it might bring.
> >We also observe that many researchers believe that a
> >proper IPng router should be capable of routing IPng
> >traffic over links at speeds that are capable of fully
> >utilizing an ATM switch on the link.
>
> ATM is yet another fad technology whose fad may be approaching its
> end...A better targer might be wire-speed routing in the context of a LAN
> switch using fast Ethernet or CDDI.
The base criterion does not mention any specific technology. We felt
that we could not accurately predict what technology would be the
'right' technology in 5 or 10 years. After all, wrt your observation
on ATM, only 1 or 2 years ago, many people were predicting that ATM
would take over the world. We make the criterion apply to 'common
commercial technology' which allows it to be flexible and to change
over time for the next 10-20 years.
> >Some predictions have been made that, as the Internet
> >grows and as more and more technically less-sophisticated
> >sites get connected, there will be more failures in the
> >network. These failures may be a combination of simple
> >size; if the size of the network goes up by a factor of n
> >then the total number of failures in the network can be
> >expected to increase by some function of n. Also, as the
> >network's users become less sophisticated, it can be
> >assumed that they will make more, innocent and well
> >meaning, mistakes, either in configuration or use of
> >their systems.
>
> This comment is just the typical obnoxious snobbishness of
> communications software engineers. If anything, the level of
> sophistication will probably increase with an increase in the number
> of sites which connect to the internet....When lots of people have
> set up and
> run multiprotocol internetworks, a little knowledge will hardly
> impress anybody.
Perhaps. However, history may be against you. I recall an IETF in
recent history (less than 2 years ago) where the terminal room was
set up by a major organization. They couldn't understand _why_ we
wanted domain name service available for the terminals and laptops.
Also, we are envisioning a future where the entities who connect to
the Internet will not be like they are today. They will be sites that
are non-technical (in the networking sense) and probably will not
have the system operations staff that current sites have. Imagine a
dentist's office connecting to the network. This is also the reason
why we are stressing a 'plug-and-play' configuration ability. The
less that has to be configured, the less chance of making such errors.
> >5.5. Transition
> >The transition plan should address the issue of cost
> >distribution. That is, it should identify what tasks are
> >required of the service providers, of the end users, of
> >the backbones and so on.
>
> This comment is rather scary. The IETF collectively has no obvious
> expertise in public finance, accounting or political economics.
The first step in figuring out the 'public finance, accounting or
political economics' issues it to determine exactly what has to be
done. That's all we are saying.
> >5.12. Multicast
>
> >CRITERION
> >The protocol must support both unicast and multicast
> >packet transmission. Part of the multicast capability is
> >a requirement to be able to send to "all IP hosts on a
> >given subnetwork". Dynamic and automatic routing of
> >multicasts is also required.
>
> >DISCUSSION
> >IPv4 has made heavy use of the ability to multicast
> >requests to all IPv4 hosts on a subnet, especially for
> >autoconfiguration. This ability must be retained in
> >IPng.
>
> >Unfortunately, IPv4 currently uses the local media
> >broadcast address to multicast to all IP hosts. This
> >behavior is anti-social in mixed-protocol networks and
> >should be fixed in IPng. There's no good reason for IPng
> >to send to all hosts on a subnet when it only wishes to
> >send to all IPng hosts. The protocol must make
> >allowances for media that do not support true
> >multicasting.
>
> The above comment is idiotic. Exactly how a network layer multicast
> is resolved to a MAC layer address for some arbitrary medium is not
> obviously part of the network layer design.
It says 'When mac-layer multicasting is available, use it in preference
to broadcasts.'
> Furthermore, as Appletalk
> has abundantly shown a protocol that uses multicast exclusively can
> certainly be antisocial in the sense of burning up a lot of bandwidth.
This criterion does not say that one should use multicasts instead of
unicasts. There are certain types of applications (eg multi-person
conferencing, finding servers) where using unicasts is not the best
way to go. If the existance of these applications is a given, then we
have a choice of using MAC-level multicasts or broadcasts (where
mcasts are available). We believe that multicasts are preferred in
these situations.
> >5.17. Private Networks
> >DISCUSSION
> >We note that, today in the IPv4 Internet, tunneling is
> >widely used to provide these capabilities.
>
> Because multiprotocol routers are so common today,
> tunneling non-IP suites through IP is just silly except in cases of
> router misdesign in which case a new router should probably be
> obtained.
Maybe one is not tunneling non-IP traffic. Perhaps one is building a
private IP network on top of the IP Internet to, for example,
cooperatively develop and test new routing protocols.
> >6. Routing
>
> >Routing is a very critical part of the Internet. In fact, the
> >Internet Engineering Task Force has a separate Area which is
> >chartered to deal only with routing issues. This Area is
> >separate from the more general Internet Area.
>
> >We see that routing is also a critical component of IPng.
> >There are several criteria, such as Scaling, Addressing, and
> >Network Services, which are intimately entwined with routing.
>
> Shouldn't routing performance be included among these critical
> components?
What exactly is routing performance? There are at least three
separate functions that are commonly subsumed under the term
'routing' and the performance could apply to any of the three. We
believe that we have performance of Forwarding packets well covered.
The other functions, information distribution (i.e. the routing
protocols) and route calculation are harder to specify. Should we say
that the 'Routing Protocols should be efficient' and 'Route
calculation should be fast'? This seems too nebulous.
> >6.5. Stability
> >This must not be allowed to happen. If anything, routes
> >should be even more stable under IPng's routing architecture
> >than under the current architecture.
>
> Does this mean load sharing between equal cost and near equal cost
> routes (IGRP) is to be dropped from the architecture?
I don't see switching packets between the several paths of a
multi-path route as route-flapping. I consider the paths of a a
multi-path route as a single 'route' for the purposes of this
discussion. The main reason that route flapping is considered 'bad'
is that route setup in the future may take into account things other
than mere reachability (see the work on integrated services). For a
multi-path route to fit into this model, all paths would have to have
the required service levels so swapping between any of the paths is
really not an issue. The issue arises when the routing subsystems
select a new path based on reachability but the necessary service
levels are not available.
The other problem with route flapping is that one may never get a
route. The 'primary' route goes down. The routing subsystem starts
to reconfigure to use an 'alternate' route and then the 'primary'
comes back up. The routing subsystem then re-reconfigures to use the
primary and it goes down again. Repeat. In doing multipath, this
isn't really an issue since both paths are already 'active'.
--
Frank Kastenholz
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08783;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11262;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08684;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08402;
3 Aug 94 13:11 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-resource-names-02.txt
Date: Wed, 03 Aug 94 13:11:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031311.aa08402 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Names
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-uri-resource-names-02.txt
Pages : 4
Date : 08/02/1994
A Uniform Resource Name (URN) is an identifier which can be used to
uniquely identify a resource, and is designed to provide persistent naming
for networked objects. This name would stay the same no matter what the
current location(s) of the object was.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-resource-names-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-resource-names-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-resource-names-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-resource-names-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08783;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11262;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08684;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08402;
3 Aug 94 13:11 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-resource-names-02.txt
Date: Wed, 03 Aug 94 13:11:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031311.aa08402 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Names
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-uri-resource-names-02.txt
Pages : 4
Date : 08/02/1994
A Uniform Resource Name (URN) is an identifier which can be used to
uniquely identify a resource, and is designed to provide persistent naming
for networked objects. This name would stay the same no matter what the
current location(s) of the object was.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-resource-names-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-resource-names-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-resource-names-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-resource-names-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08804;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11258;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08688;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08465;
3 Aug 94 13:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: i2i at sophia.inria.fr
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-mou2jtc1-03.txt
Date: Wed, 03 Aug 94 13:13:00 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031313.aa08465 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Proposed Cooperative Agreement Between the
Internet Society and ISO/IEC JTC 1/SC 6
Author(s) : C. Huitema
Filename : draft-iab-mou2jtc1-03.txt
Pages : 5
Date : 08/02/1994
The IAB has been working toward establishing a liaison relationship between
the Internet Society and ISO/JTC 1. A liaison with ISO/IEC JTC 1/SC 6 has
been offered, and there have been indications that liaisons with any of the
other SCs will be granted without problems as needed.
Further progress is subject to the preparation and approval of
a "cooperative agreement" between the two organizations. The present
document is a draft of that cooperative agreement. It stresses the main
points of agreement: mutual recognition of standards, information on work
programs, information sharing and possible collaborative efforts.
In line with JTC 1 decisions, this draft cooperative agreement covers
liaison with SC 6. The Internet Society looks forward to establishing
similar liaisons with other appropriate JTC 1 subcommittees in the
near future.
This version is a draft. It will have to be reviewed by the members of the
Internet community and discussed with ISO/IEC JTC 1. The term
"organization" in the following refers either to the Internet Society or
to SC 6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-iab-mou2jtc1-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-iab-mou2jtc1-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802130849.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-iab-mou2jtc1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-mou2jtc1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802130849.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08804;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11258;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08688;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08465;
3 Aug 94 13:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: i2i at sophia.inria.fr
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-mou2jtc1-03.txt
Date: Wed, 03 Aug 94 13:13:00 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031313.aa08465 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Proposed Cooperative Agreement Between the
Internet Society and ISO/IEC JTC 1/SC 6
Author(s) : C. Huitema
Filename : draft-iab-mou2jtc1-03.txt
Pages : 5
Date : 08/02/1994
The IAB has been working toward establishing a liaison relationship between
the Internet Society and ISO/JTC 1. A liaison with ISO/IEC JTC 1/SC 6 has
been offered, and there have been indications that liaisons with any of the
other SCs will be granted without problems as needed.
Further progress is subject to the preparation and approval of
a "cooperative agreement" between the two organizations. The present
document is a draft of that cooperative agreement. It stresses the main
points of agreement: mutual recognition of standards, information on work
programs, information sharing and possible collaborative efforts.
In line with JTC 1 decisions, this draft cooperative agreement covers
liaison with SC 6. The Internet Society looks forward to establishing
similar liaisons with other appropriate JTC 1 subcommittees in the
near future.
This version is a draft. It will have to be reviewed by the members of the
Internet community and discussed with ISO/IEC JTC 1. The term
"organization" in the following refers either to the Internet Society or
to SC 6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-iab-mou2jtc1-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-iab-mou2jtc1-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802130849.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-iab-mou2jtc1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-mou2jtc1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802130849.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08808;
3 Aug 94 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08783;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11262;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08684;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08402;
3 Aug 94 13:11 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-resource-names-02.txt
Date: Wed, 03 Aug 94 13:11:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031311.aa08402 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Names
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-uri-resource-names-02.txt
Pages : 4
Date : 08/02/1994
A Uniform Resource Name (URN) is an identifier which can be used to
uniquely identify a resource, and is designed to provide persistent naming
for networked objects. This name would stay the same no matter what the
current location(s) of the object was.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-resource-names-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-resource-names-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-resource-names-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-resource-names-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08810;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11263;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08686;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08319;
3 Aug 94 13:09 EDT
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.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-md5-00.txt
Date: Wed, 03 Aug 94 13:09:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031309.aa08319 at IETF.CNRI.Reston.VA.US>
--NextPart
A New 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 MD5 Authentication
Author(s) : F. Baker, C. Huitema
Filename : draft-ietf-ospf-md5-00.txt
Pages : 7
Date : 08/02/1994
Growth in the Internet has made us aware of the need for improved
authentication of routing information. OSPF provides two authentication
mechanisms that can be used in an area: "No Authentication" and "Simple
Password".
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ospf-md5-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-md5-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802103731.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802103731.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08810;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11263;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08686;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08319;
3 Aug 94 13:09 EDT
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.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-md5-00.txt
Date: Wed, 03 Aug 94 13:09:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031309.aa08319 at IETF.CNRI.Reston.VA.US>
--NextPart
A New 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 MD5 Authentication
Author(s) : F. Baker, C. Huitema
Filename : draft-ietf-ospf-md5-00.txt
Pages : 7
Date : 08/02/1994
Growth in the Internet has made us aware of the need for improved
authentication of routing information. OSPF provides two authentication
mechanisms that can be used in an area: "No Authentication" and "Simple
Password".
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ospf-md5-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-md5-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802103731.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802103731.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08817;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11259;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08690;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08341;
3 Aug 94 13:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-vision-02.txt
Date: Wed, 03 Aug 94 13:09:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031309.aa08341 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : A Vision of an Integrated Internet Information Service
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-iiir-vision-02.txt
Pages : 8
Date : 08/02/1994
This paper lays out a vision of how Internet information services might be
integrated over the next few years, and discusses in some detail what steps
will be needed to achieve this integration.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-vision-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iiir-vision-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110212.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iiir-vision-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-vision-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110212.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08817;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11259;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08690;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08341;
3 Aug 94 13:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-vision-02.txt
Date: Wed, 03 Aug 94 13:09:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031309.aa08341 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : A Vision of an Integrated Internet Information Service
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-iiir-vision-02.txt
Pages : 8
Date : 08/02/1994
This paper lays out a vision of how Internet information services might be
integrated over the next few years, and discusses in some detail what steps
will be needed to achieve this integration.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-vision-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iiir-vision-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110212.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iiir-vision-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-vision-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110212.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08822;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11274;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08702;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08585;
3 Aug 94 13:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-davin-qosrep-00.txt
Date: Wed, 03 Aug 94 13:14:07 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031314.aa08585 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Representing Service Quality In a Multi-Service Internet
Author(s) : J. Davin
Filename : draft-davin-qosrep-00.txt
Pages : 18
Date : 08/02/1994
This paper describes how a comprehensive account of service quality fosters
efficient and economical growth in a multi-service internet. A possible
representation of end-to-end internet service quality is also presented.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-davin-qosrep-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davin-qosrep-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802132555.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-davin-qosrep-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davin-qosrep-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802132555.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08822;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11274;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08702;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08585;
3 Aug 94 13:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-davin-qosrep-00.txt
Date: Wed, 03 Aug 94 13:14:07 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031314.aa08585 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Representing Service Quality In a Multi-Service Internet
Author(s) : J. Davin
Filename : draft-davin-qosrep-00.txt
Pages : 18
Date : 08/02/1994
This paper describes how a comprehensive account of service quality fosters
efficient and economical growth in a multi-service internet. A possible
representation of end-to-end internet service quality is also presented.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-davin-qosrep-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davin-qosrep-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802132555.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-davin-qosrep-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davin-qosrep-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802132555.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08842;
3 Aug 94 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08804;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11258;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08688;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08465;
3 Aug 94 13:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: i2i at sophia.inria.fr
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-mou2jtc1-03.txt
Date: Wed, 03 Aug 94 13:13:00 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031313.aa08465 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Proposed Cooperative Agreement Between the
Internet Society and ISO/IEC JTC 1/SC 6
Author(s) : C. Huitema
Filename : draft-iab-mou2jtc1-03.txt
Pages : 5
Date : 08/02/1994
The IAB has been working toward establishing a liaison relationship between
the Internet Society and ISO/JTC 1. A liaison with ISO/IEC JTC 1/SC 6 has
been offered, and there have been indications that liaisons with any of the
other SCs will be granted without problems as needed.
Further progress is subject to the preparation and approval of
a "cooperative agreement" between the two organizations. The present
document is a draft of that cooperative agreement. It stresses the main
points of agreement: mutual recognition of standards, information on work
programs, information sharing and possible collaborative efforts.
In line with JTC 1 decisions, this draft cooperative agreement covers
liaison with SC 6. The Internet Society looks forward to establishing
similar liaisons with other appropriate JTC 1 subcommittees in the
near future.
This version is a draft. It will have to be reviewed by the members of the
Internet community and discussed with ISO/IEC JTC 1. The term
"organization" in the following refers either to the Internet Society or
to SC 6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-iab-mou2jtc1-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-iab-mou2jtc1-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802130849.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-iab-mou2jtc1-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-mou2jtc1-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802130849.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08863;
3 Aug 94 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08810;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11263;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08686;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08319;
3 Aug 94 13:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-md5-00.txt
Date: Wed, 03 Aug 94 13:09:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031309.aa08319 at IETF.CNRI.Reston.VA.US>
--NextPart
A New 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 MD5 Authentication
Author(s) : F. Baker, C. Huitema
Filename : draft-ietf-ospf-md5-00.txt
Pages : 7
Date : 08/02/1994
Growth in the Internet has made us aware of the need for improved
authentication of routing information. OSPF provides two authentication
mechanisms that can be used in an area: "No Authentication" and "Simple
Password".
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ospf-md5-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-md5-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802103731.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802103731.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08865;
3 Aug 94 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08822;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11274;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08702;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08585;
3 Aug 94 13:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-davin-qosrep-00.txt
Date: Wed, 03 Aug 94 13:14:07 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031314.aa08585 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Representing Service Quality In a Multi-Service Internet
Author(s) : J. Davin
Filename : draft-davin-qosrep-00.txt
Pages : 18
Date : 08/02/1994
This paper describes how a comprehensive account of service quality fosters
efficient and economical growth in a multi-service internet. A possible
representation of end-to-end internet service quality is also presented.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-davin-qosrep-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davin-qosrep-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802132555.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-davin-qosrep-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davin-qosrep-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802132555.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08861;
3 Aug 94 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08817;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11259;
3 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08690;
3 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08341;
3 Aug 94 13:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-vision-02.txt
Date: Wed, 03 Aug 94 13:09:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031309.aa08341 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : A Vision of an Integrated Internet Information Service
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-iiir-vision-02.txt
Pages : 8
Date : 08/02/1994
This paper lays out a vision of how Internet information services might be
integrated over the next few years, and discusses in some detail what steps
will be needed to achieve this integration.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-vision-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iiir-vision-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110212.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iiir-vision-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-vision-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110212.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08955;
3 Aug 94 13:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11341;
3 Aug 94 13:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08902;
3 Aug 94 13:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08661;
3 Aug 94 13:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-davin-rsvfms-00.txt
Date: Wed, 03 Aug 94 13:15:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031315.aa08661 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Service Management For a Next-Generation Internet
Protocol
Author(s) : J. Davin
Filename : draft-davin-rsvfms-00.txt
Pages : 30
Date : 08/02/1994
The operational impact of deploying real-time service support into the
internet may be greater even than the impact of deploying of novel routing
and addressing features. First, introduction of diverse service qualities
may alter usage patterns in ways that are inconsistent with current
provisioning. Second, the initial deployment required to reap the benefits
of multi-service internetworking is broader than that required to meet
current routing and addressing challenges, for while benefits of enhanced
routing and addressing paradigms may require only incremental deployments
coupled with tunneling or encapsulation strategies, advances in real-time
service quality accrue only along paths where the relevant technology is
deployed end-to-end.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-davin-rsvfms-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davin-rsvfms-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802135942.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-davin-rsvfms-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davin-rsvfms-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802135942.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08955;
3 Aug 94 13:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11341;
3 Aug 94 13:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08902;
3 Aug 94 13:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08661;
3 Aug 94 13:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-davin-rsvfms-00.txt
Date: Wed, 03 Aug 94 13:15:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031315.aa08661 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Service Management For a Next-Generation Internet
Protocol
Author(s) : J. Davin
Filename : draft-davin-rsvfms-00.txt
Pages : 30
Date : 08/02/1994
The operational impact of deploying real-time service support into the
internet may be greater even than the impact of deploying of novel routing
and addressing features. First, introduction of diverse service qualities
may alter usage patterns in ways that are inconsistent with current
provisioning. Second, the initial deployment required to reap the benefits
of multi-service internetworking is broader than that required to meet
current routing and addressing challenges, for while benefits of enhanced
routing and addressing paradigms may require only incremental deployments
coupled with tunneling or encapsulation strategies, advances in real-time
service quality accrue only along paths where the relevant technology is
deployed end-to-end.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-davin-rsvfms-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davin-rsvfms-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802135942.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-davin-rsvfms-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davin-rsvfms-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802135942.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08966;
3 Aug 94 13:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08955;
3 Aug 94 13:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11341;
3 Aug 94 13:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08902;
3 Aug 94 13:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08661;
3 Aug 94 13:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-davin-rsvfms-00.txt
Date: Wed, 03 Aug 94 13:15:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031315.aa08661 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Service Management For a Next-Generation Internet
Protocol
Author(s) : J. Davin
Filename : draft-davin-rsvfms-00.txt
Pages : 30
Date : 08/02/1994
The operational impact of deploying real-time service support into the
internet may be greater even than the impact of deploying of novel routing
and addressing features. First, introduction of diverse service qualities
may alter usage patterns in ways that are inconsistent with current
provisioning. Second, the initial deployment required to reap the benefits
of multi-service internetworking is broader than that required to meet
current routing and addressing challenges, for while benefits of enhanced
routing and addressing paradigms may require only incremental deployments
coupled with tunneling or encapsulation strategies, advances in real-time
service quality accrue only along paths where the relevant technology is
deployed end-to-end.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-davin-rsvfms-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-davin-rsvfms-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802135942.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-davin-rsvfms-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-davin-rsvfms-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802135942.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09060;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11439;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09040;
3 Aug 94 13:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08722;
3 Aug 94 13:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-mesh-00.txt
Date: Wed, 03 Aug 94 13:17:04 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031317.aa08722 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : How to interact with a Whois++ mesh
Author(s) : P. Faltstrom, R. Schoultz, C. Weider
Filename : draft-ietf-wnils-whois-mesh-00.txt
Pages : 4
Date : 08/02/1994
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done
by the client, since each server 'refers' the client to the next
appropriate server(s). The protocol is simple. The client opens a
connection to a server, sends a query, receives a reply, closes the
connection, and after parsing the response the client decides which server
to contact next, if necessary.
So, the client needs to have an algorithm to follow when it interacts with
the Whois++ mesh so that referral loops can be detected, cost is minimised,
and appropriate servers are rapidly and effectively contacted.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-mesh-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-mesh-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-mesh-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-mesh-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09060;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11439;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09040;
3 Aug 94 13:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08722;
3 Aug 94 13:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-mesh-00.txt
Date: Wed, 03 Aug 94 13:17:04 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031317.aa08722 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : How to interact with a Whois++ mesh
Author(s) : P. Faltstrom, R. Schoultz, C. Weider
Filename : draft-ietf-wnils-whois-mesh-00.txt
Pages : 4
Date : 08/02/1994
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done
by the client, since each server 'refers' the client to the next
appropriate server(s). The protocol is simple. The client opens a
connection to a server, sends a query, receives a reply, closes the
connection, and after parsing the response the client decides which server
to contact next, if necessary.
So, the client needs to have an algorithm to follow when it interacts with
the Whois++ mesh so that referral loops can be detected, cost is minimised,
and appropriate servers are rapidly and effectively contacted.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-mesh-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-mesh-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-mesh-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-mesh-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09073;
3 Aug 94 13:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09060;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11439;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09040;
3 Aug 94 13:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08722;
3 Aug 94 13:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-mesh-00.txt
Date: Wed, 03 Aug 94 13:17:04 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031317.aa08722 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : How to interact with a Whois++ mesh
Author(s) : P. Faltstrom, R. Schoultz, C. Weider
Filename : draft-ietf-wnils-whois-mesh-00.txt
Pages : 4
Date : 08/02/1994
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done
by the client, since each server 'refers' the client to the next
appropriate server(s). The protocol is simple. The client opens a
connection to a server, sends a query, receives a reply, closes the
connection, and after parsing the response the client decides which server
to contact next, if necessary.
So, the client needs to have an algorithm to follow when it interacts with
the Whois++ mesh so that referral loops can be detected, cost is minimised,
and appropriate servers are rapidly and effectively contacted.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-mesh-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-mesh-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-mesh-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-mesh-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09101;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11449;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09057;
3 Aug 94 13:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08917;
3 Aug 94 13:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-arch-01.txt
Date: Wed, 03 Aug 94 13:18:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031318.aa08917 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : Architecture of the WHOIS++ service
Author(s) : P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider
Filename : draft-ietf-wnils-whois-arch-01.txt
Pages : 44
Date : 08/02/1994
This document describes WHOIS++, an extension to the trivial WHOIS service
described in RFC 954 to permit WHOIS-like servers to make available more
structured information to the Internet. We describe an extension to the
simple WHOIS data model and query protocol and a companion extensible,
distributed indexing service. A number of options have also been added
such as the use of multiple languages and character sets, more advanced
search expressions, structured data and a number of other useful features.
An optional authentication mechanism for protecting all or part of the
associated WHOIS++ information database from unauthorized access is also
described.
The additional architectural issues and commands added to support the
distributed indexing service are described in [Weider94]. This present
document should be read in conjunction with the additional reference.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-arch-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09101;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11449;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09057;
3 Aug 94 13:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08917;
3 Aug 94 13:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-arch-01.txt
Date: Wed, 03 Aug 94 13:18:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031318.aa08917 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : Architecture of the WHOIS++ service
Author(s) : P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider
Filename : draft-ietf-wnils-whois-arch-01.txt
Pages : 44
Date : 08/02/1994
This document describes WHOIS++, an extension to the trivial WHOIS service
described in RFC 954 to permit WHOIS-like servers to make available more
structured information to the Internet. We describe an extension to the
simple WHOIS data model and query protocol and a companion extensible,
distributed indexing service. A number of options have also been added
such as the use of multiple languages and character sets, more advanced
search expressions, structured data and a number of other useful features.
An optional authentication mechanism for protecting all or part of the
associated WHOIS++ information database from unauthorized access is also
described.
The additional architectural issues and commands added to support the
distributed indexing service are described in [Weider94]. This present
document should be read in conjunction with the additional reference.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-arch-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09113;
3 Aug 94 13:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09101;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11449;
3 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09057;
3 Aug 94 13:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08917;
3 Aug 94 13:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-wnils at ucdavis.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-arch-01.txt
Date: Wed, 03 Aug 94 13:18:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031318.aa08917 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : Architecture of the WHOIS++ service
Author(s) : P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider
Filename : draft-ietf-wnils-whois-arch-01.txt
Pages : 44
Date : 08/02/1994
This document describes WHOIS++, an extension to the trivial WHOIS service
described in RFC 954 to permit WHOIS-like servers to make available more
structured information to the Internet. We describe an extension to the
simple WHOIS data model and query protocol and a companion extensible,
distributed indexing service. A number of options have also been added
such as the use of multiple languages and character sets, more advanced
search expressions, structured data and a number of other useful features.
An optional authentication mechanism for protecting all or part of the
associated WHOIS++ information database from unauthorized access is also
described.
The additional architectural issues and commands added to support the
distributed indexing service are described in [Weider94]. This present
document should be read in conjunction with the additional reference.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-arch-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09390;
3 Aug 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11668;
3 Aug 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09370;
3 Aug 94 13:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09209;
3 Aug 94 13:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-05.txt
Date: Wed, 03 Aug 94 13:23:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031323.aa09209 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-05.txt
Pages : 21
Date : 08/02/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09390;
3 Aug 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11668;
3 Aug 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09370;
3 Aug 94 13:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09209;
3 Aug 94 13:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-05.txt
Date: Wed, 03 Aug 94 13:23:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031323.aa09209 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-05.txt
Pages : 21
Date : 08/02/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09402;
3 Aug 94 13:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09390;
3 Aug 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11668;
3 Aug 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09370;
3 Aug 94 13:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09209;
3 Aug 94 13:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-05.txt
Date: Wed, 03 Aug 94 13:23:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031323.aa09209 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-05.txt
Pages : 21
Date : 08/02/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09434;
3 Aug 94 13:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11684;
3 Aug 94 13:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09421;
3 Aug 94 13:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09262;
3 Aug 94 13:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-myers-pop3-auth-01.txt
Date: Wed, 03 Aug 94 13:25:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031325.aa09262 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : POP3 AUTHentication command
Author(s) : J. G. Myers
Filename : draft-myers-pop3-auth-01.txt
Pages : 5
Date : 08/02/1994
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism for
subsequent protocol interactions. The authentication and protection
mechanisms used by the POP3 AUTH command are those used by IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-myers-pop3-auth-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-pop3-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802150828.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-myers-pop3-auth-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-pop3-auth-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802150828.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09434;
3 Aug 94 13:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11684;
3 Aug 94 13:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09421;
3 Aug 94 13:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09262;
3 Aug 94 13:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-myers-pop3-auth-01.txt
Date: Wed, 03 Aug 94 13:25:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031325.aa09262 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : POP3 AUTHentication command
Author(s) : J. G. Myers
Filename : draft-myers-pop3-auth-01.txt
Pages : 5
Date : 08/02/1994
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism for
subsequent protocol interactions. The authentication and protection
mechanisms used by the POP3 AUTH command are those used by IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-myers-pop3-auth-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-pop3-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802150828.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-myers-pop3-auth-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-pop3-auth-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802150828.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09446;
3 Aug 94 13:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09434;
3 Aug 94 13:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11684;
3 Aug 94 13:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09421;
3 Aug 94 13:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09262;
3 Aug 94 13:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-myers-pop3-auth-01.txt
Date: Wed, 03 Aug 94 13:25:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031325.aa09262 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : POP3 AUTHentication command
Author(s) : J. G. Myers
Filename : draft-myers-pop3-auth-01.txt
Pages : 5
Date : 08/02/1994
This document describes the optional AUTH command, for indicating an
authentication mechanism to the server, performing an authentication
protocol exchange, and optionally negotiating a protection mechanism for
subsequent protocol interactions. The authentication and protection
mechanisms used by the POP3 AUTH command are those used by IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-myers-pop3-auth-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-myers-pop3-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802150828.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-myers-pop3-auth-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-myers-pop3-auth-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802150828.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09608;
3 Aug 94 13:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09600;
3 Aug 94 13:35 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa11870;
3 Aug 94 13:35 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <NAA06043 at pad-thai.aktis.com>; Wed, 3 Aug 1994 13:22:28 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA05421; Wed, 3 Aug 94 13:21:06 EDT
Received: from dun-dun-noodles.cam.ov.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <NAA06036 at pad-thai.aktis.com>; Wed, 3 Aug 1994 13:22:07 -0400
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA21564; Wed, 3 Aug 94 13:22:05 EDT
Message-Id: <9408031722.AA21564 at dun-dun-noodles.cam.ov.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Wed, 03 Aug 1994 13:45:53 -0000."
<9408031245.AA11995 at getafix.oasis.icl.co.uk>
Date: Wed, 03 Aug 1994 13:22:04 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> So it follows that there could not be any generic encapsulating
>> "wrapper", as in the GSS-API specification for on-line security
>> mechanisms.
>>
>> Hence a potential store-and-forward GSS-API would be a programmatic
>> construct only (i.e. the analogues of Appendices B and C of
>> RFC1508 couldn't apply).
That depends on how clever you are. For instance, you could stick a
mechanism-independent header in front of a PEM or PGP message, as long
as it consisted only of ascii characters and ended in CR LF CR LF.
Standalone readers would ignore it since it would be before the
pre-encapsulation boundary. We'd need to make sure that MIME-PEM
allowed this header, but that should be easy.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10424;
3 Aug 94 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10420;
3 Aug 94 14:19 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa13066;
3 Aug 94 14:19 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA18906 on Wed, 3 Aug 94 13:17:59 -0400
Received: from ietf.cnri.reston.va.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA18902 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Wed, 3 Aug 94 13:17:53 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08402;
3 Aug 94 13:11 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: uri at bunyip.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-resource-names-02.txt
Date: Wed, 03 Aug 94 13:11:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408031311.aa08402 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Names
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-uri-resource-names-02.txt
Pages : 4
Date : 08/02/1994
A Uniform Resource Name (URN) is an identifier which can be used to
uniquely identify a resource, and is designed to provide persistent naming
for networked objects. This name would stay the same no matter what the
current location(s) of the object was.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-resource-names-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-resource-names-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-resource-names-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-resource-names-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802110701.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11224;
3 Aug 94 15:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11216;
3 Aug 94 15:00 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14049;
3 Aug 94 15:00 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA07845 at pad-thai.aktis.com>; Wed, 3 Aug 1994 14:42:39 -0400
Received: from postman.osf.org by MIT.EDU with SMTP
id AC06512; Wed, 3 Aug 94 13:37:38 EDT
Received: from sulphur.osf.org (sulphur.osf.org [130.105.5.36]) by postman.osf.org (8.6.9/8.6.x) with SMTP
id NAA23789; Wed, 3 Aug 1994 13:32:34 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rich Salz <rsalz at osf.org>
Received: by sulphur.osf.org (1.37.109.4/4.7) id AA04846; Wed, 3 Aug 94 13:30:13 -0400
Date: Wed, 3 Aug 94 13:30:13 -0400
Message-Id: <9408031730.AA04846 at sulphur.osf.org>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: Re: Query re work on GSS-API extensions for store-and-fwd
support
Cc: gomberg at smiley.mitre.org, cat-ietf at mit.edu
> Is this relevant to the SC21/WG8 workitem referred to?
Sorry, I was confused. Never mind.
> When was the DCE Security Spec resubmitted to X/Open?
I don't think it was ever pulled, but it is in review. I could be wrong.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11246;
3 Aug 94 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11236;
3 Aug 94 15:02 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14076;
3 Aug 94 15:02 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA07875 at pad-thai.aktis.com>; Wed, 3 Aug 1994 14:45:50 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA10170; Wed, 3 Aug 94 14:44:28 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <19576-0 at relay1.pipex.net>; Wed, 3 Aug 1994 19:44:06 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA12130; Wed, 3 Aug 94 19:46:38 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA03226;
Wed, 3 Aug 94 19:43:56 BST
Message-Id: <9408031845.AA08527 at getafix.oasis.icl.co.uk>
Date: Wed, 3 Aug 94 19:45:22 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
To: cat-ietf at mit.edu
> That depends on how clever you are. For instance, you could stick a
> mechanism-independent header in front of a PEM or PGP message, as long
> as it consisted only of ascii characters and ended in CR LF CR LF.
> Standalone readers would ignore it since it would be before the
> pre-encapsulation boundary. We'd need to make sure that MIME-PEM
> allowed this header, but that should be easy.
Ok - but a "skippable" mechanism-independent header that is specific
to a given application's parsing rules would need to be different for
other (non-PEM) store-and-forward applications, and may indeed not be
supportable in all such applications.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11652;
3 Aug 94 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14552;
3 Aug 94 15:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11640;
3 Aug 94 15:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11566;
3 Aug 94 15:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-transponders-02.txt
Date: Wed, 03 Aug 94 15:15:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031515.aa11566 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : Resource Transponders
Author(s) : C. Weider
Filename : draft-ietf-iiir-transponders-02.txt
Pages : 4
Date : 08/02/1994
Although a number of systems have been created in the last several years to
provide resource location and navigation on the Internet, the information
contained in these systems must be maintained and updated by hand. This
paper describes an automatic mechanism, the resource transponder, for
maintaining resource location information.
Author's note:
This document is being circulated as sort of a research paper; consequently
there are no protocol specifications or anything of the sort. I hope that
we can go from here and actually design them if there's consensus that they
are potentially useful. Once we have some idea of the required
functionality, we can then go out and standardize them.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-transponders-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iiir-transponders-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802114923.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iiir-transponders-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-transponders-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802114923.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11652;
3 Aug 94 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14552;
3 Aug 94 15:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11640;
3 Aug 94 15:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11566;
3 Aug 94 15:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-transponders-02.txt
Date: Wed, 03 Aug 94 15:15:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031515.aa11566 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : Resource Transponders
Author(s) : C. Weider
Filename : draft-ietf-iiir-transponders-02.txt
Pages : 4
Date : 08/02/1994
Although a number of systems have been created in the last several years to
provide resource location and navigation on the Internet, the information
contained in these systems must be maintained and updated by hand. This
paper describes an automatic mechanism, the resource transponder, for
maintaining resource location information.
Author's note:
This document is being circulated as sort of a research paper; consequently
there are no protocol specifications or anything of the sort. I hope that
we can go from here and actually design them if there's consensus that they
are potentially useful. Once we have some idea of the required
functionality, we can then go out and standardize them.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-transponders-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iiir-transponders-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802114923.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iiir-transponders-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-transponders-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802114923.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11664;
3 Aug 94 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11652;
3 Aug 94 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14552;
3 Aug 94 15:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11640;
3 Aug 94 15:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11566;
3 Aug 94 15:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-transponders-02.txt
Date: Wed, 03 Aug 94 15:15:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408031515.aa11566 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : Resource Transponders
Author(s) : C. Weider
Filename : draft-ietf-iiir-transponders-02.txt
Pages : 4
Date : 08/02/1994
Although a number of systems have been created in the last several years to
provide resource location and navigation on the Internet, the information
contained in these systems must be maintained and updated by hand. This
paper describes an automatic mechanism, the resource transponder, for
maintaining resource location information.
Author's note:
This document is being circulated as sort of a research paper; consequently
there are no protocol specifications or anything of the sort. I hope that
we can go from here and actually design them if there's consensus that they
are potentially useful. Once we have some idea of the required
functionality, we can then go out and standardize them.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-transponders-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iiir-transponders-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802114923.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iiir-transponders-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-transponders-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802114923.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11830;
3 Aug 94 15:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11822;
3 Aug 94 15:24 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14820;
3 Aug 94 15:24 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA08438 at pad-thai.aktis.com>; Wed, 3 Aug 1994 15:05:25 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA11753; Wed, 3 Aug 94 15:04:12 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <20181-0 at relay1.pipex.net>; Wed, 3 Aug 1994 20:03:58 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA12295; Wed, 3 Aug 94 20:06:30 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA03398;
Wed, 3 Aug 94 20:03:47 BST
Message-Id: <9408031905.AA12179 at getafix.oasis.icl.co.uk>
Date: Wed, 3 Aug 94 20:05:13 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: support
To: cat-ietf at mit.edu
> > When was the DCE Security Spec resubmitted to X/Open?
>
> I don't think it was ever pulled, but it is in review. I could be wrong.
There was a request from HP and IBM to X/Open for a three month extension
to the review period of the DCE Security Spec. As this was inconsistent
with the notion of a "fast-track" of stable material, X/Open decided instead,
in early June of this year, to close the company review, and asked OSF to
resubmit when it had resolved the issues raised by HP and IBM with
the spec. I haven't seen a subsequent announcement which indicated that
the final fast-track review has started (or completed).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11911;
3 Aug 94 15:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11903;
3 Aug 94 15:26 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14992;
3 Aug 94 15:26 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA08459 at pad-thai.aktis.com>; Wed, 3 Aug 1994 15:07:04 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA11873; Wed, 3 Aug 94 15:05:46 EDT
Received: from dun-dun-noodles.cam.ov.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA08454 at pad-thai.aktis.com>; Wed, 3 Aug 1994 15:06:55 -0400
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA21685; Wed, 3 Aug 94 15:06:53 EDT
Message-Id: <9408031906.AA21685 at dun-dun-noodles.cam.ov.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Wed, 03 Aug 1994 19:45:22 -0000."
<9408031845.AA08527 at getafix.oasis.icl.co.uk>
Date: Wed, 03 Aug 1994 15:06:53 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> Ok - but a "skippable" mechanism-independent header that is specific
>> to a given application's parsing rules would need to be different for
>> other (non-PEM) store-and-forward applications, and may indeed not be
>> supportable in all such applications.
I just discussed this with John Linn, and it would be easily doable
with PEM and PGP as they exist today, and with minor modifications to
MIME-PEM, which is far from consensus anyway. I'm not familiar with
any other existing store-and-forward applications we would want to
provide under a generic API. Could you describe some others to me,
and their constraints? I don't think we'll be able to make it work in
every case, but I think for the more common ones, it will be possible.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12273;
3 Aug 94 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12264;
3 Aug 94 15:47 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa15396;
3 Aug 94 15:47 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA10003 at pad-thai.aktis.com>; Wed, 3 Aug 1994 15:22:27 -0400
Received: from ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA13120; Wed, 3 Aug 94 15:20:53 EDT
Received: (from postman at localhost) by andrew.cmu.edu (8.6.7/8.6.6) id PAA13500 for cat-ietf at mit.edu; Wed, 3 Aug 1994 15:20:40 -0400
Received: via switchmail; Wed, 3 Aug 1994 15:20:39 -0400 (EDT)
Received: from johnstown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.AiDyrAK00UoQE0On1u>;
Wed, 3 Aug 1994 15:19:48 -0400 (EDT)
Received: from johnstown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr16/db74/.Outgoing/QF.kiDyqhi00UoQMtZAVI>;
Wed, 3 Aug 1994 15:19:10 -0400 (EDT)
Received: from mms.4.60.Nov..4.1993.10.47.44.sun4c.411.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.johnstown.andrew.cmu.edu.sun4c.411
via MS.5.6.johnstown.andrew.cmu.edu.sun4c_411;
Wed, 3 Aug 1994 15:19:08 -0400 (EDT)
Message-Id: <wiDyqg600UoQ8tZAMp at andrew.cmu.edu>
Date: Wed, 3 Aug 1994 15:19:08 -0400 (EDT)
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>
To: cat-ietf at mit.edu
Subject: FTP questions
Hi,
I've been working locally on an enhanced FTP client and server. I used
client and (wuarchive based) server which were available from
thumper.bellcore.com as the base for my work, with the exception that I
pulled diffs between the original 2.1c server and the enhanced one, and
hand-applied them to the wuarchive 2.4 ftpd, so we'd have the newest
version, plus the Kerberos 4 modifications we wanted. At any rate, I'm
wondering this:
assume the AUTH/ADAT challenge-response is done. We send across a user
command and one of these things happens:
1) kerberos user we authenticated as is allowed to log in as user we specified
2) kerberos user we authenticated as is NOT allowed to log in as user we
specified, user needs to send a password
3) user we wish to log in as is not allowed to log in
The fourth case is the one giving me heartburn.
4) kerberos user may be allowed to log in as the user we specified but
we need either a password or an AFS token so we can check what PTS groups
the user is a member of.
I'd like to give the user the option to send current authentication
(probably their Kerberos TGT; I've already set up a means for the user
to do this, and since we're using an AFS kaserver, it can be done) or
their password. In either case, the data will be encrypted. The
importnat thing is, I need to (I'd like to) send a different reply code
back to the client in the case of "we need to get your authentication to
see if you can log in" than in the case of "Kerberos user foo not
authorized to log in as bar, send a password".
Is there any provision for having new codes allocated, should I use an
existing code, should I be drug out into the street and shot, or do I
have any other options?
Thanks
-Derrick
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12550;
3 Aug 94 16:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12542;
3 Aug 94 16:03 EDT
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa15742;
3 Aug 94 16:03 EDT
Received: by ucdavis.ucdavis.edu (8.6.9/UCD2.50)
id MAA24138; Wed, 3 Aug 1994 12:52:31 -0700
X-Orig-Sender: ietf-wnils-request at ucdavis.edu
Received: from IETF.nri.reston.VA.US by ucdavis.ucdavis.edu (8.6.9/UCD2.50)
id MAA24126; Wed, 3 Aug 1994 12:52:30 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08722;
3 Aug 94 13:17 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, CNRI.Reston.VA.US at ucdavis.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
cc: ietf-wnils at ucdavis.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-mesh-00.txt
Date: Wed, 03 Aug 94 13:17:04 -0400
Message-ID: <9408031317.aa08722 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : How to interact with a Whois++ mesh
Author(s) : P. Faltstrom, R. Schoultz, C. Weider
Filename : draft-ietf-wnils-whois-mesh-00.txt
Pages : 4
Date : 08/02/1994
In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done
by the client, since each server 'refers' the client to the next
appropriate server(s). The protocol is simple. The client opens a
connection to a server, sends a query, receives a reply, closes the
connection, and after parsing the response the client decides which server
to contact next, if necessary.
So, the client needs to have an algorithm to follow when it interacts with
the Whois++ mesh so that referral loops can be detected, cost is minimised,
and appropriate servers are rapidly and effectively contacted.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-mesh-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-mesh-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-mesh-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-mesh-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802143636.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13173;
3 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16484;
3 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13151;
3 Aug 94 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13064;
3 Aug 94 16:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16437;
3 Aug 94 16:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13059;
3 Aug 94 16:26 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: mwalnut at CNRI.Reston.VA.US
cc: meeting-planning at CNRI.Reston.VA.US
Subject: IETF: APRIL '95 Confirmed
Date: Wed, 03 Aug 94 16:26:37 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9408031626.aa13059 at IETF.CNRI.Reston.VA.US>
Spring 1995
Danvers, Massachusetts
Host(s): FTP Software, Inc./ Stev Knowles
NEARNET/ John Curran
April 3-7, 1995
Status: CONFIRMED
The IETF Secretariat is pleased to announce that the 32nd Internet
Engineering Task Force (IETF) meeting will be held at the Sheraton
Tara Hotel & Resort in Danvers, Massachusetts in April of 1995.
This information along with a listing of proposed meeting dates and sites,
is available via the remote directories (see retrieval instructions below).
In addition, information on future IETF meetings which are not yet confirmed
is also available.
FTP Access
==========
IETF Information is available by anonymous FTP from several sites.
East Coast (US) Address: ds.internic.net (198.49.45.10)
West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
To retrieve this information via FTP, establish an anonymous FTP
connection, then login with username ``anonymous''. Use your email
address as the password. When logged in, change to the directory of
your choice with one of the following commands:
cd ietf
Individual files can then be retrieved using the GET command:
get 0mtg-sites.txt
get 0mtg-at-a-glance-95apr.txt (still incomplete)
------
Future IETF Meeting Sites
Fall 1994
San Jose, California
Sun Microsystems, Inc.
Hosts: Bob Hinden and Geoff Mulligan
December 5-9, 1994
Status: CONFIRMED
Spring 1995
Danvers, Massachusetts
FTP Software, Inc.
NEARNET
Host(s): Stev Knowles
John Curran
April 3-7, 1995
Status: CONFIRMED
Summer 1995
Stockholm, Sweden
NORDUnet
Host: Bernhard Stockman
Possible Dates: July 17-21, 1995
July 31-August 4, 1995
Status: TENTATIVE
Fall 1995
Possible Dates: November 13-17, 1995
December 4-8, 1995
1
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13173;
3 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16484;
3 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13151;
3 Aug 94 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13064;
3 Aug 94 16:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16437;
3 Aug 94 16:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13059;
3 Aug 94 16:26 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: mwalnut at CNRI.Reston.VA.US
cc: meeting-planning at CNRI.Reston.VA.US
Subject: IETF: APRIL '95 Confirmed
Date: Wed, 03 Aug 94 16:26:37 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9408031626.aa13059 at IETF.CNRI.Reston.VA.US>
Spring 1995
Danvers, Massachusetts
Host(s): FTP Software, Inc./ Stev Knowles
NEARNET/ John Curran
April 3-7, 1995
Status: CONFIRMED
The IETF Secretariat is pleased to announce that the 32nd Internet
Engineering Task Force (IETF) meeting will be held at the Sheraton
Tara Hotel & Resort in Danvers, Massachusetts in April of 1995.
This information along with a listing of proposed meeting dates and sites,
is available via the remote directories (see retrieval instructions below).
In addition, information on future IETF meetings which are not yet confirmed
is also available.
FTP Access
==========
IETF Information is available by anonymous FTP from several sites.
East Coast (US) Address: ds.internic.net (198.49.45.10)
West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
To retrieve this information via FTP, establish an anonymous FTP
connection, then login with username ``anonymous''. Use your email
address as the password. When logged in, change to the directory of
your choice with one of the following commands:
cd ietf
Individual files can then be retrieved using the GET command:
get 0mtg-sites.txt
get 0mtg-at-a-glance-95apr.txt (still incomplete)
------
Future IETF Meeting Sites
Fall 1994
San Jose, California
Sun Microsystems, Inc.
Hosts: Bob Hinden and Geoff Mulligan
December 5-9, 1994
Status: CONFIRMED
Spring 1995
Danvers, Massachusetts
FTP Software, Inc.
NEARNET
Host(s): Stev Knowles
John Curran
April 3-7, 1995
Status: CONFIRMED
Summer 1995
Stockholm, Sweden
NORDUnet
Host: Bernhard Stockman
Possible Dates: July 17-21, 1995
July 31-August 4, 1995
Status: TENTATIVE
Fall 1995
Possible Dates: November 13-17, 1995
December 4-8, 1995
1
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13185;
3 Aug 94 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13173;
3 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16484;
3 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13151;
3 Aug 94 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13064;
3 Aug 94 16:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16437;
3 Aug 94 16:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13059;
3 Aug 94 16:26 EDT
To: IETF-Announce: ;
Reply-To: mwalnut at CNRI.Reston.VA.US
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: mwalnut at CNRI.Reston.VA.US
cc: meeting-planning at CNRI.Reston.VA.US
Subject: IETF: APRIL '95 Confirmed
Date: Wed, 03 Aug 94 16:26:37 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9408031626.aa13059 at IETF.CNRI.Reston.VA.US>
Spring 1995
Danvers, Massachusetts
Host(s): FTP Software, Inc./ Stev Knowles
NEARNET/ John Curran
April 3-7, 1995
Status: CONFIRMED
The IETF Secretariat is pleased to announce that the 32nd Internet
Engineering Task Force (IETF) meeting will be held at the Sheraton
Tara Hotel & Resort in Danvers, Massachusetts in April of 1995.
This information along with a listing of proposed meeting dates and sites,
is available via the remote directories (see retrieval instructions below).
In addition, information on future IETF meetings which are not yet confirmed
is also available.
FTP Access
==========
IETF Information is available by anonymous FTP from several sites.
East Coast (US) Address: ds.internic.net (198.49.45.10)
West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
To retrieve this information via FTP, establish an anonymous FTP
connection, then login with username ``anonymous''. Use your email
address as the password. When logged in, change to the directory of
your choice with one of the following commands:
cd ietf
Individual files can then be retrieved using the GET command:
get 0mtg-sites.txt
get 0mtg-at-a-glance-95apr.txt (still incomplete)
------
Future IETF Meeting Sites
Fall 1994
San Jose, California
Sun Microsystems, Inc.
Hosts: Bob Hinden and Geoff Mulligan
December 5-9, 1994
Status: CONFIRMED
Spring 1995
Danvers, Massachusetts
FTP Software, Inc.
NEARNET
Host(s): Stev Knowles
John Curran
April 3-7, 1995
Status: CONFIRMED
Summer 1995
Stockholm, Sweden
NORDUnet
Host: Bernhard Stockman
Possible Dates: July 17-21, 1995
July 31-August 4, 1995
Status: TENTATIVE
Fall 1995
Possible Dates: November 13-17, 1995
December 4-8, 1995
1
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13201;
3 Aug 94 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13195;
3 Aug 94 16:30 EDT
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa16522;
3 Aug 94 16:30 EDT
Received: by ucdavis.ucdavis.edu (8.6.9/UCD2.50)
id NAA28608; Wed, 3 Aug 1994 13:20:46 -0700
X-Orig-Sender: ietf-wnils-request at ucdavis.edu
Received: from IETF.nri.reston.VA.US by ucdavis.ucdavis.edu (8.6.9/UCD2.50)
id NAA28598; Wed, 3 Aug 1994 13:20:44 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08917;
3 Aug 94 13:18 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, CNRI.Reston.VA.US at ucdavis.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
cc: ietf-wnils at ucdavis.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-wnils-whois-arch-01.txt
Date: Wed, 03 Aug 94 13:18:21 -0400
Message-ID: <9408031318.aa08917 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Whois and Network Information
Lookup Service Working Group of the IETF.
Title : Architecture of the WHOIS++ service
Author(s) : P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider
Filename : draft-ietf-wnils-whois-arch-01.txt
Pages : 44
Date : 08/02/1994
This document describes WHOIS++, an extension to the trivial WHOIS service
described in RFC 954 to permit WHOIS-like servers to make available more
structured information to the Internet. We describe an extension to the
simple WHOIS data model and query protocol and a companion extensible,
distributed indexing service. A number of options have also been added
such as the use of multiple languages and character sets, more advanced
search expressions, structured data and a number of other useful features.
An optional authentication mechanism for protecting all or part of the
associated WHOIS++ information database from unauthorized access is also
described.
The additional architectural issues and commands added to support the
distributed indexing service are described in [Weider94]. This present
document should be read in conjunction with the additional reference.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-wnils-whois-arch-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-wnils-whois-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-wnils-whois-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-wnils-whois-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145103.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13633;
3 Aug 94 17:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13625;
3 Aug 94 17:03 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa17243;
3 Aug 94 17:03 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA12019 at pad-thai.aktis.com>; Wed, 3 Aug 1994 16:45:56 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA19185; Wed, 3 Aug 94 16:44:35 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <22796-0 at relay1.pipex.net>; Wed, 3 Aug 1994 21:44:29 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA13255; Wed, 3 Aug 94 21:46:55 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA04956;
Wed, 3 Aug 94 21:44:13 BST
Message-Id: <9408032045.AA26340 at getafix.oasis.icl.co.uk>
Date: Wed, 3 Aug 94 21:45:38 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
To: cat-ietf at mit.edu
> I just discussed this with John Linn, and it would be easily doable
> with PEM and PGP as they exist today, and with minor modifications to
> MIME-PEM, which is far from consensus anyway. I'm not familiar with
> any other existing store-and-forward applications we would want to
> provide under a generic API. Could you describe some others to me,
> and their constraints?
X.400 and EDI. Token formats are defined, and they aren't the same as
PEM/PGP. These applications don't obviously lend theselves to having a
CRLF-terminated wrapper used to prefix security tokens, and still
preserve interoperability.
On the other hand, while there are some, there are not a lot of
implementations of X.400-1988 to be non-interoperable with, and an
alternative asymmetric token format could be defined ...
> I don't think we'll be able to make it work in
> every case, but I think for the more common ones, it will be possible.
I suspect that EDI applications are likely to be the most common consumers
of store-and-forward security services eventually ...
It is likely to be more immediately productive to focus on achieving
an agreed store-and-forward interface for PEM and PGP - but without
overselling its absolute genericity.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14009;
3 Aug 94 17:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14005;
3 Aug 94 17:35 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa17847;
3 Aug 94 17:35 EDT
Received: by interlock.ans.net id AA14509
(InterLock SMTP Gateway 1.1 for iwg-out at ans.net);
Wed, 3 Aug 1994 17:10:41 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Wed, 3 Aug 1994 17:10:41 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Wed, 3 Aug 1994 17:10:41 -0400
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: bgp at ans.net
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-05.txt
Date: Wed, 03 Aug 94 13:23:52 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408031323.aa09209 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-05.txt
Pages : 21
Date : 08/02/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940802145716.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14853;
3 Aug 94 18:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14845;
3 Aug 94 18:40 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa19829;
3 Aug 94 18:40 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <SAA13903 at pad-thai.aktis.com>; Wed, 3 Aug 1994 18:22:11 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA25665; Wed, 3 Aug 94 18:20:54 EDT
Received: from krypton.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19)
id AA15000; Wed, 3 Aug 94 17:20:50 CDT
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA03502; Wed, 3 Aug 94 17:20:47 CDT
Date: Wed, 3 Aug 94 17:20:47 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9408032220.AA03502 at krypton.mcc.com>
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu
In-Reply-To: John Linn's message of Wed, 03 Aug 1994 11:26:21 -0400 <9408031526.AA09378 at winkl.aktis.com>
Subject: Draft minutes for Toronto CAT sessions
First, thanks for a thorough set of minutes. While this was my first
IETF CAT WG meeting, I've been involved in other standards activities
in the past, and can appreciate your efforts both in moderating the
meetings as well as preparing the minutes.
One comment wrt the minutes. You mentioned:
"Service-to-client one-way authentication (as desired, e.g., by Mosaic):"
I just wanted to point out that Mosaic doesn't inherently desire
one-way authentication. Rather, it's more a matter of how a
particular Web service is being used. Mutual authentication would in
fact be desirable in many cases so as to enable the enforcement of
access controls based on authenticated *user* identities.
Next, some general comments to the CAT list.
Wrt security mechanism negotiation, again I suggest Don (or whoever)
take a look at the S-HTTP draft specification to get a feel for what
they are trying to do. S-HTTP is a set of extensions to the existing
HTTP (WWW) application protocol, specifically for doing security
mechanism negotiation. They want to negotiate general mechanism type /
encapsulation format (e.g. PKCS, PEM, PGP, SPKM, Kerberos, etc.), as
well as algorithm type (e.g. RSA, MD5, DSA, SHA, DES, etc.). I think
having some form of mechanism negotiation in the GSS is a good idea,
but it will need to be fairly robust to satisfy various applications.
(Don: I'd be glad to assist on this one.)
Wrt context expiration, I "conceptually" agree with Jeff in the sense
of not having indefinite contexts for security purposes, but
"practically" agree with Rajaram in the sense that the more complex a
standard API is to use from an application programmer's standpoint,
the less likely it will be widely adopted. This concern stems from my
previous work in developing standard APIs, as well as observing other
standards efforts (e.g. OSI?). While having context expiration in the
GSS isn't necessarily *too* complex for applications to handle, I
mention it here as a general rule of thumb to keep in mind as the API
evolves. So, we at least need to document how an application might
handle the expiration of a context (re-establish it, etc.).
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15455;
3 Aug 94 19:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15447;
3 Aug 94 19:21 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa20626;
3 Aug 94 19:21 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA14640 at pad-thai.aktis.com>; Wed, 3 Aug 1994 19:07:16 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA27798; Wed, 3 Aug 94 19:05:59 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA18036; Wed, 3 Aug 94 19:05:54 EDT
Date: Wed, 3 Aug 94 19:05:54 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408032305.AA18036 at tsx-11.MIT.EDU>
To: John Linn <linn at cam.ov.com>
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, vipin.samar at eng.sun.com,
cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Wed, 03 Aug 1994 08:16:50 -0400,
<9408031216.AA09176 at winkl.aktis.com>
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 03 Aug 1994 08:16:50 -0400
From: John Linn <linn at cam.ov.com>
We appear to have consensus that S&F GSS-API extensions would be
a useful idea; now, we need to decide if and how to progress this
as a work item. Ted, Piers: would it be OK with you if I forwarded
this message to the pem-dev list, as a vehicle to involve interested
members of the PEM development community who may not previously have
been concerned with GSS-API?
Fine with me. Next, though, we have a harder problem --- we need to
find a volunteer willing to write up a proposal for what these GSS-API
extensions will need to look like. :-)
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15481;
3 Aug 94 19:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15473;
3 Aug 94 19:25 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa20683;
3 Aug 94 19:25 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA14795 at pad-thai.aktis.com>; Wed, 3 Aug 1994 19:13:11 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA28111; Wed, 3 Aug 94 19:11:55 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA18110; Wed, 3 Aug 94 19:11:52 EDT
Date: Wed, 3 Aug 94 19:11:52 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408032311.AA18110 at tsx-11.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, linn at cam.ov.com, cat-ietf at mit.edu
In-Reply-To: Marc Horowitz's message of Wed, 03 Aug 1994 13:22:04 -0400,
<9408031722.AA21564 at dun-dun-noodles.cam.ov.com>
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 03 Aug 1994 13:22:04 -0400
From: Marc Horowitz <marc at cam.ov.com>
That depends on how clever you are. For instance, you could stick a
mechanism-independent header in front of a PEM or PGP message, as long
as it consisted only of ascii characters and ended in CR LF CR LF.
Standalone readers would ignore it since it would be before the
pre-encapsulation boundary. We'd need to make sure that MIME-PEM
allowed this header, but that should be easy.
You're assuming here that the extension is restricted to ASCII-armored
messages, which is a bad assumption. Some mechanisms may be merely
emitting binary blobs of data....
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15830;
3 Aug 94 19:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15820;
3 Aug 94 19:32 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa20842;
3 Aug 94 19:33 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA14820 at pad-thai.aktis.com>; Wed, 3 Aug 1994 19:16:09 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA28227; Wed, 3 Aug 94 19:14:52 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA18141; Wed, 3 Aug 94 19:14:48 EDT
Date: Wed, 3 Aug 94 19:14:48 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408032314.AA18141 at tsx-11.MIT.EDU>
To: John Linn <linn at cam.ov.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Wed, 03 Aug 1994 11:26:21 -0400,
<9408031526.AA09378 at winkl.aktis.com>
Subject: Re: Draft minutes for Toronto CAT sessions
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
In the section of the minutes where the expiration time was discussed,
it might be helpful to add that the rationales for accepting Jeff's
proposal were that (a) programs like rlogin were not likely to be using
the GSSAPI interface anyway, for performance reasons (due to the
character i/o orientation of such programs) and (b) programs that really
didn't want the context to expire could always use GSS-seal to pass
their own encryption key, and then roll their own encryption. However,
it was agreed that in generally, we were under no obligation to make it
easy for such programs to evade the context expiration requirement.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15943;
3 Aug 94 19:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15935;
3 Aug 94 19:39 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa20944;
3 Aug 94 19:39 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA14974 at pad-thai.aktis.com>; Wed, 3 Aug 1994 19:26:58 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA28655; Wed, 3 Aug 94 19:25:45 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA18272; Wed, 3 Aug 94 19:25:41 EDT
Date: Wed, 3 Aug 94 19:25:41 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408032325.AA18272 at tsx-11.MIT.EDU>
To: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>
Cc: cat-ietf at mit.edu
In-Reply-To: Derrick J. Brashear's message of Wed, 3 Aug 1994 15:19:08 -0400 (EDT),
<wiDyqg600UoQ8tZAMp at andrew.cmu.edu>
Subject: Re: FTP questions
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 3 Aug 1994 15:19:08 -0400 (EDT)
From: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>
4) kerberos user may be allowed to log in as the user we specified but
we need either a password or an AFS token so we can check what PTS groups
the user is a member of.
I'd like to give the user the option to send current authentication
(probably their Kerberos TGT; I've already set up a means for the user
to do this, and since we're using an AFS kaserver, it can be done) or
their password. In either case, the data will be encrypted.
So let me get this straight... if I want to steal Kerberos TGT's, all I
have to do is set up a FTP server, and pursuade you to FTP to it, and if
I send it the correct reply code, it will happily send me a copy of your
TGT and the session key to go along with it --- which I am then free to
use to get an AFS token, or do anything else to impersonate as you....
Am I missing anything?
I'd strongly suggest that you only send over an AFS token (i.e., AFS
ticket), not the TGT, and that you only do this after prompting to the
user and making sure that that's what the user really wants to have
happen. I think it would be a bad UI design if the FTP client happily
forwarded your AFS tokens to whomever asks for them with a magic reply
code.
In fact, I'd probably suggest that user should have to type a command
(say, klog) which forwards the AFS tokens to the foreign ftp server.
This is a much simpler approach than having to do something with a magic
reply sequence. It's probably easier to implement, too!
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16223;
3 Aug 94 19:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16214;
3 Aug 94 19:58 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa21257;
3 Aug 94 19:58 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA15274 at pad-thai.aktis.com>; Wed, 3 Aug 1994 19:47:25 -0400
Received: from mgm.ctt.bellcore.com by MIT.EDU with SMTP
id AA29517; Wed, 3 Aug 94 19:46:07 EDT
Received: from diesel.ctt.bellcore.com by mgm.ctt.bellcore.com with SMTP id AA07133
(5.65c/IDA-1.4.4 for <cat-ietf at mit.edu>); Wed, 3 Aug 1994 19:45:31 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "P. Rajaram" <rajaram at ctt.bellcore.com>
Received: by diesel.ctt.bellcore.com (4.1/Spike-2.2)
id AA01758; Wed, 3 Aug 94 19:45:30 EDT
Date: Wed, 3 Aug 94 19:45:30 EDT
Message-Id: <9408032345.AA01758 at diesel.ctt.bellcore.com>
To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Draft minutes for Toronto CAT sessions
> Jeff Schiller (MIT) proposed that no
> context should last forever, and that for the Kerberos mechanism the
> expiration time should be no later than the expiration of the
> ticket(s) which are used to establish the context.
My argument is that context expration should not be forced by ticket
expiration; i.e. they should not be related. Context expiration is a
desirable feature that should be supported & enforced at the GSSAPI
level, but it should not be tied to (or be limited by) any one mechanism.
Ideally, I'd like to see an administrator configurable parameter that
defines the maximum context time for a site. The administrator then
gets to define a local policy. If a context spans two different
policy domains, then the max context time should be the minimum of
the two parameters. I know, it sounds messy. Configuration is icky.
The administrators can be trusted to do the 'right thing'. After all,
the administrator currently gets to define the max ticket lifetime for
Kerberos.
-raj
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16275;
3 Aug 94 20:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16267;
3 Aug 94 20:04 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa21321;
3 Aug 94 20:04 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA15277 at pad-thai.aktis.com>; Wed, 3 Aug 1994 19:48:52 -0400
Received: from Slapshot.Stanford.EDU by MIT.EDU with SMTP
id AA29580; Wed, 3 Aug 94 19:47:34 EDT
Received: (from schemers at localhost) by Slapshot.Stanford.EDU (8.6.9/8.6.6) id QAA24159; Wed, 3 Aug 1994 16:47:32 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Roland J. Schemers III" <schemers at slapshot.stanford.edu>
Message-Id: <9408031647.ZM24157 at Slapshot.Stanford.EDU>
Date: Wed, 3 Aug 1994 16:47:32 -0700
In-Reply-To: tytso at MIT.EDU (Theodore Ts'o)
"Re: FTP questions" (Aug 3, 7:25pm)
References: <9408032325.AA18272 at tsx-11.MIT.EDU>
X-Mailer: Z-Mail (3.0.0 15dec93)
To: Theodore Ts'o <tytso at mit.edu>,
"Derrick J. Brashear" <db74+ at andrew.cmu.edu>
Subject: Re: FTP questions
Cc: cat-ietf at mit.edu
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
On Aug 3, 7:25pm, Theodore Tso wrote:
> Subject: Re: FTP questions
>
> I'd strongly suggest that you only send over an AFS token (i.e., AFS
> ticket), not the TGT, and that you only do this after prompting to the
> user and making sure that that's what the user really wants to have
> happen. I think it would be a bad UI design if the FTP client happily
> forwarded your AFS tokens to whomever asks for them with a magic reply
> code.
>
> In fact, I'd probably suggest that user should have to type a command
> (say, klog) which forwards the AFS tokens to the foreign ftp server.
> This is a much simpler approach than having to do something with a magic
> reply sequence. It's probably easier to implement, too!
>
That is essentially the approach I took in my hack on the same code. The
user has to type "klog", and then is given the option of forwarding their
current tokens or typing in a username/password pair. Obiviously you
don't want to do the username/password pair (even if its encrypted) so
you would take the username/password, get a token locally, and then forward
the token. If you just hit return it sends the current tokens. For example:
Slapshot:sybase/table 104# ftp slapshot
Connected to Slapshot.Stanford.EDU.
220 Slapshot.Stanford.EDU FTP server (Version 5.60) ready.
334 Using authentication type KERBEROS_V4; ADAT must follow
KERBEROS_V4 accepted as authentication type
Kerberos V4 authentication succeeded
Name (slapshot:schemers):
S:231 Kerberos user schemers at IR.STANFORD.EDU is authorized as schemers
S:230 User schemers logged in.
S:Remote system type is UNIX.
Using binary mode to transfer files.
ftp> private
P:200 Protection level set to Private.
ftp> klog
Username (schemers):
P:331 Password/token required for schemers
Password (send current tokens):
sending token afs at ir.stanford.edu)
P:200 AFSTOKEN successful (afs. at ir.stanford.edu, AFS ID 4337. at ir.stanford.edu)
ftp>
This was all a simple hack (i.e, you should really type "private" first :-),
but it wouldn't be too hard to change my code to encrypt the token if your
not in private mode. I basically convert the token to network byte order
then radix encode it.
I think in this case you should:
1. Always ask the user (or have a .netrc option for certain hosts?). As
Ted mentioned, I don't want random servers sucking over tokens and/or
tgts :-)
2. Only send over the AFS token. That way you are delegating access only
to your files, nothing else (well, unless you have AFS admin privs)
You could also request a token with a shorter lifetime.
Roland
--
Roland J. Schemers III | Networking Systems
Authentication Services Programmer | 414 Sweet Hall +1 (415) 723-6740
Distributed Computing Operations | Stanford, CA 94305-3090
Stanford University | schemers at Slapshot.Stanford.EDU
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16793;
3 Aug 94 20:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16785;
3 Aug 94 20:54 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa22078;
3 Aug 94 20:54 EDT
Received: from hacksaw.rutgers.edu by pad-thai.aktis.com (8.6.8/) with ESMTP
id <UAA16116 at pad-thai.aktis.com>; Wed, 3 Aug 1994 20:39:25 -0400
Received: (from scooper at localhost) by hacksaw.rutgers.edu (8.6.8.1+bestmx/8.6.6) id UAA11203; Wed, 3 Aug 1994 20:35:07 -0400
Date: Wed, 3 Aug 1994 20:35:07 -0400
Message-Id: <199408040035.UAA11203 at hacksaw.rutgers.edu>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon Cooper <scooper at hardees.rutgers.edu>
To: cat-ietf at cam.ov.com
CC: bossert at hardees.rutgers.edu, drummond at hardees.rutgers.edu,
pleasant at hardees.rutgers.edu, dmk at hardees.rutgers.edu
In-reply-to: <9408032220.AA03502 at krypton.mcc.com> (rosenthl at mcc.com)
Subject: "service-to-client" one-way authentication.
X-Subject: Re: Draft minutes for Toronto CAT sessions
Doug Rosenthal writes:
>
>First, thanks for a thorough set of minutes. While this was my first
>IETF CAT WG meeting, I've been involved in other standards activities
>in the past, and can appreciate your efforts both in moderating the
>meetings as well as preparing the minutes.
>
I too apprecaite the minutes. I unfortunately could not attend the IETF
as I was attending the FIRST conference in Boston. [other Rutgers folks
were there, and perhaps this is how Mosiac was introduced].
>One comment wrt the minutes. You mentioned:
>"Service-to-client one-way authentication (as desired, e.g., by Mosaic):"
>I just wanted to point out that Mosaic doesn't inherently desire
>one-way authentication. Rather, it's more a matter of how a
>particular Web service is being used. Mutual authentication would in
>fact be desirable in many cases so as to enable the enforcement of
>access controls based on authenticated *user* identities.
>
I want to put forward that "service-to-client" one-way authentication
is a very important issue and should be explicitly mentioned in GSS-API
documents. If you are using the GSS-API to ensure that you are talking to
the right service (ie it can authenticate itself to you) then why should
you have to give up your identity? Privacy should not be forgotten. Do
you object to Radio Shack (and other stores) asking for you zip code or
telephone number? Giving of this info is voluntary, if you do give it
then your name/address and perhaps "profile" info is stored and then sold.
Now consider this scenario; as more commercial services come online they
choose to use the GSS-API (as it is the "standard") to ensure that their
service cannot be spoofed (ie users can authenticate the service). Such
providers will be overjoyed to learn that they will then be able to
identify every person connecting to their service -- wow, now as a
sideline they can then collect and sell profiles on the users that
connect...
There are several services that are designed to provide "public"
information, Mosaic is one and perhaps anonymous ftp (in its *real* sense)
is another. Determining if the service is authentic is important, but
that does not mean the client user has to be identified. There are cases
where mutual authentication is desirable in these protocols, but it should
not be "required" when the intent is to determine the authenticity of a
service.
Simon Cooper,
Systems Coordinator,
Rutgers University, Network Services.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25971;
4 Aug 94 0:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25961;
4 Aug 94 0:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25646;
4 Aug 94 0:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25946;
4 Aug 94 0:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25904;
4 Aug 94 0:52 EDT
Received: from gw.nw.com by CNRI.Reston.VA.US id aa25605; 4 Aug 94 0:52 EDT
Received: from localhost (mkl at localhost) by nw.com (8.6.5/8.6.5) id VAA23851 for ietf at cnri.reston.va.us; Wed, 3 Aug 1994 21:51:31 -0700
Date: Wed, 3 Aug 94 21:51:31 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Lottor <mkl at nw.com>
To: ietf at CNRI.Reston.VA.US
Subject: Internet Domain Survey results, July 1994
Message-ID: <CMM.0.90.4.775975891.mkl at nw.com>
Internet Domain Survey Network Wizards July 1994
The Domain Survey attempts to discover every host on the Internet by doing
a complete search of the Domain Name System. The latest results gathered
during late-July 1994 are listed. For more information see RFC 1296;
for more data see the zone directory on ftp.nw.com, or http://www.nw.com.
-- Mark Lottor
Number of Hosts, Domains, and Nets Advertised in the Domain Name System
July 94 Apr 94 Jan 94 Oct 93 Jul 93 Change (year)
==============================================================================
Hosts: 3,212,000 N/A 2,217,000 2,056,000 1,776,000 81%
Domains: 46,000 30,000 28,000 26,000 77%
PingReply: 707,000* 576,000# N/A 464,000# 52%
%ofHosts: 22% 26% 26%
[* = estimated by pinging a random sample of 1% of all hosts]
[# = estimated by pinging a random sample of 5% of all hosts]
Nets:
Class A: 89 N/A 74 69 67 33%
Class B: 4493 4043 3849 3728 21%
Class C: 20628 16422 12615 9972 107%
Total: 25210 20539 16533 13767 83%
Number of 2nd-Level Domains: 20,295
Number of 2nd-Level Domains under selected Top-Level Domains
12687 com 1388 org 1292 edu 545 net 202 gov
Host Distribution by Top-Level Domain Name
[see ftp.nw.com, zone/iso-country-codes to decode names]
856234 edu 23616 it 4518 pt 420 lu 53 lt
774735 com 21147 es 4014 sg 399 ve 52 eg
169248 gov 20130 at 3703 cl 339 ua 46 tn
155706 uk 16556 us 3308 ie 325 cn 42 pe
149193 de 15595 za 3268 is 322 ru 38 cy
130176 mil 14830 nz 3145 su 316 in 27 li
127516 ca 12109 kr 2958 gr 315 int 24 pa
127514 au 12107 dk 1869 cs 297 kw 23 ni
72409 jp 12107 be 1322 my 256 ec 12 mo
71899 fr 10314 tw 1204 tr 248 ar 7 dz
66459 org 9141 hk 1197 th 180 lv 5 fj
59729 nl 8464 il 868 sk 144 co 4 ir
53294 se 7392 pl 838 hr 101 uy 4 aq
49598 fi 5896 br 659 ee 79 bg 2 md
47401 ch 5639 cz 574 si 75 pr 1 sa
38759 no 5390 hu 544 cr 65 ph
30993 net 5164 mx 453 ro 54 id
Top 50 Host Names
1284 ns 840 mercury 681 charon 608 mail 571 thor
1178 venus 802 cisco 679 eagle 607 pc11 562 pc12
1099 pc1 796 iris 664 alpha 603 mac10 562 merlin
1078 pluto 784 pc3 661 neptune 602 pc5 554 mac4
1015 mars 765 ftp 644 newton 602 pc02 551 pc6
946 zeus 751 router 627 pc01 596 gateway 546 gauss
933 jupiter 751 orion 622 pc10 594 www 544 athena
919 pc2 751 gw 621 mac3 589 gopher 543 mac11
888 saturn 738 mac2 621 hermes 588 pc03 541 mac12
845 mac1 682 pc4 614 apollo 584 pc04 540 titan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03214;
4 Aug 94 9:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03206;
4 Aug 94 9:18 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa02976;
4 Aug 94 9:18 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA26371 at pad-thai.aktis.com>; Thu, 4 Aug 1994 08:37:07 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09737; Thu, 4 Aug 94 08:37:06 EDT
Message-Id: <9408041237.AA09737 at winkl.aktis.com>
To: Simon Cooper <scooper at hardees.rutgers.edu>
Cc: cat-ietf at cam.ov.com, bossert at hardees.rutgers.edu,
drummond at hardees.rutgers.edu, pleasant at hardees.rutgers.edu,
dmk at hardees.rutgers.edu, linn at cam.ov.com
Subject: Re: "service-to-client" one-way authentication.
In-Reply-To: Your message of "Wed, 03 Aug 1994 20:35:07 EDT."
<199408040035.UAA11203 at hacksaw.rutgers.edu>
Date: Thu, 04 Aug 1994 08:37:06 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Simon,
> I want to put forward that "service-to-client" one-way authentication
>is a very important issue and should be explicitly mentioned in GSS-API
>documents. If you are using the GSS-API to ensure that you are talking to
>the right service (ie it can authenticate itself to you) then why should
>you have to give up your identity? Privacy should not be forgotten.
It is a fact that GSS-API as it stands supports two classes of
authentication, one-way and mutual, selectable by the initiator
of a security context. In most cases (though this is not required
by GSS-API), a client is a context initiator and the server it accesses
is a context acceptor; this being the common case, we've sometimes
fallen into the inadvertent trap of using "client" as a synonym
for "initiator". One-way authentication from Mosaic service to
Mosaic accessor could be handled today at the GSS-API level
by having the Mosaic service initiate a security context to the
requesting Mosaic client, using one-way authentication. This works
fine at the level of GSS-API, which doesn't impose much asymmetry
between clients and servers, but won't necessarily work with
supporting mechanisms which implement clients' and servers' code
and manage their keys differently.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03334;
4 Aug 94 9:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03326;
4 Aug 94 9:24 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa03154;
4 Aug 94 9:24 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA26371 at pad-thai.aktis.com>; Thu, 4 Aug 1994 08:37:07 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09737; Thu, 4 Aug 94 08:37:06 EDT
Message-Id: <9408041237.AA09737 at winkl.aktis.com>
To: Simon Cooper <scooper at hardees.rutgers.edu>
Cc: cat-ietf at cam.ov.com, bossert at hardees.rutgers.edu,
drummond at hardees.rutgers.edu, pleasant at hardees.rutgers.edu,
dmk at hardees.rutgers.edu, linn at cam.ov.com
Subject: Re: "service-to-client" one-way authentication.
In-Reply-To: Your message of "Wed, 03 Aug 1994 20:35:07 EDT."
<199408040035.UAA11203 at hacksaw.rutgers.edu>
Date: Thu, 04 Aug 1994 08:37:06 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Simon,
> I want to put forward that "service-to-client" one-way authentication
>is a very important issue and should be explicitly mentioned in GSS-API
>documents. If you are using the GSS-API to ensure that you are talking to
>the right service (ie it can authenticate itself to you) then why should
>you have to give up your identity? Privacy should not be forgotten.
It is a fact that GSS-API as it stands supports two classes of
authentication, one-way and mutual, selectable by the initiator
of a security context. In most cases (though this is not required
by GSS-API), a client is a context initiator and the server it accesses
is a context acceptor; this being the common case, we've sometimes
fallen into the inadvertent trap of using "client" as a synonym
for "initiator". One-way authentication from Mosaic service to
Mosaic accessor could be handled today at the GSS-API level
by having the Mosaic service initiate a security context to the
requesting Mosaic client, using one-way authentication. This works
fine at the level of GSS-API, which doesn't impose much asymmetry
between clients and servers, but won't necessarily work with
supporting mechanisms which implement clients' and servers' code
and manage their keys differently.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03689;
4 Aug 94 9:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03681;
4 Aug 94 9:56 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa04560;
4 Aug 94 9:56 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA01049 at pad-thai.aktis.com>; Thu, 4 Aug 1994 09:39:09 -0400
Received: from PO6.ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA24057; Thu, 4 Aug 94 09:37:55 EDT
Received: (from postman at localhost) by po6.andrew.cmu.edu (8.6.7/8.6.6) id JAA04647 for cat-ietf at mit.edu; Thu, 4 Aug 1994 09:37:48 -0400
Received: via switchmail; Thu, 4 Aug 1994 09:37:45 -0400 (EDT)
Received: from johnstown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.UiECwZS00UoQA0OnFM>;
Thu, 4 Aug 1994 09:37:42 -0400 (EDT)
Received: from johnstown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr16/db74/.Outgoing/QF.AiECwX200UoQ4wj85I>;
Thu, 4 Aug 1994 09:37:39 -0400 (EDT)
Received: from mms.4.60.Nov..4.1993.10.47.44.sun4c.411.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.johnstown.andrew.cmu.edu.sun4c.411
via MS.5.6.johnstown.andrew.cmu.edu.sun4c_411;
Thu, 4 Aug 1994 09:37:38 -0400 (EDT)
Message-Id: <UiECwWu00UoQ0wj7xj at andrew.cmu.edu>
Date: Thu, 4 Aug 1994 09:37:38 -0400 (EDT)
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>
To: cat-ietf at mit.edu
Subject: Re: FTP questions
In-Reply-To: <9408031647.ZM24157 at Slapshot.Stanford.EDU>
Excerpts from mail: 3-Aug-94 Re: FTP questions by Roland J. S. III at Slapsho
> I think in this case you should:
>
> 1. Always ask the user (or have a .netrc option for certain hosts?). As
> Ted mentioned, I don't want random servers sucking over tokens and/or
> tgts :-)
>
I agree. This was planned, but I neglected to mention it:-) In general,
anything which could be considered sensative that we send over, the user
is first asked.
> 2. Only send over the AFS token. That way you are delegating access only
> to your files, nothing else (well, unless you have AFS admin privs)
>
> You could also request a token with a shorter lifetime.
The only problem I have with this is that it makes more difficult (but
certainly not impossible) the possibility of porting just the client to
an OS with Kerberos, but not AFS.
-D
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03848;
4 Aug 94 10:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03840;
4 Aug 94 10:00 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa04689;
4 Aug 94 10:00 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA01081 at pad-thai.aktis.com>; Thu, 4 Aug 1994 09:42:13 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA24253; Thu, 4 Aug 94 09:40:55 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA01075 at pad-thai.aktis.com>; Thu, 4 Aug 1994 09:42:06 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09778; Thu, 4 Aug 94 09:42:05 EDT
Message-Id: <9408041342.AA09778 at winkl.aktis.com>
To: Theodore Ts'o <tytso at mit.edu>
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Draft minutes for Toronto CAT sessions
In-Reply-To: Your message of "Wed, 03 Aug 1994 19:14:48 EDT."
<9408032314.AA18141 at tsx-11.MIT.EDU>
Date: Thu, 04 Aug 1994 09:42:04 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
>In the section of the minutes where the expiration time was discussed,
>it might be helpful to add that the rationales for accepting Jeff's
>proposal were that (a) programs like rlogin were not likely to be using
>the GSSAPI interface anyway, for performance reasons (due to the
>character i/o orientation of such programs)
Thanks for the reminder; I'll add this to the minutes, since it
did come up in the discussion. I believe, though, that the
notion of "programs like rlogin" is a fuzzily defined class,
munging two separate ideas: (1) programs using per-character
I/O and (2) session-oriented programs where the sessions are
long-lived. As a good example of something that's (2) but not (1),
I've heard of cases where a regular nightly FTP transfer runs
for many hours, to transfer a large amount of data across a
not-so-wide pipe.
>and (b) programs that really
>didn't want the context to expire could always use GSS-seal to pass
>their own encryption key, and then roll their own encryption.
Certainly true; I'm not sure that such an application would bother
making use of GSS-API at all rather than rolling all of its own
cryptography, and would rather be in the mode of providing the
services that applications need than by disqualifying them at the door;
I have to believe that it's easier for an application to renew
a context periodically than to build its own mechanism from the
ground up.
>However,
>it was agreed that in generally, we were under no obligation to make it
>easy for such programs to evade the context expiration requirement.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04033;
4 Aug 94 10:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04025;
4 Aug 94 10:14 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05065;
4 Aug 94 10:14 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA01426 at pad-thai.aktis.com>; Thu, 4 Aug 1994 09:57:38 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA25366; Thu, 4 Aug 94 09:56:21 EDT
Received: from krypton.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19)
id AA21157; Thu, 4 Aug 94 08:56:11 CDT
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA04176; Thu, 4 Aug 94 08:56:11 CDT
Date: Thu, 4 Aug 94 08:56:11 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9408041356.AA04176 at krypton.mcc.com>
To: rajaram at ctt.bellcore.com
Cc: cat-ietf at mit.edu, linn at cam.ov.com
In-Reply-To: "P. Rajaram"'s message of Wed, 3 Aug 94 19:45:30 EDT <9408032345.AA01758 at diesel.ctt.bellcore.com>
Subject: Draft minutes for Toronto CAT sessions
From: "P. Rajaram" <rajaram at ctt.bellcore.com>
Date: Wed, 3 Aug 94 19:45:30 EDT
To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Draft minutes for Toronto CAT sessions
My argument is that context expration should not be forced by ticket
expiration; i.e. they should not be related. Context expiration is a
desirable feature that should be supported & enforced at the GSSAPI
level, but it should not be tied to (or be limited by) any one mechanism.
Ideally, I'd like to see an administrator configurable parameter that
defines the maximum context time for a site. The administrator then
gets to define a local policy. If a context spans two different
policy domains, then the max context time should be the minimum of
the two parameters. I know, it sounds messy. Configuration is icky.
The administrators can be trusted to do the 'right thing'. After all,
the administrator currently gets to define the max ticket lifetime for
Kerberos.
Hmmm ... I may be missing something here. It seems that the
"characteristics" of context expiration are inherently tied to a given
mechanism. E.g., with Kerberos, it's inherently tied to ticket
lifetime since the tickets are the basis for the security context. As
you say, policy is enforced by the administrator setting the max
ticket lifetime. Thus, the administrator indirectly configures the
max context time.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04199;
4 Aug 94 10:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04191;
4 Aug 94 10:25 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05257;
4 Aug 94 10:25 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA01765 at pad-thai.aktis.com>; Thu, 4 Aug 1994 10:07:01 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA26071; Thu, 4 Aug 94 10:05:35 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA01752 at pad-thai.aktis.com>; Thu, 4 Aug 1994 10:06:41 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09817; Thu, 4 Aug 94 10:06:40 EDT
Message-Id: <9408041406.AA09817 at winkl.aktis.com>
To: cat-ietf at mit.edu, pem-dev at tis.com
Cc: linn at cam.ov.com, gomberg at gateway.mitre.org
Subject: GSS-API extensions for store-and-forward support
Date: Thu, 04 Aug 1994 10:06:39 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT list members have already seen the attached, excerpted from an ongoing
discussion we've been having in response to a informal liaison request
from Dave Gomberg on behalf of ISO/IEC JTC 1/SC21 WG8, who are looking
to incorporate or define store-and-forward messaging API primitives
for use in conjunction with GSS-API. Several people have commented
with interest and belief that such a definition would be a Good and
Reasonable Thing. I'm sending this to pem-dev as well in the interest
of informing potentially-interested participants who haven't previously
been involved with GSS-API, and of surveying the likely pool of
volunteers who might be interested in drafting a spec.
I'd envision the appropriate spec as being a standalone document
referencing GSS-API, probably accepting GSS-API credentials (rather
than security contexts) as input to the protect/unprotect
primitives for store-and forward messaging. For mechanisms capable
of supporting both on-line, association-oriented and store-and-forward
services, this would facilitate access to both with a single login.
Comments? Interest?
--jl
------- Forwarded Message
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA17602 at pad-thai.aktis.com>; Wed, 3 Aug 1994 08:16:54 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09176; Wed, 3 Aug 94 08:16:51 EDT
Message-Id: <9408031216.AA09176 at winkl.aktis.com>
To: tytso at MIT.EDU (Theodore Ts'o)
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, vipin.samar at eng.sun.com,
cat-ietf at MIT.EDU, linn at cam.ov.com
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Tue, 02 Aug 1994 22:52:31 EDT."
<9408030252.AA03428 at tsx-11.MIT.EDU>
Date: Wed, 03 Aug 1994 08:16:50 -0400
From: John Linn <linn at cam.ov.com>
Piers and Ted write:
> From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
> Date: Tue, 2 Aug 94 23:10:08 BST
> Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
>
> I too think that such an interface would be a good thing. But, being
> devil's advocate, what Internet applications would be potential
> consumers of such APIs? While EDI and email are two obvious candidates,
> doesn't the existence of existing specifications and/or implementations of
> store-and-forward security embedded within such applications (PEM, PGP,
> X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a
> new generic, and possibly non-interoperable, paradigm for implementing
> the same services?
>
>Well, a generic API that defined how to take a blob of data and creating
>a PEM or PGP encrypted (and possibly ASCII armored) message would be
>quite useful. I don't think this would necessarily be a new,
>non-interoperable paradigm, since there generally isn't a commonly used
>API in use now for these services that's callable from other programs.
>(Right now, there's just a command-line interface for PEM and PGP.)
>
>I'm assuming here that the packet formats of PEM, PGP, etc. would not
>change under this new API.
Clearly, introducing non-interoperability is a non-useful thing.
This implies to me that messaging support primitives would
want to accept input selector parameters to prescribe which of
a set of already-defined encapsulation formats (e.g., PEM, PGP,
PEM-MIME, ...) they're to output or process as input. Each of
these formats would correspond (loosely) to a GSS-API mechanism,
and this seems to me like a useful means to construct
messaging toolkits allowing applications to use multiple protection
formats.
We appear to have consensus that S&F GSS-API extensions would be
a useful idea; now, we need to decide if and how to progress this
as a work item. Ted, Piers: would it be OK with you if I forwarded
this message to the pem-dev list, as a vehicle to involve interested
members of the PEM development community who may not previously have
been concerned with GSS-API?
- --jl
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04713;
4 Aug 94 10:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04709;
4 Aug 94 10:49 EDT
Received: from relay.tis.com by CNRI.Reston.VA.US id aa05892; 4 Aug 94 10:49 EDT
Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3)
id sma010430; Thu Aug 4 10:34:45 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa06874;
4 Aug 94 10:33 EDT
Received: from sol.tis.com by magellan.TIS.COM id aa06870; 4 Aug 94 10:29 EDT
Received: from pad-thai.aktis.com(192.231.148.11) by relay via smap (V1.3)
id sma009956; Thu Aug 4 10:05:47 1994
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA01752 at pad-thai.aktis.com>; Thu, 4 Aug 1994 10:06:41 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09817; Thu, 4 Aug 94 10:06:40 EDT
Message-Id: <9408041406.AA09817 at winkl.aktis.com>
To: cat-ietf at mit.edu, pem-dev at tis.com
Cc: linn at cam.ov.com, gomberg at gateway.mitre.org
Subject: GSS-API extensions for store-and-forward support
Date: Thu, 04 Aug 1994 10:06:39 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT list members have already seen the attached, excerpted from an ongoing
discussion we've been having in response to a informal liaison request
from Dave Gomberg on behalf of ISO/IEC JTC 1/SC21 WG8, who are looking
to incorporate or define store-and-forward messaging API primitives
for use in conjunction with GSS-API. Several people have commented
with interest and belief that such a definition would be a Good and
Reasonable Thing. I'm sending this to pem-dev as well in the interest
of informing potentially-interested participants who haven't previously
been involved with GSS-API, and of surveying the likely pool of
volunteers who might be interested in drafting a spec.
I'd envision the appropriate spec as being a standalone document
referencing GSS-API, probably accepting GSS-API credentials (rather
than security contexts) as input to the protect/unprotect
primitives for store-and forward messaging. For mechanisms capable
of supporting both on-line, association-oriented and store-and-forward
services, this would facilitate access to both with a single login.
Comments? Interest?
--jl
------- Forwarded Message
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA17602 at pad-thai.aktis.com>; Wed, 3 Aug 1994 08:16:54 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09176; Wed, 3 Aug 94 08:16:51 EDT
Message-Id: <9408031216.AA09176 at winkl.aktis.com>
To: tytso at MIT.EDU (Theodore Ts'o)
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, vipin.samar at eng.sun.com,
cat-ietf at MIT.EDU, linn at cam.ov.com
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Tue, 02 Aug 1994 22:52:31 EDT."
<9408030252.AA03428 at tsx-11.MIT.EDU>
Date: Wed, 03 Aug 1994 08:16:50 -0400
From: John Linn <linn at cam.ov.com>
Piers and Ted write:
> From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
> Date: Tue, 2 Aug 94 23:10:08 BST
> Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
>
> I too think that such an interface would be a good thing. But, being
> devil's advocate, what Internet applications would be potential
> consumers of such APIs? While EDI and email are two obvious candidates,
> doesn't the existence of existing specifications and/or implementations of
> store-and-forward security embedded within such applications (PEM, PGP,
> X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a
> new generic, and possibly non-interoperable, paradigm for implementing
> the same services?
>
>Well, a generic API that defined how to take a blob of data and creating
>a PEM or PGP encrypted (and possibly ASCII armored) message would be
>quite useful. I don't think this would necessarily be a new,
>non-interoperable paradigm, since there generally isn't a commonly used
>API in use now for these services that's callable from other programs.
>(Right now, there's just a command-line interface for PEM and PGP.)
>
>I'm assuming here that the packet formats of PEM, PGP, etc. would not
>change under this new API.
Clearly, introducing non-interoperability is a non-useful thing.
This implies to me that messaging support primitives would
want to accept input selector parameters to prescribe which of
a set of already-defined encapsulation formats (e.g., PEM, PGP,
PEM-MIME, ...) they're to output or process as input. Each of
these formats would correspond (loosely) to a GSS-API mechanism,
and this seems to me like a useful means to construct
messaging toolkits allowing applications to use multiple protection
formats.
We appear to have consensus that S&F GSS-API extensions would be
a useful idea; now, we need to decide if and how to progress this
as a work item. Ted, Piers: would it be OK with you if I forwarded
this message to the pem-dev list, as a vehicle to involve interested
members of the PEM development community who may not previously have
been concerned with GSS-API?
- --jl
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06681;
4 Aug 94 12:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06673;
4 Aug 94 12:51 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa08988;
4 Aug 94 12:51 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA04922 at pad-thai.aktis.com>; Thu, 4 Aug 1994 12:34:07 -0400
Received: from Slapshot.Stanford.EDU by MIT.EDU with SMTP
id AA07422; Thu, 4 Aug 94 12:32:51 EDT
Received: (from schemers at localhost) by Slapshot.Stanford.EDU (8.6.9/8.6.6) id JAA26927; Thu, 4 Aug 1994 09:32:44 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Roland J. Schemers III" <schemers at slapshot.stanford.edu>
Message-Id: <9408040932.ZM26925 at Slapshot.Stanford.EDU>
Date: Thu, 4 Aug 1994 09:32:44 -0700
In-Reply-To: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>
"Re: FTP questions" (Aug 4, 9:37am)
References: <UiECwWu00UoQ0wj7xj at andrew.cmu.edu>
X-Mailer: Z-Mail (3.0.0 15dec93)
To: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>, cat-ietf at mit.edu
Subject: Re: FTP questions
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
On Aug 4, 9:37am, Derrick J. Brashear wrote:
> Subject: Re: FTP questions
>>
> > 2. Only send over the AFS token. That way you are delegating access only
> > to your files, nothing else (well, unless you have AFS admin privs)
> >
> > You could also request a token with a shorter lifetime.
> The only problem I have with this is that it makes more difficult (but
> certainly not impossible) the possibility of porting just the client to
> an OS with Kerberos, but not AFS.
>
Isn't a token basically a kerberos ticket in a different format? Seems like
you should be able to build an AFS token with only the Kerberos software.
At least a token for your current realm/cell.
Roland
--
Roland J. Schemers III | Networking Systems
Authentication Services Programmer | 414 Sweet Hall +1 (415) 723-6740
Distributed Computing Operations | Stanford, CA 94305-3090
Stanford University | schemers at Slapshot.Stanford.EDU
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07412;
4 Aug 94 13:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07402;
4 Aug 94 13:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09769;
4 Aug 94 13:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07350;
4 Aug 94 13:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07057;
4 Aug 94 13:18 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa09511; 4 Aug 94 13:18 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA15364 for ietf at cnri.reston.va.us; Thu, 4 Aug 94 13:17:52 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id KAA03791; Thu, 4 Aug 1994 10:17:08 -0700
Message-Id: <199408041717.KAA03791 at aland.bbn.com>
To: Joachim Martillo <martillo at pluto.dss.com>
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of Tue, 02 Aug 94 19:39:42 -0400.
<9408022339.AA20981 at pluto.dss.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 04 Aug 94 10:17:06 -0700
X-Orig-Sender: craig at aland.bbn.com
Hi:
Let me see if I can reply to some of your concerns about the IPng
criteria document. (I'll skip spots where you agreed with it and some spots
where I wasn't sure of what the key point was).
First off, the concern on 10**15 end-hosts. We're quite clear
about why we said that. We derived it straight from other work which we
felt wasn't quite demanding enough in terms of the number of devices in the
home. The fact that it comes out to 250,000 addresses per human only reflects
some of the Internet's difficulties with efficient address allocation.
Second, about performance. I'm not quite sure what your concern is but
it appears to be that we weren't firm enough about router performance. To
which, sigh, I plead that we can't please everyone. Originally the performance
section was pretty explicit that we believe that with a properly designed
IPng, certain explicit levels of router performance could be achieved.
But folks pointed out that having an experimental router that could achieve
a certain speed would meet the requirement but not achieve our goal and that
a better approach was, given that we know higher speed media (OC-48c for
instance) is coming, we simply say that commercial routers ought to be able
to achieve those speeds with IPng.
> This comment suggests that the new address structure should enable the
> quickest possible route look-up. The quickest possible route look-up
> means that a network number should conveniently correspond to a
> natural register size on common communications computers and that
> accesses to slower processor external memory should be minimized.
> Such needs and 16 byte addresses are hard to reconcile with current
> router technology.
Um, no, I'm afraid I don't agree with this analysis. I think a better
answer is to say that the header size should be a small number of cache
lines in size (the unit of access is no longer a register size). With
128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two
cache lines. Furthermore, most RISC systems have so many registers that
putting the entire header into registers isn't hard -- and the address
lookup in 90% of the cases is just a hash followed by a couple of compares.
> >over the Internet. It is not unreasonable, therefore, to
> >expect that the ratio of "local" traffic (i.e. the
> >traffic that stays on one's local network) to "export"
> >traffic (i.e. traffic destined to or sourced from a
> >network other than one's own local network) will change,
> >and the percent of export traffic will increase.
>
> This observation is not obviously true.
No, but one has to guess. Our conclusion was that if one assumed most
traffic was local, the requirements on the next generation IP were less
stringent. (In particular, there's less router traffic). So we chose the
more stringent approach.
> >We also observe that many researchers believe that a
> >proper IPng router should be capable of routing IPng
> >traffic over links at speeds that are capable of fully
> >utilizing an ATM switch on the link.
>
> ATM is yet another fad technology whose fad may be approaching its
> end. I have recently read that several companies which had started
> ATM development efforts had abandoned these efforts as pointless. A
> better targer might be wire-speed routing in the context of a LAN
> switch using fast Ethernet or CDDI.
Fast Ethernet and CDDI are too slow. We wanted to talk about 10 Gb/s speeds
and beyond. So far, ATM is the only protocol spec'd for those speeds.
> BTW, after groveling through numerous packet switching implementations
> and network drivers, almost invariably I have found that bottlenecks
> and low performance have been due not to protocol design but poor
> software implementations or (often even more importantly) due to the
> host OS architecture. The protocol design has generally been an
> extremely minor component of network/packet-switching performance.
Yep. But there are folks working on making very very fast implementations
and they are getting burned by protocol design issues.
Regarding designing for the future. I think you may be right that we're
ahistorical (shocking! -- I'm a former medievalist), but I still think that
designing for the high end of today's technology is the right approach.
The future is only 18 months away (next rev of CPUs).
> >Some predictions have been made that, as the Internet
> >grows and as more and more technically less-sophisticated
> >sites get connected, there will be more failures in the
> >network. These failures may be a combination of simple
> >size; if the size of the network goes up by a factor of n
> >then the total number of failures in the network can be
> >expected to increase by some function of n. Also, as the
> >network's users become less sophisticated, it can be
> >assumed that they will make more, innocent and well
> >meaning, mistakes, either in configuration or use of
> >their systems.
>
> This comment is just the typical obnoxious snobbishness of
> communications software engineers. If anything, the level of
> sophistication will probably increase with an increase in the number
> of sites which connect to the internet. Nowadays, someone who knows a
> little is a guru and technical wizard who feels obligated to produce
> reams of IETF draft documents. When lots of people have set up and
> run multiprotocol internetworks, a little knowledge will hardly
> impress anybody.
Actually, we're not trying to be snobbish. There has been a general shortage
of expertise in networking. And we have to expect our sites to be less
knowledgable in the future. So either the network breaks, or we make our
system more robust.
> >5.5. Transition
>
> >The transition plan should address the issue of cost
> >distribution. That is, it should identify what tasks are
> >required of the service providers, of the end users, of
> >the backbones and so on.
>
> This comment is rather scary. The IETF collectively has no obvious
> expertise in public finance, accounting or political economics.
>
> The one area where the IETF has tried to distribute costs is network
> management, and in this case the IETF has managed to make small
> installations subsidize the development of SNMP on behalf of a few
> large network providers even though the small installations have no
> real need of such a thing.
I dunno. We've got a lot of folks who've led successful startups etc.
Or putting this another way, if the idea is that folks who are in the IETF
cannot at least try to address issues of finance, accounting or economics,
why should we believe they are qualified to run businesses?
At some level, one just has to look at some of these problems -- so we will.
> >5.8. Configuration, Administration, and Operation
>
> >Also, a strength of IPv4 has been its ability to be used
> >on isolated subnets. IPng hosts must be able to work on
> >networks without routers present.
>
> Who designs a networking suite which requires routers on a single
> communications subet?
OSI used to and may still.
> >5.12. Multicast
> >Unfortunately, IPv4 currently uses the local media
> >broadcast address to multicast to all IP hosts. This
> >behavior is anti-social in mixed-protocol networks and
> >should be fixed in IPng. There's no good reason for IPng
> >to send to all hosts on a subnet when it only wishes to
> >send to all IPng hosts. The protocol must make
> >allowances for media that do not support true
> >multicasting.
>
> The above comment is idiotic. Exactly how a network layer multicast
> is resolved to a MAC layer address for some arbitrary medium is not
> obviously part of the network layer design.
Sure it is.
> >5.18. Things We Chose Not to Require
>
> I am not sure how MTU discovery overcomes the need for fragmentation
> unless MTU discovery is performed before each packet is sent and
> strict source routing is employed.
Read the MTU discovery spec. You don't need strict source routing or discovery
before each packet.
> >IP Header Checksum
> >There has been discussion indicating that the IP Checksum
> >does not provide enough error protection to warrant its
> >performance impact. The argument states that there is
> >almost always a stronger datalink level CRC, and that
> >end-to-end protection is provided by the TCP checksum.
> >Therefore we believe that an IPng checksum is not
> >required per-se.
>
> The IP header checksum is not intended to provide end-to-end data
> integrity but rather provides local address integrity. Few routers
> provide EDAC. Stuck bits in the wrong place after receive datalink
> CRC is calculated could easily cause some poor neighboring router to
> be inundated with misdirected packets whose lack of data integrity
> might not be detected until much later or even never (if the new
> address corresponds to no actual address). This problem could be
> particularly serious in the cases of applications which rarely or
> infrequently require acknowledgement of transmitted data packets.
Read the paragraph again. It says that local address integrity is sufficiently
protected by the link CRC and that end-to-end integrity of the IP datagram
is ensured by the end-to-end TCP checksums. Simple engineering.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07946;
4 Aug 94 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07935;
4 Aug 94 13:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10187;
4 Aug 94 13:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07924;
4 Aug 94 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07878;
4 Aug 94 13:50 EDT
Received: from feta.cisco.com by CNRI.Reston.VA.US id aa10158;
4 Aug 94 13:50 EDT
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA04358; Thu, 4 Aug 1994 10:51:13 -0700
Date: Thu, 4 Aug 1994 10:51:13 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408041751.KAA04358 at feta.cisco.com>
To: craig at aland.bbn.com
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
In-Reply-To: Craig Partridge's message of Thu, 04 Aug 94 10:17:06 -0700 <199408041717.KAA03791 at aland.bbn.com>
Subject: IPng recommendation
I know it's off the subject (and water under the bridge), but this
statement is not true and has never been. C'mon, Craig, you should
know better.
> Who designs a networking suite which requires routers on a single
> communications subet?
OSI used to and may still.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08052;
4 Aug 94 13:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08042;
4 Aug 94 13:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10306;
4 Aug 94 13:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08030;
4 Aug 94 13:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08000;
4 Aug 94 13:56 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa10288; 4 Aug 94 13:56 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA23623 for ietf at CNRI.Reston.VA.US; Thu, 4 Aug 94 13:56:47 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id KAA03894; Thu, 4 Aug 1994 10:56:14 -0700
Message-Id: <199408041756.KAA03894 at aland.bbn.com>
To: Dave Katz <dkatz at cisco.com>
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of Thu, 04 Aug 94 10:51:13 -0700.
<199408041751.KAA04358 at feta.cisco.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 04 Aug 94 10:56:12 -0700
X-Orig-Sender: craig at aland.bbn.com
Dave:
You mean I've been burned by bad info again?
My understanding was that if one wanted to do certain types of dynamic
address assignment under OSI one had to have a router present because dynamic
assignment required ES-IS and ES-IS required a router to be present. Is this
incorrect?
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08360;
4 Aug 94 14:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08355;
4 Aug 94 14:08 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa10544;
4 Aug 94 14:08 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id DAA10689; Fri, 5 Aug 1994 03:58:48 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id DAA10664; Fri, 5 Aug 1994 03:51:18 +1000
Precedence: list
Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA15347; Fri, 5 Aug 1994 03:51:15 +1000 (from dkatz at cisco.com)
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA04358; Thu, 4 Aug 1994 10:51:13 -0700
Date: Thu, 4 Aug 1994 10:51:13 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408041751.KAA04358 at feta.cisco.com>
To: craig at aland.bbn.com
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
In-Reply-To: Craig Partridge's message of Thu, 04 Aug 94 10:17:06 -0700 <199408041717.KAA03791 at aland.bbn.com>
Subject: IPng recommendation
I know it's off the subject (and water under the bridge), but this
statement is not true and has never been. C'mon, Craig, you should
know better.
> Who designs a networking suite which requires routers on a single
> communications subet?
OSI used to and may still.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08579;
4 Aug 94 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08569;
4 Aug 94 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10706;
4 Aug 94 14:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08556;
4 Aug 94 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08490;
4 Aug 94 14:12 EDT
Received: from feta.cisco.com by CNRI.Reston.VA.US id aa10665;
4 Aug 94 14:12 EDT
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA05791; Thu, 4 Aug 1994 11:12:43 -0700
Date: Thu, 4 Aug 1994 11:12:43 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408041812.LAA05791 at feta.cisco.com>
To: craig at aland.bbn.com
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
In-Reply-To: Craig Partridge's message of Thu, 04 Aug 94 10:56:12 -0700 <199408041756.KAA03894 at aland.bbn.com>
Subject: IPng recommendation
Sorry, I thought you were caught by the "can't forward to another box
on the wire without a router" red herring.
Address autoconfiguration has been defined at the ISO level only as a
server-based process. However, there is nothing to explicitly bar
other approaches. At least one ES vendor has implemented a scheme that
falls back to being completely serverless on isolated LANs (trivial,
since there's a "local scope" address format defined). This obviously
can be done without being in violation of any spec (since from the outside
you can't tell that it wasn't just statically defined).
There is also an internet draft (draft-ietf-tuba-addr-assign-00.txt) that
attempts to formalize the spectrum of possibilities into a single mechanism.
So, yes, I think you've been burned by bad info again, in that there
is no requirement per se to have a router present.
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 04 Aug 94 10:56:12 -0700
Sender: craig at aland.bbn.com
Dave:
You mean I've been burned by bad info again?
My understanding was that if one wanted to do certain types of dynamic
address assignment under OSI one had to have a router present because dynamic
assignment required ES-IS and ES-IS required a router to be present. Is this
incorrect?
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08697;
4 Aug 94 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08685;
4 Aug 94 14:18 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa10816;
4 Aug 94 14:18 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA06846 at pad-thai.aktis.com>; Thu, 4 Aug 1994 14:02:44 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA14347; Thu, 4 Aug 94 14:01:31 EDT
Received: from dun-dun-noodles.cam.ov.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA06842 at pad-thai.aktis.com>; Thu, 4 Aug 1994 14:02:42 -0400
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA22493; Thu, 4 Aug 94 14:02:41 EDT
Message-Id: <9408041802.AA22493 at dun-dun-noodles.cam.ov.com>
To: "Roland J. Schemers III" <schemers at slapshot.stanford.edu>
Cc: "Derrick J. Brashear" <db74+ at andrew.cmu.edu>, cat-ietf at mit.edu
Subject: Re: FTP questions
In-Reply-To: Your message of "Thu, 04 Aug 1994 09:32:44 PDT."
<9408040932.ZM26925 at Slapshot.Stanford.EDU>
Date: Thu, 04 Aug 1994 14:02:40 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> Isn't a token basically a kerberos ticket in a different format? Seems like
>> you should be able to build an AFS token with only the Kerberos software.
>> At least a token for your current realm/cell.
Actually, a token is a kerberos 4 ticket in essentially the same
format. There's already a program to generate a token with MIT
kerberos software, called aklog.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09917;
4 Aug 94 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09913;
4 Aug 94 15:01 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa11767;
4 Aug 94 15:01 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id EAA10768; Fri, 5 Aug 1994 04:55:43 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id EAA10740; Fri, 5 Aug 1994 04:40:49 +1000
Precedence: list
Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA15497; Fri, 5 Aug 1994 03:56:59 +1000 (from craig at aland.bbn.com)
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA23623 for big-internet at munnari.oz.au; Thu, 4 Aug 94 13:56:47 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id KAA03894; Thu, 4 Aug 1994 10:56:14 -0700
Message-Id: <199408041756.KAA03894 at aland.bbn.com>
To: Dave Katz <dkatz at cisco.com>
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of Thu, 04 Aug 94 10:51:13 -0700.
<199408041751.KAA04358 at feta.cisco.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 04 Aug 94 10:56:12 -0700
X-Orig-Sender: craig at aland.bbn.com
Dave:
You mean I've been burned by bad info again?
My understanding was that if one wanted to do certain types of dynamic
address assignment under OSI one had to have a router present because dynamic
assignment required ES-IS and ES-IS required a router to be present. Is this
incorrect?
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09929;
4 Aug 94 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09925;
4 Aug 94 15:02 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa11779;
4 Aug 94 15:02 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id EAA10785; Fri, 5 Aug 1994 04:56:54 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id EAA10743; Fri, 5 Aug 1994 04:42:00 +1000
Precedence: list
Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA15895; Fri, 5 Aug 1994 04:13:00 +1000 (from dkatz at cisco.com)
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA05791; Thu, 4 Aug 1994 11:12:43 -0700
Date: Thu, 4 Aug 1994 11:12:43 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408041812.LAA05791 at feta.cisco.com>
To: craig at aland.bbn.com
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
In-Reply-To: Craig Partridge's message of Thu, 04 Aug 94 10:56:12 -0700 <199408041756.KAA03894 at aland.bbn.com>
Subject: IPng recommendation
Sorry, I thought you were caught by the "can't forward to another box
on the wire without a router" red herring.
Address autoconfiguration has been defined at the ISO level only as a
server-based process. However, there is nothing to explicitly bar
other approaches. At least one ES vendor has implemented a scheme that
falls back to being completely serverless on isolated LANs (trivial,
since there's a "local scope" address format defined). This obviously
can be done without being in violation of any spec (since from the outside
you can't tell that it wasn't just statically defined).
There is also an internet draft (draft-ietf-tuba-addr-assign-00.txt) that
attempts to formalize the spectrum of possibilities into a single mechanism.
So, yes, I think you've been burned by bad info again, in that there
is no requirement per se to have a router present.
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 04 Aug 94 10:56:12 -0700
Sender: craig at aland.bbn.com
Dave:
You mean I've been burned by bad info again?
My understanding was that if one wanted to do certain types of dynamic
address assignment under OSI one had to have a router present because dynamic
assignment required ES-IS and ES-IS required a router to be present. Is this
incorrect?
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10391;
4 Aug 94 15:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10387;
4 Aug 94 15:26 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa12491;
4 Aug 94 15:26 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id FAA10823; Fri, 5 Aug 1994 05:16:02 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id EAA10792; Fri, 5 Aug 1994 04:59:05 +1000
Precedence: list
Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA14251; Fri, 5 Aug 1994 03:18:20 +1000 (from craig at aland.bbn.com)
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA15364 for big-internet at munnari.oz.au; Thu, 4 Aug 94 13:17:52 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id KAA03791; Thu, 4 Aug 1994 10:17:08 -0700
Message-Id: <199408041717.KAA03791 at aland.bbn.com>
To: Joachim Martillo <martillo at pluto.dss.com>
Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of Tue, 02 Aug 94 19:39:42 -0400.
<9408022339.AA20981 at pluto.dss.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 04 Aug 94 10:17:06 -0700
X-Orig-Sender: craig at aland.bbn.com
Hi:
Let me see if I can reply to some of your concerns about the IPng
criteria document. (I'll skip spots where you agreed with it and some spots
where I wasn't sure of what the key point was).
First off, the concern on 10**15 end-hosts. We're quite clear
about why we said that. We derived it straight from other work which we
felt wasn't quite demanding enough in terms of the number of devices in the
home. The fact that it comes out to 250,000 addresses per human only reflects
some of the Internet's difficulties with efficient address allocation.
Second, about performance. I'm not quite sure what your concern is but
it appears to be that we weren't firm enough about router performance. To
which, sigh, I plead that we can't please everyone. Originally the performance
section was pretty explicit that we believe that with a properly designed
IPng, certain explicit levels of router performance could be achieved.
But folks pointed out that having an experimental router that could achieve
a certain speed would meet the requirement but not achieve our goal and that
a better approach was, given that we know higher speed media (OC-48c for
instance) is coming, we simply say that commercial routers ought to be able
to achieve those speeds with IPng.
> This comment suggests that the new address structure should enable the
> quickest possible route look-up. The quickest possible route look-up
> means that a network number should conveniently correspond to a
> natural register size on common communications computers and that
> accesses to slower processor external memory should be minimized.
> Such needs and 16 byte addresses are hard to reconcile with current
> router technology.
Um, no, I'm afraid I don't agree with this analysis. I think a better
answer is to say that the header size should be a small number of cache
lines in size (the unit of access is no longer a register size). With
128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two
cache lines. Furthermore, most RISC systems have so many registers that
putting the entire header into registers isn't hard -- and the address
lookup in 90% of the cases is just a hash followed by a couple of compares.
> >over the Internet. It is not unreasonable, therefore, to
> >expect that the ratio of "local" traffic (i.e. the
> >traffic that stays on one's local network) to "export"
> >traffic (i.e. traffic destined to or sourced from a
> >network other than one's own local network) will change,
> >and the percent of export traffic will increase.
>
> This observation is not obviously true.
No, but one has to guess. Our conclusion was that if one assumed most
traffic was local, the requirements on the next generation IP were less
stringent. (In particular, there's less router traffic). So we chose the
more stringent approach.
> >We also observe that many researchers believe that a
> >proper IPng router should be capable of routing IPng
> >traffic over links at speeds that are capable of fully
> >utilizing an ATM switch on the link.
>
> ATM is yet another fad technology whose fad may be approaching its
> end. I have recently read that several companies which had started
> ATM development efforts had abandoned these efforts as pointless. A
> better targer might be wire-speed routing in the context of a LAN
> switch using fast Ethernet or CDDI.
Fast Ethernet and CDDI are too slow. We wanted to talk about 10 Gb/s speeds
and beyond. So far, ATM is the only protocol spec'd for those speeds.
> BTW, after groveling through numerous packet switching implementations
> and network drivers, almost invariably I have found that bottlenecks
> and low performance have been due not to protocol design but poor
> software implementations or (often even more importantly) due to the
> host OS architecture. The protocol design has generally been an
> extremely minor component of network/packet-switching performance.
Yep. But there are folks working on making very very fast implementations
and they are getting burned by protocol design issues.
Regarding designing for the future. I think you may be right that we're
ahistorical (shocking! -- I'm a former medievalist), but I still think that
designing for the high end of today's technology is the right approach.
The future is only 18 months away (next rev of CPUs).
> >Some predictions have been made that, as the Internet
> >grows and as more and more technically less-sophisticated
> >sites get connected, there will be more failures in the
> >network. These failures may be a combination of simple
> >size; if the size of the network goes up by a factor of n
> >then the total number of failures in the network can be
> >expected to increase by some function of n. Also, as the
> >network's users become less sophisticated, it can be
> >assumed that they will make more, innocent and well
> >meaning, mistakes, either in configuration or use of
> >their systems.
>
> This comment is just the typical obnoxious snobbishness of
> communications software engineers. If anything, the level of
> sophistication will probably increase with an increase in the number
> of sites which connect to the internet. Nowadays, someone who knows a
> little is a guru and technical wizard who feels obligated to produce
> reams of IETF draft documents. When lots of people have set up and
> run multiprotocol internetworks, a little knowledge will hardly
> impress anybody.
Actually, we're not trying to be snobbish. There has been a general shortage
of expertise in networking. And we have to expect our sites to be less
knowledgable in the future. So either the network breaks, or we make our
system more robust.
> >5.5. Transition
>
> >The transition plan should address the issue of cost
> >distribution. That is, it should identify what tasks are
> >required of the service providers, of the end users, of
> >the backbones and so on.
>
> This comment is rather scary. The IETF collectively has no obvious
> expertise in public finance, accounting or political economics.
>
> The one area where the IETF has tried to distribute costs is network
> management, and in this case the IETF has managed to make small
> installations subsidize the development of SNMP on behalf of a few
> large network providers even though the small installations have no
> real need of such a thing.
I dunno. We've got a lot of folks who've led successful startups etc.
Or putting this another way, if the idea is that folks who are in the IETF
cannot at least try to address issues of finance, accounting or economics,
why should we believe they are qualified to run businesses?
At some level, one just has to look at some of these problems -- so we will.
> >5.8. Configuration, Administration, and Operation
>
> >Also, a strength of IPv4 has been its ability to be used
> >on isolated subnets. IPng hosts must be able to work on
> >networks without routers present.
>
> Who designs a networking suite which requires routers on a single
> communications subet?
OSI used to and may still.
> >5.12. Multicast
> >Unfortunately, IPv4 currently uses the local media
> >broadcast address to multicast to all IP hosts. This
> >behavior is anti-social in mixed-protocol networks and
> >should be fixed in IPng. There's no good reason for IPng
> >to send to all hosts on a subnet when it only wishes to
> >send to all IPng hosts. The protocol must make
> >allowances for media that do not support true
> >multicasting.
>
> The above comment is idiotic. Exactly how a network layer multicast
> is resolved to a MAC layer address for some arbitrary medium is not
> obviously part of the network layer design.
Sure it is.
> >5.18. Things We Chose Not to Require
>
> I am not sure how MTU discovery overcomes the need for fragmentation
> unless MTU discovery is performed before each packet is sent and
> strict source routing is employed.
Read the MTU discovery spec. You don't need strict source routing or discovery
before each packet.
> >IP Header Checksum
> >There has been discussion indicating that the IP Checksum
> >does not provide enough error protection to warrant its
> >performance impact. The argument states that there is
> >almost always a stronger datalink level CRC, and that
> >end-to-end protection is provided by the TCP checksum.
> >Therefore we believe that an IPng checksum is not
> >required per-se.
>
> The IP header checksum is not intended to provide end-to-end data
> integrity but rather provides local address integrity. Few routers
> provide EDAC. Stuck bits in the wrong place after receive datalink
> CRC is calculated could easily cause some poor neighboring router to
> be inundated with misdirected packets whose lack of data integrity
> might not be detected until much later or even never (if the new
> address corresponds to no actual address). This problem could be
> particularly serious in the cases of applications which rarely or
> infrequently require acknowledgement of transmitted data packets.
Read the paragraph again. It says that local address integrity is sufficiently
protected by the link CRC and that end-to-end integrity of the IP datagram
is ensured by the end-to-end TCP checksums. Simple engineering.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11366;
4 Aug 94 16:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11358;
4 Aug 94 16:31 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa13809;
4 Aug 94 16:31 EDT
Received: from tsx-11.MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA09930 at pad-thai.aktis.com>; Thu, 4 Aug 1994 16:12:46 -0400
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA02818; Thu, 4 Aug 94 16:11:27 EDT
Date: Thu, 4 Aug 94 16:11:27 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9408042011.AA02818 at tsx-11.MIT.EDU>
To: John Linn <linn at cam.ov.com>
Cc: Simon Cooper <scooper at hardees.rutgers.edu>, cat-ietf at cam.ov.com,
bossert at hardees.rutgers.edu, drummond at hardees.rutgers.edu,
pleasant at hardees.rutgers.edu, dmk at hardees.rutgers.edu, linn at cam.ov.com
In-Reply-To: John Linn's message of Thu, 04 Aug 1994 08:37:06 -0400,
<9408041237.AA09737 at winkl.aktis.com>
Subject: Re: "service-to-client" one-way authentication.
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 04 Aug 1994 08:37:06 -0400
From: John Linn <linn at cam.ov.com>
It is a fact that GSS-API as it stands supports two classes of
authentication, one-way and mutual, selectable by the initiator
of a security context. In most cases (though this is not required
by GSS-API), a client is a context initiator and the server it accesses
is a context acceptor; this being the common case, we've sometimes
fallen into the inadvertent trap of using "client" as a synonym
for "initiator". One-way authentication from Mosaic service to
Mosaic accessor could be handled today at the GSS-API level
by having the Mosaic service initiate a security context to the
requesting Mosaic client, using one-way authentication. This works
fine at the level of GSS-API, which doesn't impose much asymmetry
between clients and servers, but won't necessarily work with
supporting mechanisms which implement clients' and servers' code
and manage their keys differently.
What this says is that it is possible to implement a GSS-API client
which conforms to the GSS-API specification, but yet will not work on
many mechanisms. While this is perhaps always been true --- a client
could require confidentiality services which the mechanism could not
supply, this grows the potential interoperability gap.
At minimum, what this implies is that when a mechanism is documented,
not only does it need to say what confidentiality/authentication
forwarding/etc services it provides, it should also state what
restrictions it might have on clients/servers in the roles of initiator
and acceptor.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12626;
4 Aug 94 17:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12618;
4 Aug 94 17:49 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa15874;
4 Aug 94 17:49 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <RAA11570 at pad-thai.aktis.com>; Thu, 4 Aug 1994 17:30:34 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vipin.Samar at eng.sun.com
Received: from Sun.COM by MIT.EDU with SMTP
id AA01425; Thu, 4 Aug 94 17:29:19 EDT
Received: from Eng.Sun.COM (mxchange.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA18828; Thu, 4 Aug 94 14:29:13 PDT
Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (8.6.9/SMI-4.1)
id OAA02117; Thu, 4 Aug 1994 14:28:27 -0700
Received: from tiny.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
id AA20054; Thu, 4 Aug 1994 14:28:26 -0700
Received: by tiny.Eng.Sun.COM (5.x/SMI-SVR4)
id AA07001; Thu, 4 Aug 1994 14:29:00 -0700
Date: Thu, 4 Aug 1994 14:29:00 -0700
Message-Id: <9408042129.AA07001 at tiny.Eng.Sun.COM>
To: cat-ietf at mit.edu
Subject: buffer mgmt and performance issues
X-Sun-Charset: US-ASCII
I noticed that there were a few discussions in Toronto about buffer
mgmt issues.
As it is, security adds its own overhead on top of the current
performance, and for any secure system to be usable, among other
things, we have to be sure that the performance hit is minimized. One
area where this can be done is by improving GSS-API's
buffer management.
For example, in gss_sign() operation, it requires the calculation of
the message digest of the data using MD5 or whatever algorithm. Then,
typically the application would copy the generated token to a common
buffer area so that the data and signature can be sent in one packet
using t_snd(), send() or whatever(). I would like to avoid this copying
by passing a preallocated buffer to gss_sign(). One way of
implementing this would be to allocate a big buffer for both the
message and the signature, and then just pass the address of the
signature block to gss_sign(). This would basically save the time it
takes to copy the message digest.
The second problem is that gss_seal() outputs a new buffer which may be
lot longer than the original data segment. This could be a problem for
applications like NFS which break up the file into UDP packet size. I
have heard that there are discussions under way to provide support for
large data. I just wanted to reiterate the fact that we should provide
support of this kind to GSS-API. Conversly, I would also like to have
support for limiting the size of the output buffer obtained after
calling gss_seal(). Again taking the example of NFS, this would limit
the data packets to 8K (If I so desire). In such cases, I would like
the API to return the length of the data that it could process so that
gss_seal() could be called again with the remaining data.
The other problem with gss_seal(), gss_unseal(), and gss_sign() is that
the GSS-API implementation is expected to allocate the buffer area and
then the application is supposed to free it by gss_release_buffer().
All this malloc() and free() calls can be avoided by passing a
pre-allocated buffer to the API; if the answer does not fit the buffer
length, then an appropriate error message should be returned (e.g.
GSS_S_TOO_SMALL) in which case, the application is free to select a new
buffer size. The length field of the buffer can be suitably set to
denote that the caller is passing a preallocated buffer. Admittedly,
the gains here are small, but every bit helps.
Comments?
vipin
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12897;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16025;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12849;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12697;
4 Aug 94 17:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mhsds-long-bud-intro-02.txt
Date: Thu, 04 Aug 94 17:50:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041750.aa12697 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Introducing Project Long Bud: Internet Pilot Project
for the Deployment of X.500 Directory Information in
Support of X.400 Routing
Author(s) : H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera
Filename : draft-ietf-mhsds-long-bud-intro-02.txt
Pages : 13
Date : 08/03/1994
The Internet X.400 community (i.e. GO-MHS) currently lacks a distributed
mechanism providing dynamic updating and management of message routing
information. The IETF MHS-DS Working Group has specified an approach for
X.400 Message Handling Systems to perform message routing using OSI
Directory Services. The MHS-DS approach has been successfully tested in a
number of local environments.
This INTERNET-DRAFT describes a proposed Internet Pilot Project that
seeks to prove the MHS-DS approach on a larger scale. The results of
this pilot will then be used to draw up recommendations for a
global deployment.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-long-bud-intro-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mhsds-long-bud-intro-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhsds-long-bud-intro-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-long-bud-intro-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12897;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16025;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12849;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12697;
4 Aug 94 17:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mhsds-long-bud-intro-02.txt
Date: Thu, 04 Aug 94 17:50:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041750.aa12697 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Introducing Project Long Bud: Internet Pilot Project
for the Deployment of X.500 Directory Information in
Support of X.400 Routing
Author(s) : H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera
Filename : draft-ietf-mhsds-long-bud-intro-02.txt
Pages : 13
Date : 08/03/1994
The Internet X.400 community (i.e. GO-MHS) currently lacks a distributed
mechanism providing dynamic updating and management of message routing
information. The IETF MHS-DS Working Group has specified an approach for
X.400 Message Handling Systems to perform message routing using OSI
Directory Services. The MHS-DS approach has been successfully tested in a
number of local environments.
This INTERNET-DRAFT describes a proposed Internet Pilot Project that
seeks to prove the MHS-DS approach on a larger scale. The results of
this pilot will then be used to draw up recommendations for a
global deployment.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-long-bud-intro-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mhsds-long-bud-intro-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhsds-long-bud-intro-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-long-bud-intro-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12898;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16023;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12847;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12736;
4 Aug 94 17:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-imap4-05.txt
Date: Thu, 04 Aug 94 17:51:46 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041751.aa12736 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
Author(s) : M. Crispin
Filename : draft-ietf-imap-imap4-05.txt
Pages : 69
Date : 08/03/1994
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to
access and manipulate electronic mail messages on a server. IMAP4 permits
manipulation of remote message folders, called "mailboxes", in a way that
is functionally equivalent to local mailboxes. IMAP4 also provides the
capability for an offline client to resynchronize with the server (see also
[IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes;
checking for new messages; permanently removing messages;
setting and clearing flags; RFC 822 and MIME parsing; searching;
and selective fetching of message attributes, texts, and portions thereof.
Messages in IMAP4 are accessed by the use of numbers. These numbers are
either message sequence numbers (relative position from 1 to the number of
messages in the mailbox) or unique identifiers (immutable, strictly
ascending values assigned to each message, but which are not necessarily
contiguous).
IMAP4 supports a single server. A mechanism for supporting
multiple IMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by
a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
Compatibility issues are discussed in [IMAP-COMPAT].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-imap4-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-imap4-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-imap4-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-imap4-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12898;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16023;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12847;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12736;
4 Aug 94 17:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-imap4-05.txt
Date: Thu, 04 Aug 94 17:51:46 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041751.aa12736 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
Author(s) : M. Crispin
Filename : draft-ietf-imap-imap4-05.txt
Pages : 69
Date : 08/03/1994
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to
access and manipulate electronic mail messages on a server. IMAP4 permits
manipulation of remote message folders, called "mailboxes", in a way that
is functionally equivalent to local mailboxes. IMAP4 also provides the
capability for an offline client to resynchronize with the server (see also
[IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes;
checking for new messages; permanently removing messages;
setting and clearing flags; RFC 822 and MIME parsing; searching;
and selective fetching of message attributes, texts, and portions thereof.
Messages in IMAP4 are accessed by the use of numbers. These numbers are
either message sequence numbers (relative position from 1 to the number of
messages in the mailbox) or unique identifiers (immutable, strictly
ascending values assigned to each message, but which are not necessarily
contiguous).
IMAP4 supports a single server. A mechanism for supporting
multiple IMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by
a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
Compatibility issues are discussed in [IMAP-COMPAT].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-imap4-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-imap4-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-imap4-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-imap4-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12929;
4 Aug 94 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12898;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16023;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12847;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12736;
4 Aug 94 17:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-imap4-05.txt
Date: Thu, 04 Aug 94 17:51:46 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041751.aa12736 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
Author(s) : M. Crispin
Filename : draft-ietf-imap-imap4-05.txt
Pages : 69
Date : 08/03/1994
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to
access and manipulate electronic mail messages on a server. IMAP4 permits
manipulation of remote message folders, called "mailboxes", in a way that
is functionally equivalent to local mailboxes. IMAP4 also provides the
capability for an offline client to resynchronize with the server (see also
[IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes;
checking for new messages; permanently removing messages;
setting and clearing flags; RFC 822 and MIME parsing; searching;
and selective fetching of message attributes, texts, and portions thereof.
Messages in IMAP4 are accessed by the use of numbers. These numbers are
either message sequence numbers (relative position from 1 to the number of
messages in the mailbox) or unique identifiers (immutable, strictly
ascending values assigned to each message, but which are not necessarily
contiguous).
IMAP4 supports a single server. A mechanism for supporting
multiple IMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by
a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
Compatibility issues are discussed in [IMAP-COMPAT].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-imap4-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-imap4-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-imap4-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-imap4-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12930;
4 Aug 94 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12897;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16025;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12849;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12697;
4 Aug 94 17:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mhsds-long-bud-intro-02.txt
Date: Thu, 04 Aug 94 17:50:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041750.aa12697 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Introducing Project Long Bud: Internet Pilot Project
for the Deployment of X.500 Directory Information in
Support of X.400 Routing
Author(s) : H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera
Filename : draft-ietf-mhsds-long-bud-intro-02.txt
Pages : 13
Date : 08/03/1994
The Internet X.400 community (i.e. GO-MHS) currently lacks a distributed
mechanism providing dynamic updating and management of message routing
information. The IETF MHS-DS Working Group has specified an approach for
X.400 Message Handling Systems to perform message routing using OSI
Directory Services. The MHS-DS approach has been successfully tested in a
number of local environments.
This INTERNET-DRAFT describes a proposed Internet Pilot Project that
seeks to prove the MHS-DS approach on a larger scale. The results of
this pilot will then be used to draw up recommendations for a
global deployment.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-long-bud-intro-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mhsds-long-bud-intro-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhsds-long-bud-intro-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-long-bud-intro-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12947;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16047;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12845;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12585;
4 Aug 94 17:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-04.txt
Date: Thu, 04 Aug 94 17:48:45 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041748.aa12585 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-04.txt
Pages : 6
Date : 08/03/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803133157.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803133157.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12947;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16047;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12845;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12585;
4 Aug 94 17:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-04.txt
Date: Thu, 04 Aug 94 17:48:45 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041748.aa12585 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-04.txt
Pages : 6
Date : 08/03/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803133157.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803133157.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12946;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16058;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12859;
4 Aug 94 17:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12788;
4 Aug 94 17:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-dorner-content-header-00.txt
Date: Thu, 04 Aug 94 17:52:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041752.aa12788 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Communicating Presentation Information in Internet
Messages: The Content-Disposition Header
Author(s) : R. Troost, S. Dorner
Filename : draft-dorner-content-header-00.txt
Pages : 8
Date : 08/03/1994
This memo provides a mechanism whereby messages conforming to the [RFC
1521] ("MIME") specification can convey presentational information. It
specifies a new "Content-Disposition" header, optional and valid for any
[RFC 1521] entity ("message" or "body part"). Two values for this header
are described in this memo; one for the ordinary linear presentation of the
body part, and another to facilitate the use of mail to transfer files. It
is expected that more values will be defined in the future, and procedures
are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such,
the reader is assumed to be familiar with [RFC 1521], [RFC 1522], and
[RFC 822]. The information presented herein supplements but does
not replace that found in those documents.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-dorner-content-header-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dorner-content-header-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803150434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-dorner-content-header-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dorner-content-header-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803150434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12946;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16058;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12859;
4 Aug 94 17:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12788;
4 Aug 94 17:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-dorner-content-header-00.txt
Date: Thu, 04 Aug 94 17:52:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041752.aa12788 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Communicating Presentation Information in Internet
Messages: The Content-Disposition Header
Author(s) : R. Troost, S. Dorner
Filename : draft-dorner-content-header-00.txt
Pages : 8
Date : 08/03/1994
This memo provides a mechanism whereby messages conforming to the [RFC
1521] ("MIME") specification can convey presentational information. It
specifies a new "Content-Disposition" header, optional and valid for any
[RFC 1521] entity ("message" or "body part"). Two values for this header
are described in this memo; one for the ordinary linear presentation of the
body part, and another to facilitate the use of mail to transfer files. It
is expected that more values will be defined in the future, and procedures
are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such,
the reader is assumed to be familiar with [RFC 1521], [RFC 1522], and
[RFC 822]. The information presented herein supplements but does
not replace that found in those documents.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-dorner-content-header-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dorner-content-header-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803150434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-dorner-content-header-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dorner-content-header-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803150434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12969;
4 Aug 94 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12946;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16058;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12859;
4 Aug 94 17:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12788;
4 Aug 94 17:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-dorner-content-header-00.txt
Date: Thu, 04 Aug 94 17:52:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041752.aa12788 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Communicating Presentation Information in Internet
Messages: The Content-Disposition Header
Author(s) : R. Troost, S. Dorner
Filename : draft-dorner-content-header-00.txt
Pages : 8
Date : 08/03/1994
This memo provides a mechanism whereby messages conforming to the [RFC
1521] ("MIME") specification can convey presentational information. It
specifies a new "Content-Disposition" header, optional and valid for any
[RFC 1521] entity ("message" or "body part"). Two values for this header
are described in this memo; one for the ordinary linear presentation of the
body part, and another to facilitate the use of mail to transfer files. It
is expected that more values will be defined in the future, and procedures
are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such,
the reader is assumed to be familiar with [RFC 1521], [RFC 1522], and
[RFC 822]. The information presented herein supplements but does
not replace that found in those documents.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-dorner-content-header-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dorner-content-header-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803150434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-dorner-content-header-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dorner-content-header-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803150434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13309;
4 Aug 94 18:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13305;
4 Aug 94 18:13 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa16683;
4 Aug 94 18:13 EDT
Received: by mercury.udev.cdc.com; Thu, 4 Aug 94 16:57:42 -0500
X-From: cclark at cnri.reston.va.us Thu Aug 4 16:57 CDT 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Thu, 4 Aug 94 16:57:22 -0500
Received: from ietf.cnri.reston.va.us by zeus.cdc.com; Thu, 4 Aug 94 16:56:54 -0500
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12697;
4 Aug 94 17:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhs-ds at mercury.udev.cdc.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mhsds-long-bud-intro-02.txt
Date: Thu, 04 Aug 94 17:50:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041750.aa12697 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MHS-DS Working Group of the
IETF.
Title : Introducing Project Long Bud: Internet Pilot Project
for the Deployment of X.500 Directory Information in
Support of X.400 Routing
Author(s) : H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera
Filename : draft-ietf-mhsds-long-bud-intro-02.txt
Pages : 13
Date : 08/03/1994
The Internet X.400 community (i.e. GO-MHS) currently lacks a distributed
mechanism providing dynamic updating and management of message routing
information. The IETF MHS-DS Working Group has specified an approach for
X.400 Message Handling Systems to perform message routing using OSI
Directory Services. The MHS-DS approach has been successfully tested in a
number of local environments.
This INTERNET-DRAFT describes a proposed Internet Pilot Project that
seeks to prove the MHS-DS approach on a larger scale. The results of
this pilot will then be used to draw up recommendations for a
global deployment.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mhsds-long-bud-intro-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mhsds-long-bud-intro-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhsds-long-bud-intro-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhsds-long-bud-intro-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803142305.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12968;
4 Aug 94 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12947;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16047;
4 Aug 94 17:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12845;
4 Aug 94 17:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12585;
4 Aug 94 17:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-04.txt
Date: Thu, 04 Aug 94 17:48:45 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041748.aa12585 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-04.txt
Pages : 6
Date : 08/03/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803133157.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803133157.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13443;
4 Aug 94 18:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13439;
4 Aug 94 18:29 EDT
Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa16974;
4 Aug 94 18:29 EDT
Received: by mx2.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA20385;
Thu, 4 Aug 94 15:08:32 -0700
Errors-To: owner-imap at cac.washington.edu
X-Orig-Sender: owner-imap at cac.washington.edu
Return-Path: <cclark at CNRI.Reston.VA.US>
Received: from ietf.cnri.reston.va.us by mx2.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA20379;
Thu, 4 Aug 94 15:08:29 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12736;
4 Aug 94 17:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: imap at cac.washington.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-imap4-05.txt
Date: Thu, 04 Aug 94 17:51:46 -0400
Message-Id: <9408041751.aa12736 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
Author(s) : M. Crispin
Filename : draft-ietf-imap-imap4-05.txt
Pages : 69
Date : 08/03/1994
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to
access and manipulate electronic mail messages on a server. IMAP4 permits
manipulation of remote message folders, called "mailboxes", in a way that
is functionally equivalent to local mailboxes. IMAP4 also provides the
capability for an offline client to resynchronize with the server (see also
[IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes;
checking for new messages; permanently removing messages;
setting and clearing flags; RFC 822 and MIME parsing; searching;
and selective fetching of message attributes, texts, and portions thereof.
Messages in IMAP4 are accessed by the use of numbers. These numbers are
either message sequence numbers (relative position from 1 to the number of
messages in the mailbox) or unique identifiers (immutable, strictly
ascending values assigned to each message, but which are not necessarily
contiguous).
IMAP4 supports a single server. A mechanism for supporting
multiple IMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by
a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
Compatibility issues are discussed in [IMAP-COMPAT].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-imap4-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-imap4-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-imap4-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-imap4-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803145240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13733;
4 Aug 94 18:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17291;
4 Aug 94 18:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13716;
4 Aug 94 18:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12639;
4 Aug 94 17:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: notifications at cs.utk.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-notary-mime-report-00.txt
Date: Thu, 04 Aug 94 17:49:54 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041749.aa12639 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Notifications and
Acknowledgements Requirements Working Group of the IETF.
Title : Multipart/Report
Author(s) : G. Vaudreuil
Filename : draft-ietf-notary-mime-report-00.txt
Pages : 2
Date : 08/03/1994
This memo defines a generic packaging mechanism for mail system reports.
The Multipart/Report is a convention for interpersonal message
notifications for MIME.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-notary-mime-report-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-notary-mime-report-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803134039.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-notary-mime-report-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-notary-mime-report-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803134039.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13733;
4 Aug 94 18:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17291;
4 Aug 94 18:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13716;
4 Aug 94 18:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12639;
4 Aug 94 17:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: notifications at cs.utk.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-notary-mime-report-00.txt
Date: Thu, 04 Aug 94 17:49:54 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041749.aa12639 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Notifications and
Acknowledgements Requirements Working Group of the IETF.
Title : Multipart/Report
Author(s) : G. Vaudreuil
Filename : draft-ietf-notary-mime-report-00.txt
Pages : 2
Date : 08/03/1994
This memo defines a generic packaging mechanism for mail system reports.
The Multipart/Report is a convention for interpersonal message
notifications for MIME.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-notary-mime-report-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-notary-mime-report-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803134039.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-notary-mime-report-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-notary-mime-report-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803134039.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13745;
4 Aug 94 18:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13733;
4 Aug 94 18:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17291;
4 Aug 94 18:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13716;
4 Aug 94 18:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12639;
4 Aug 94 17:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: notifications at cs.utk.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-notary-mime-report-00.txt
Date: Thu, 04 Aug 94 17:49:54 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408041749.aa12639 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Notifications and
Acknowledgements Requirements Working Group of the IETF.
Title : Multipart/Report
Author(s) : G. Vaudreuil
Filename : draft-ietf-notary-mime-report-00.txt
Pages : 2
Date : 08/03/1994
This memo defines a generic packaging mechanism for mail system reports.
The Multipart/Report is a convention for interpersonal message
notifications for MIME.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-notary-mime-report-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-notary-mime-report-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940803134039.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-notary-mime-report-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-notary-mime-report-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940803134039.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05348;
5 Aug 94 11:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05344;
5 Aug 94 11:52 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa09784;
5 Aug 94 11:51 EDT
Received: by atlas.xylogics.com id AA19198 (5.65c/UK-2.1-940401);
Fri, 5 Aug 1994 11:51:46 -0400
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by atlas.xylogics.com with SMTP
id AA11547 (5.65c/UK-2.1-940401); Fri, 5 Aug 1994 11:51:38 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05205;
5 Aug 94 11:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: @cnri.reston.va.us:;
Cc: ietf-rip at xylogics.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ripv2-mibext2-02.txt
Date: Fri, 05 Aug 94 11:46:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408051146.aa05205 at IETF.CNRI.Reston.VA.US>
--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 MIB Extension
Author(s) : G. Malkin, F. Baker
Filename : draft-ietf-ripv2-mibext2-02.txt
Pages : 19
Date : 08/04/1994
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing RIP Version 2.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ripv2-mibext2-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mibext2-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-mibext2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-mibext2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05495;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09985;
5 Aug 94 12:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05452;
5 Aug 94 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04949;
5 Aug 94 11:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-lagoze-dienst-protocol-00.txt
Date: Fri, 05 Aug 94 11:28:32 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051128.aa04949 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dienst, A Protocol for a Distributed Digital
Document Library
Author(s) : J. Davis, C. Lagoze
Filename : draft-lagoze-dienst-protocol-00.txt
Pages : 12
Date : 08/04/1994
This document describes Dienst, a protocol for communication with
distributed digital library servers. This protocol provides an
object-oriented interface to a document model, which allows a user to
access complete documents or named sub-parts. It also supports multiple
formats for documents. Dienst protocol messages are embedded within HTTP,
the protocol used over the World Wide Web. Thus, anyone using a Web browser
(e.g. Mosaic, Cello) has access to the services provided by Dienst.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-lagoze-dienst-protocol-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lagoze-dienst-protocol-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804151316.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-lagoze-dienst-protocol-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lagoze-dienst-protocol-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804151316.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05495;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09985;
5 Aug 94 12:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05452;
5 Aug 94 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04949;
5 Aug 94 11:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-lagoze-dienst-protocol-00.txt
Date: Fri, 05 Aug 94 11:28:32 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051128.aa04949 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dienst, A Protocol for a Distributed Digital
Document Library
Author(s) : J. Davis, C. Lagoze
Filename : draft-lagoze-dienst-protocol-00.txt
Pages : 12
Date : 08/04/1994
This document describes Dienst, a protocol for communication with
distributed digital library servers. This protocol provides an
object-oriented interface to a document model, which allows a user to
access complete documents or named sub-parts. It also supports multiple
formats for documents. Dienst protocol messages are embedded within HTTP,
the protocol used over the World Wide Web. Thus, anyone using a Web browser
(e.g. Mosaic, Cello) has access to the services provided by Dienst.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-lagoze-dienst-protocol-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lagoze-dienst-protocol-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804151316.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-lagoze-dienst-protocol-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lagoze-dienst-protocol-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804151316.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05504;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09987;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab05452;
5 Aug 94 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05205;
5 Aug 94 11:46 EDT
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.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ripv2-mibext2-02.txt
Date: Fri, 05 Aug 94 11:46:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051146.aa05205 at IETF.CNRI.Reston.VA.US>
--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 MIB Extension
Author(s) : G. Malkin, F. Baker
Filename : draft-ietf-ripv2-mibext2-02.txt
Pages : 19
Date : 08/04/1994
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing RIP Version 2.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ripv2-mibext2-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mibext2-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-mibext2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-mibext2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05504;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09987;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab05452;
5 Aug 94 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05205;
5 Aug 94 11:46 EDT
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.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ripv2-mibext2-02.txt
Date: Fri, 05 Aug 94 11:46:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051146.aa05205 at IETF.CNRI.Reston.VA.US>
--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 MIB Extension
Author(s) : G. Malkin, F. Baker
Filename : draft-ietf-ripv2-mibext2-02.txt
Pages : 19
Date : 08/04/1994
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing RIP Version 2.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ripv2-mibext2-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mibext2-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-mibext2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-mibext2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05509;
5 Aug 94 12:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05495;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09985;
5 Aug 94 12:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05452;
5 Aug 94 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04949;
5 Aug 94 11:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-lagoze-dienst-protocol-00.txt
Date: Fri, 05 Aug 94 11:28:32 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051128.aa04949 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Dienst, A Protocol for a Distributed Digital
Document Library
Author(s) : J. Davis, C. Lagoze
Filename : draft-lagoze-dienst-protocol-00.txt
Pages : 12
Date : 08/04/1994
This document describes Dienst, a protocol for communication with
distributed digital library servers. This protocol provides an
object-oriented interface to a document model, which allows a user to
access complete documents or named sub-parts. It also supports multiple
formats for documents. Dienst protocol messages are embedded within HTTP,
the protocol used over the World Wide Web. Thus, anyone using a Web browser
(e.g. Mosaic, Cello) has access to the services provided by Dienst.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-lagoze-dienst-protocol-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lagoze-dienst-protocol-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804151316.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-lagoze-dienst-protocol-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lagoze-dienst-protocol-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804151316.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05524;
5 Aug 94 12:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05504;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09987;
5 Aug 94 12:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab05452;
5 Aug 94 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05205;
5 Aug 94 11:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ripv2-mibext2-02.txt
Date: Fri, 05 Aug 94 11:46:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051146.aa05205 at IETF.CNRI.Reston.VA.US>
--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 MIB Extension
Author(s) : G. Malkin, F. Baker
Filename : draft-ietf-ripv2-mibext2-02.txt
Pages : 19
Date : 08/04/1994
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing RIP Version 2.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ripv2-mibext2-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mibext2-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ripv2-mibext2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-mibext2-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804154734.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06113;
5 Aug 94 12:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06105;
5 Aug 94 12:51 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa10988;
5 Aug 94 12:51 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA00241 at pad-thai.aktis.com>; Fri, 5 Aug 1994 12:24:44 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA15358; Fri, 5 Aug 94 12:23:20 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/27May94)
id AA20913; Fri, 5 Aug 94 09:15:42 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AB21932; Fri, 5 Aug 94 12:15:44 -0400
Message-Id: <9408051615.AB21932 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 5 Aug 94 12:15:44 EDT
Date: Fri, 5 Aug 94 12:15:44 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 05-Aug-1994 1111" <wray at tuxedo.enet.dec.com>
To: vipin.samar at eng.sun.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, vipin.samar at eng.sun.com
Subject: RE: buffer mgmt and performance issues
Vipin,
>For example, in gss_sign() operation, it requires the calculation of
>the message digest of the data using MD5 or whatever algorithm. Then,
>typically the application would copy the generated token to a common
>buffer area so that the data and signature can be sent in one packet
>using t_snd(), send() or whatever(). I would like to avoid this copying
>by passing a preallocated buffer to gss_sign(). One way of
>implementing this would be to allocate a big buffer for both the
>message and the signature, and then just pass the address of the
>signature block to gss_sign(). This would basically save the time it
>takes to copy the message digest.
If I understand you correctly, wouldn't this technique require that the
application know the size of the signature block before it calls gss_sign(), so
that it knows how much room to leave for it before the start of the data? Or
are you going to put the data into the output buffer after the signature's been
calculated? If so, then you're willing to copy the data instead of the
signature (which will typically be short - on the order of tens of bytes), so
you might consider using gss_seal instead of gss_sign, as that's exactly what
gss_seal does.
In general though, I'd have thought that the time taken to copy a gss_sign
token would be far outweighed by everything else that's going on (cryptographic
operations, network comms, etc).
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06113;
5 Aug 94 12:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06105;
5 Aug 94 12:51 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa10988;
5 Aug 94 12:51 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA00241 at pad-thai.aktis.com>; Fri, 5 Aug 1994 12:24:44 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA15358; Fri, 5 Aug 94 12:23:20 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/27May94)
id AA20913; Fri, 5 Aug 94 09:15:42 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AB21932; Fri, 5 Aug 94 12:15:44 -0400
Message-Id: <9408051615.AB21932 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 5 Aug 94 12:15:44 EDT
Date: Fri, 5 Aug 94 12:15:44 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 05-Aug-1994 1111" <wray at tuxedo.enet.dec.com>
To: vipin.samar at eng.sun.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, vipin.samar at eng.sun.com
Subject: RE: buffer mgmt and performance issues
Vipin,
>For example, in gss_sign() operation, it requires the calculation of
>the message digest of the data using MD5 or whatever algorithm. Then,
>typically the application would copy the generated token to a common
>buffer area so that the data and signature can be sent in one packet
>using t_snd(), send() or whatever(). I would like to avoid this copying
>by passing a preallocated buffer to gss_sign(). One way of
>implementing this would be to allocate a big buffer for both the
>message and the signature, and then just pass the address of the
>signature block to gss_sign(). This would basically save the time it
>takes to copy the message digest.
If I understand you correctly, wouldn't this technique require that the
application know the size of the signature block before it calls gss_sign(), so
that it knows how much room to leave for it before the start of the data? Or
are you going to put the data into the output buffer after the signature's been
calculated? If so, then you're willing to copy the data instead of the
signature (which will typically be short - on the order of tens of bytes), so
you might consider using gss_seal instead of gss_sign, as that's exactly what
gss_seal does.
In general though, I'd have thought that the time taken to copy a gss_sign
token would be far outweighed by everything else that's going on (cryptographic
operations, network comms, etc).
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06243;
5 Aug 94 13:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06235;
5 Aug 94 13:00 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa11183;
5 Aug 94 13:00 EDT
Received: from ptolemaeus.rutgers.edu by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA00593 at pad-thai.aktis.com>; Fri, 5 Aug 1994 12:40:55 -0400
Received: by ptolemaeus.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA06369; Fri, 5 Aug 94 12:39:31 EDT
Date: Fri, 5 Aug 94 12:39:30 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mel Pleasant <pleasant at ptolemaeus.rutgers.edu>
To: Theodore Ts'o <tytso at athena.mit.edu>
Cc: John Linn <linn at cam.ov.com>, Simon Cooper <scooper at hardees.rutgers.edu>,
cat-ietf at cam.ov.com, bossert at hardees.rutgers.edu,
drummond at hardees.rutgers.edu, dmk at hardees.rutgers.edu, linn at cam.ov.com
Subject: Re: "service-to-client" one-way authentication.
In-Reply-To: Your message of Thu, 4 Aug 94 16:11:27 EDT
Message-Id: <CMM-RU.1.4.776104770.pleasant at ptolemaeus.rutgers.edu>
> Date: Thu, 04 Aug 1994 08:37:06 -0400
> From: John Linn <linn at cam.ov.com>
>
> It is a fact that GSS-API as it stands supports two classes of
> authentication, one-way and mutual, selectable by the initiator
> of a security context. In most cases (though this is not required
> by GSS-API), a client is a context initiator and the server it accesses
> is a context acceptor; this being the common case, we've sometimes
> fallen into the inadvertent trap of using "client" as a synonym
> for "initiator". One-way authentication from Mosaic service to
> Mosaic accessor could be handled today at the GSS-API level
> by having the Mosaic service initiate a security context to the
> requesting Mosaic client, using one-way authentication. This works
> fine at the level of GSS-API, which doesn't impose much asymmetry
> between clients and servers, but won't necessarily work with
> supporting mechanisms which implement clients' and servers' code
> and manage their keys differently.
>
> What this says is that it is possible to implement a GSS-API client
> which conforms to the GSS-API specification, but yet will not work on
> many mechanisms. While this is perhaps always been true --- a client
> could require confidentiality services which the mechanism could not
> supply, this grows the potential interoperability gap.
>
> At minimum, what this implies is that when a mechanism is documented,
> not only does it need to say what confidentiality/authentication
> forwarding/etc services it provides, it should also state what
> restrictions it might have on clients/servers in the roles of initiator
> and acceptor.
>
> - Ted
>
>
Indeed, if/when GSS-API enters a negotiation phase between client and server
over just which mechanisms are available and ultimately decide upon which one
to use, much of the decision will need to be based upon just what services
are required by the calling modules . . . .
-- Mel
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06686;
5 Aug 94 13:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11942;
5 Aug 94 13:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06672;
5 Aug 94 13:33 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06572;
5 Aug 94 13:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ohta-simple-dns-00.txt
Date: Fri, 05 Aug 94 13:30:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051330.aa06572 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Secure DNS
Author(s) : M. Ohta
Filename : draft-ohta-simple-dns-00.txt
Pages : 17
Date : 08/04/1994
An extension to DNS is proposed to make answers from it authenticated.
The extension is designed to be minimal, which will be useful as a
framework to make applications provide required level of authentication
and/or confidentiality.
The changes to the existing architecture of DNS is also minimized.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ohta-simple-dns-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-simple-dns-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804134437.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ohta-simple-dns-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ohta-simple-dns-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804134437.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06686;
5 Aug 94 13:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11942;
5 Aug 94 13:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06672;
5 Aug 94 13:33 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06572;
5 Aug 94 13:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ohta-simple-dns-00.txt
Date: Fri, 05 Aug 94 13:30:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051330.aa06572 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Secure DNS
Author(s) : M. Ohta
Filename : draft-ohta-simple-dns-00.txt
Pages : 17
Date : 08/04/1994
An extension to DNS is proposed to make answers from it authenticated.
The extension is designed to be minimal, which will be useful as a
framework to make applications provide required level of authentication
and/or confidentiality.
The changes to the existing architecture of DNS is also minimized.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ohta-simple-dns-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-simple-dns-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804134437.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ohta-simple-dns-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ohta-simple-dns-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804134437.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06698;
5 Aug 94 13:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06686;
5 Aug 94 13:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11942;
5 Aug 94 13:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06672;
5 Aug 94 13:33 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06572;
5 Aug 94 13:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ohta-simple-dns-00.txt
Date: Fri, 05 Aug 94 13:30:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051330.aa06572 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Simple Secure DNS
Author(s) : M. Ohta
Filename : draft-ohta-simple-dns-00.txt
Pages : 17
Date : 08/04/1994
An extension to DNS is proposed to make answers from it authenticated.
The extension is designed to be minimal, which will be useful as a
framework to make applications provide required level of authentication
and/or confidentiality.
The changes to the existing architecture of DNS is also minimized.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ohta-simple-dns-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-simple-dns-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804134437.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ohta-simple-dns-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ohta-simple-dns-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804134437.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06844;
5 Aug 94 13:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12053;
5 Aug 94 13:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06831;
5 Aug 94 13:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06779;
5 Aug 94 13:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-model-00.txt
Date: Fri, 05 Aug 94 13:35:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051335.aa06779 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
Author(s) : M. Crispin
Filename : draft-ietf-imap-model-00.txt
Pages : 4
Date : 08/04/1994
This memo describes the distributed electronic mail model of IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-model-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06844;
5 Aug 94 13:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12053;
5 Aug 94 13:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06831;
5 Aug 94 13:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06779;
5 Aug 94 13:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-model-00.txt
Date: Fri, 05 Aug 94 13:35:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051335.aa06779 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
Author(s) : M. Crispin
Filename : draft-ietf-imap-model-00.txt
Pages : 4
Date : 08/04/1994
This memo describes the distributed electronic mail model of IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-model-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06855;
5 Aug 94 13:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06844;
5 Aug 94 13:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12053;
5 Aug 94 13:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06831;
5 Aug 94 13:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06779;
5 Aug 94 13:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-model-00.txt
Date: Fri, 05 Aug 94 13:35:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408051335.aa06779 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
Author(s) : M. Crispin
Filename : draft-ietf-imap-model-00.txt
Pages : 4
Date : 08/04/1994
This memo describes the distributed electronic mail model of IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-model-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07604;
5 Aug 94 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07600;
5 Aug 94 14:25 EDT
Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa13101;
5 Aug 94 14:25 EDT
Received: by mx1.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA25125;
Fri, 5 Aug 94 10:59:15 -0700
Errors-To: owner-imap at cac.washington.edu
X-Orig-Sender: owner-imap at cac.washington.edu
Return-Path: <cclark at CNRI.Reston.VA.US>
Received: from ietf.cnri.reston.va.us by mx1.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA25114;
Fri, 5 Aug 94 10:59:13 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06779;
5 Aug 94 13:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: imap at cac.washington.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-imap-model-00.txt
Date: Fri, 05 Aug 94 13:35:41 -0400
Message-Id: <9408051335.aa06779 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Access
Protocol Working Group of the IETF.
Title : DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
Author(s) : M. Crispin
Filename : draft-ietf-imap-model-00.txt
Pages : 4
Date : 08/04/1994
This memo describes the distributed electronic mail model of IMAP4.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-model-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-imap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-imap-model-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-model-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940804175614.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09467;
5 Aug 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15588;
5 Aug 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09438;
5 Aug 94 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09323;
5 Aug 94 16:15 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15484;
5 Aug 94 16:15 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04470>; Fri, 5 Aug 1994 13:15:23 -0700
Message-Id: <199408052015.AA04470 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1667 on Modeling and Simulation Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:15:50 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1667:
Title: Modeling and Simulation Requirements for IPng
Author: S. Symington, D. Wood & M. Pullen
Mailbox: susan at gateway.mitre.org, wood at mitre.org
mpullen at cs.gmu.edu
Pages: 7
Characters: 17,291
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
The Defense Modeling and Simulation community is a major user of
packet networks and as such has a stake in the definition of IPng.
This white paper summarizes the Distributed Interactive Simulation
environment that is under development, with regard to its real-time
nature, scope and magnitude of networking requirements. The
requirements for real-time response, multicasting, and resource
reservation are set forth, based on our best current understanding of
the future of Defense Modeling and Simulation.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131238.RFC at ISI.EDU>
SEND /rfc/rfc1667.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1667.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131238.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09467;
5 Aug 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15588;
5 Aug 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09438;
5 Aug 94 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09323;
5 Aug 94 16:15 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15484;
5 Aug 94 16:15 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04470>; Fri, 5 Aug 1994 13:15:23 -0700
Message-Id: <199408052015.AA04470 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1667 on Modeling and Simulation Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:15:50 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1667:
Title: Modeling and Simulation Requirements for IPng
Author: S. Symington, D. Wood & M. Pullen
Mailbox: susan at gateway.mitre.org, wood at mitre.org
mpullen at cs.gmu.edu
Pages: 7
Characters: 17,291
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
The Defense Modeling and Simulation community is a major user of
packet networks and as such has a stake in the definition of IPng.
This white paper summarizes the Distributed Interactive Simulation
environment that is under development, with regard to its real-time
nature, scope and magnitude of networking requirements. The
requirements for real-time response, multicasting, and resource
reservation are set forth, based on our best current understanding of
the future of Defense Modeling and Simulation.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131238.RFC at ISI.EDU>
SEND /rfc/rfc1667.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1667.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131238.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09483;
5 Aug 94 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09467;
5 Aug 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15588;
5 Aug 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09438;
5 Aug 94 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09323;
5 Aug 94 16:15 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15484;
5 Aug 94 16:15 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04470>; Fri, 5 Aug 1994 13:15:23 -0700
Message-Id: <199408052015.AA04470 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1667 on Modeling and Simulation Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:15:50 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1667:
Title: Modeling and Simulation Requirements for IPng
Author: S. Symington, D. Wood & M. Pullen
Mailbox: susan at gateway.mitre.org, wood at mitre.org
mpullen at cs.gmu.edu
Pages: 7
Characters: 17,291
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
The Defense Modeling and Simulation community is a major user of
packet networks and as such has a stake in the definition of IPng.
This white paper summarizes the Distributed Interactive Simulation
environment that is under development, with regard to its real-time
nature, scope and magnitude of networking requirements. The
requirements for real-time response, multicasting, and resource
reservation are set forth, based on our best current understanding of
the future of Defense Modeling and Simulation.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131238.RFC at ISI.EDU>
SEND /rfc/rfc1667.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1667.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131238.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09567;
5 Aug 94 16:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15679;
5 Aug 94 16:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09535;
5 Aug 94 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09468;
5 Aug 94 16:18 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15587;
5 Aug 94 16:18 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04558>; Fri, 5 Aug 1994 13:18:30 -0700
Message-Id: <199408052018.AA04558 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1668 on Unified Routing Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:18:59 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1668:
Title: Unified Routing Requirements for IPng
Author: D. Estrin, T. Li & Y. Rekhter
Mailbox: estrin at usc.edu, tli at cisco.com,
yakov at watson.ibm.com
Pages: 3
Characters: 5,106
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131622.RFC at ISI.EDU>
SEND /rfc/rfc1668.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1668.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131622.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09567;
5 Aug 94 16:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15679;
5 Aug 94 16:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09535;
5 Aug 94 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09468;
5 Aug 94 16:18 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15587;
5 Aug 94 16:18 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04558>; Fri, 5 Aug 1994 13:18:30 -0700
Message-Id: <199408052018.AA04558 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1668 on Unified Routing Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:18:59 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1668:
Title: Unified Routing Requirements for IPng
Author: D. Estrin, T. Li & Y. Rekhter
Mailbox: estrin at usc.edu, tli at cisco.com,
yakov at watson.ibm.com
Pages: 3
Characters: 5,106
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131622.RFC at ISI.EDU>
SEND /rfc/rfc1668.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1668.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131622.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09578;
5 Aug 94 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09567;
5 Aug 94 16:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15679;
5 Aug 94 16:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09535;
5 Aug 94 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09468;
5 Aug 94 16:18 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15587;
5 Aug 94 16:18 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04558>; Fri, 5 Aug 1994 13:18:30 -0700
Message-Id: <199408052018.AA04558 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1668 on Unified Routing Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:18:59 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1668:
Title: Unified Routing Requirements for IPng
Author: D. Estrin, T. Li & Y. Rekhter
Mailbox: estrin at usc.edu, tli at cisco.com,
yakov at watson.ibm.com
Pages: 3
Characters: 5,106
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131622.RFC at ISI.EDU>
SEND /rfc/rfc1668.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1668.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131622.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09623;
5 Aug 94 16:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15710;
5 Aug 94 16:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09597;
5 Aug 94 16:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09529;
5 Aug 94 16:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15662;
5 Aug 94 16:20 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04608>; Fri, 5 Aug 1994 13:20:45 -0700
Message-Id: <199408052020.AA04608 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1669 on IPng White Paper on Market Viability
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:21:13 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1669:
Title: Market Viability as a IPng Criteria
Author: J. Curran
Mailbox: jcurran at near.net
Pages: 4
Characters: 8,099
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
In an open marketplace, adoption of new technology is driven by
consumer demand. New technologies that wish to succeed in the
marketplace must provide new capabilities or reduced costs to gain
consumer confidence. Internetworking technologies can be particularly
difficult to deploy and must provide a correspondingly high return on
investment. In order to determine market viability of new
internetworking technology, it's necessary to compare the required
deployment effort against the potential benefits as seen by the
customer. "Viability in the Marketplace" is an important requirement
for any IPng candidate and this paper is an attempt to summarize some
important factors in determing market viability of IPng proposals.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131926.RFC at ISI.EDU>
SEND /rfc/rfc1669.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1669.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131926.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09623;
5 Aug 94 16:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15710;
5 Aug 94 16:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09597;
5 Aug 94 16:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09529;
5 Aug 94 16:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15662;
5 Aug 94 16:20 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04608>; Fri, 5 Aug 1994 13:20:45 -0700
Message-Id: <199408052020.AA04608 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1669 on IPng White Paper on Market Viability
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:21:13 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1669:
Title: Market Viability as a IPng Criteria
Author: J. Curran
Mailbox: jcurran at near.net
Pages: 4
Characters: 8,099
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
In an open marketplace, adoption of new technology is driven by
consumer demand. New technologies that wish to succeed in the
marketplace must provide new capabilities or reduced costs to gain
consumer confidence. Internetworking technologies can be particularly
difficult to deploy and must provide a correspondingly high return on
investment. In order to determine market viability of new
internetworking technology, it's necessary to compare the required
deployment effort against the potential benefits as seen by the
customer. "Viability in the Marketplace" is an important requirement
for any IPng candidate and this paper is an attempt to summarize some
important factors in determing market viability of IPng proposals.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131926.RFC at ISI.EDU>
SEND /rfc/rfc1669.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1669.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131926.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09634;
5 Aug 94 16:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09623;
5 Aug 94 16:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15710;
5 Aug 94 16:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09597;
5 Aug 94 16:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09529;
5 Aug 94 16:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15662;
5 Aug 94 16:20 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04608>; Fri, 5 Aug 1994 13:20:45 -0700
Message-Id: <199408052020.AA04608 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1669 on IPng White Paper on Market Viability
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:21:13 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1669:
Title: Market Viability as a IPng Criteria
Author: J. Curran
Mailbox: jcurran at near.net
Pages: 4
Characters: 8,099
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
In an open marketplace, adoption of new technology is driven by
consumer demand. New technologies that wish to succeed in the
marketplace must provide new capabilities or reduced costs to gain
consumer confidence. Internetworking technologies can be particularly
difficult to deploy and must provide a correspondingly high return on
investment. In order to determine market viability of new
internetworking technology, it's necessary to compare the required
deployment effort against the potential benefits as seen by the
customer. "Viability in the Marketplace" is an important requirement
for any IPng candidate and this paper is an attempt to summarize some
important factors in determing market viability of IPng proposals.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805131926.RFC at ISI.EDU>
SEND /rfc/rfc1669.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1669.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805131926.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09737;
5 Aug 94 16:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15801;
5 Aug 94 16:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09720;
5 Aug 94 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09609;
5 Aug 94 16:23 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15705;
5 Aug 94 16:23 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04637>; Fri, 5 Aug 1994 13:23:34 -0700
Message-Id: <199408052023.AA04637 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1670 on Input to IPng Engineering Considerations
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:24:03 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1670:
Title: Input to IPng Engineering Considerations
Author: D. Heagerty
Mailbox: denise at dxcoms.cern.ch
Pages: 3
Characters: 5,350
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
This white paper expresses some personal opinions on IPng engineering
considerations, based on experience with DECnet Phase V transition.
It suggests breaking down the IPng decisions and transition tasks
into smaller parts so they can be tackled early by the relevant
experts.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132215.RFC at ISI.EDU>
SEND /rfc/rfc1670.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1670.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132215.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09737;
5 Aug 94 16:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15801;
5 Aug 94 16:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09720;
5 Aug 94 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09609;
5 Aug 94 16:23 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15705;
5 Aug 94 16:23 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04637>; Fri, 5 Aug 1994 13:23:34 -0700
Message-Id: <199408052023.AA04637 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1670 on Input to IPng Engineering Considerations
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:24:03 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1670:
Title: Input to IPng Engineering Considerations
Author: D. Heagerty
Mailbox: denise at dxcoms.cern.ch
Pages: 3
Characters: 5,350
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
This white paper expresses some personal opinions on IPng engineering
considerations, based on experience with DECnet Phase V transition.
It suggests breaking down the IPng decisions and transition tasks
into smaller parts so they can be tackled early by the relevant
experts.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132215.RFC at ISI.EDU>
SEND /rfc/rfc1670.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1670.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132215.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09748;
5 Aug 94 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09737;
5 Aug 94 16:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15801;
5 Aug 94 16:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09720;
5 Aug 94 16:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09609;
5 Aug 94 16:23 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15705;
5 Aug 94 16:23 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04637>; Fri, 5 Aug 1994 13:23:34 -0700
Message-Id: <199408052023.AA04637 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1670 on Input to IPng Engineering Considerations
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:24:03 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1670:
Title: Input to IPng Engineering Considerations
Author: D. Heagerty
Mailbox: denise at dxcoms.cern.ch
Pages: 3
Characters: 5,350
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
This white paper expresses some personal opinions on IPng engineering
considerations, based on experience with DECnet Phase V transition.
It suggests breaking down the IPng decisions and transition tasks
into smaller parts so they can be tackled early by the relevant
experts.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132215.RFC at ISI.EDU>
SEND /rfc/rfc1670.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1670.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132215.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09868;
5 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15880;
5 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09856;
5 Aug 94 16:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09783;
5 Aug 94 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15844;
5 Aug 94 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04758>; Fri, 5 Aug 1994 13:27:09 -0700
Message-Id: <199408052027.AA04758 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1671 on IPng White Paper on Transition, etc.
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:27:38 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1671:
Title: IPng White Paper on Transition and Other
Considerations
Author: B. Carpenter
Mailbox: brian at dxcoms.cern.ch
Pages: 8
Characters: 17,631
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This white paper
outlines some general requirements for IPng in selected areas.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132517.RFC at ISI.EDU>
SEND /rfc/rfc1671.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1671.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132517.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09868;
5 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15880;
5 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09856;
5 Aug 94 16:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09783;
5 Aug 94 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15844;
5 Aug 94 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04758>; Fri, 5 Aug 1994 13:27:09 -0700
Message-Id: <199408052027.AA04758 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1671 on IPng White Paper on Transition, etc.
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:27:38 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1671:
Title: IPng White Paper on Transition and Other
Considerations
Author: B. Carpenter
Mailbox: brian at dxcoms.cern.ch
Pages: 8
Characters: 17,631
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This white paper
outlines some general requirements for IPng in selected areas.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132517.RFC at ISI.EDU>
SEND /rfc/rfc1671.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1671.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132517.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09882;
5 Aug 94 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09868;
5 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15880;
5 Aug 94 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09856;
5 Aug 94 16:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09783;
5 Aug 94 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15844;
5 Aug 94 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04758>; Fri, 5 Aug 1994 13:27:09 -0700
Message-Id: <199408052027.AA04758 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1671 on IPng White Paper on Transition, etc.
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:27:38 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1671:
Title: IPng White Paper on Transition and Other
Considerations
Author: B. Carpenter
Mailbox: brian at dxcoms.cern.ch
Pages: 8
Characters: 17,631
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This white paper
outlines some general requirements for IPng in selected areas.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132517.RFC at ISI.EDU>
SEND /rfc/rfc1671.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1671.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132517.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09996;
5 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15974;
5 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09977;
5 Aug 94 16:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09907;
5 Aug 94 16:30 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15928;
5 Aug 94 16:30 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04842>; Fri, 5 Aug 1994 13:30:25 -0700
Message-Id: <199408052030.AA04842 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1672 on Accounting Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:30:54 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1672:
Title: Accounting Requirements for IPng
Author: N. Brownlee
Mailbox: n.brownlee at auckland.ac.nz
Pages: 3
Characters: 6,185
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper discusses accounting requirements for IPng. It
recommends that all IPng packets carry accounting tags, which would
vary in size. In the simplest case a tag would simply be a voucher
identifying the party responsible for the packet. At other times tags
should also carry other higher-level accounting information.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132846.RFC at ISI.EDU>
SEND /rfc/rfc1672.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1672.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132846.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09996;
5 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15974;
5 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09977;
5 Aug 94 16:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09907;
5 Aug 94 16:30 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15928;
5 Aug 94 16:30 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04842>; Fri, 5 Aug 1994 13:30:25 -0700
Message-Id: <199408052030.AA04842 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1672 on Accounting Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:30:54 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1672:
Title: Accounting Requirements for IPng
Author: N. Brownlee
Mailbox: n.brownlee at auckland.ac.nz
Pages: 3
Characters: 6,185
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper discusses accounting requirements for IPng. It
recommends that all IPng packets carry accounting tags, which would
vary in size. In the simplest case a tag would simply be a voucher
identifying the party responsible for the packet. At other times tags
should also carry other higher-level accounting information.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132846.RFC at ISI.EDU>
SEND /rfc/rfc1672.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1672.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132846.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10007;
5 Aug 94 16:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09996;
5 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15974;
5 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09977;
5 Aug 94 16:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09907;
5 Aug 94 16:30 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15928;
5 Aug 94 16:30 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04842>; Fri, 5 Aug 1994 13:30:25 -0700
Message-Id: <199408052030.AA04842 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1672 on Accounting Requirements for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:30:54 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1672:
Title: Accounting Requirements for IPng
Author: N. Brownlee
Mailbox: n.brownlee at auckland.ac.nz
Pages: 3
Characters: 6,185
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper discusses accounting requirements for IPng. It
recommends that all IPng packets carry accounting tags, which would
vary in size. In the simplest case a tag would simply be a voucher
identifying the party responsible for the packet. At other times tags
should also carry other higher-level accounting information.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805132846.RFC at ISI.EDU>
SEND /rfc/rfc1672.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1672.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805132846.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10101;
5 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16149;
5 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10088;
5 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10043;
5 Aug 94 16:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16096;
5 Aug 94 16:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04946>; Fri, 5 Aug 1994 13:34:30 -0700
Message-Id: <199408052034.AA04946 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1673 on EPRI Comments on IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:34:59 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1673:
Title: Electric Power Research Institute Comments on IPng
Author: R. Skelton
Mailbox: RSKELTON at msm.epri.com
Pages: 4
Characters: 7,476
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
The Electric Power Research Institute (EPRI) is a non-profit
organization, with 700 voluntary utility members, managing a technical
research and development program for the electric utility industry to
improve power production, distribution and use. The electric power
industry is a major user of computing and communications and is fully
committed to open systems. The question of the future of the Internet
protocol (IP) is an issue of national if not international concern. It
is critical to the building of a National Information Infrastructure,
comparable to the adoption of basic standards for the industrial era
such as railways, highways and electricity.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133144.RFC at ISI.EDU>
SEND /rfc/rfc1673.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1673.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133144.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10101;
5 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16149;
5 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10088;
5 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10043;
5 Aug 94 16:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16096;
5 Aug 94 16:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04946>; Fri, 5 Aug 1994 13:34:30 -0700
Message-Id: <199408052034.AA04946 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1673 on EPRI Comments on IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:34:59 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1673:
Title: Electric Power Research Institute Comments on IPng
Author: R. Skelton
Mailbox: RSKELTON at msm.epri.com
Pages: 4
Characters: 7,476
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
The Electric Power Research Institute (EPRI) is a non-profit
organization, with 700 voluntary utility members, managing a technical
research and development program for the electric utility industry to
improve power production, distribution and use. The electric power
industry is a major user of computing and communications and is fully
committed to open systems. The question of the future of the Internet
protocol (IP) is an issue of national if not international concern. It
is critical to the building of a National Information Infrastructure,
comparable to the adoption of basic standards for the industrial era
such as railways, highways and electricity.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133144.RFC at ISI.EDU>
SEND /rfc/rfc1673.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1673.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133144.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10118;
5 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10101;
5 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16149;
5 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10088;
5 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10043;
5 Aug 94 16:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16096;
5 Aug 94 16:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA04946>; Fri, 5 Aug 1994 13:34:30 -0700
Message-Id: <199408052034.AA04946 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1673 on EPRI Comments on IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:34:59 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1673:
Title: Electric Power Research Institute Comments on IPng
Author: R. Skelton
Mailbox: RSKELTON at msm.epri.com
Pages: 4
Characters: 7,476
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
The Electric Power Research Institute (EPRI) is a non-profit
organization, with 700 voluntary utility members, managing a technical
research and development program for the electric utility industry to
improve power production, distribution and use. The electric power
industry is a major user of computing and communications and is fully
committed to open systems. The question of the future of the Internet
protocol (IP) is an issue of national if not international concern. It
is critical to the building of a National Information Infrastructure,
comparable to the adoption of basic standards for the industrial era
such as railways, highways and electricity.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133144.RFC at ISI.EDU>
SEND /rfc/rfc1673.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1673.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133144.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10296;
5 Aug 94 16:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16210;
5 Aug 94 16:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10281;
5 Aug 94 16:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10212;
5 Aug 94 16:37 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16182;
5 Aug 94 16:37 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05030>; Fri, 5 Aug 1994 13:38:01 -0700
Message-Id: <199408052038.AA05030 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1674 on A Cellular Industry View of IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:38:29 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1674:
Title: A Cellular Industry View of IPng
Author: M. Taylor
Mailbox: mark.s.taylor at airdata.com
Pages: 3
Characters: 6,157
Updates/Obsoletes: none
This memo is a response to RFC 1550, "IP: Next Generation (IPng) White
Paper Solicitation". The statements in this paper are intended as
input to the technical discussions within IETF, and do not represent
any endorsement or commitment on the part of the cellular industry,
the Cellular Digital Packet Data (CDPD) consortium of service
providers or any of its constituent companies.
This is a memo of the requirements for IPng as envisioned by
representatives of the Cellular Digital Packet Data (CDPD) consortium
of service providers. As the leading service providers for this
nascent technology, which will provide the capability for mobility of
native mainstream connectionless network layer-based applications it
is our intention to support whatever form IPng takes. However, there
are several requirements which we feel IPng must meet.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133527.RFC at ISI.EDU>
SEND /rfc/rfc1674.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1674.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133527.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10296;
5 Aug 94 16:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16210;
5 Aug 94 16:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10281;
5 Aug 94 16:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10212;
5 Aug 94 16:37 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16182;
5 Aug 94 16:37 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05030>; Fri, 5 Aug 1994 13:38:01 -0700
Message-Id: <199408052038.AA05030 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1674 on A Cellular Industry View of IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:38:29 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1674:
Title: A Cellular Industry View of IPng
Author: M. Taylor
Mailbox: mark.s.taylor at airdata.com
Pages: 3
Characters: 6,157
Updates/Obsoletes: none
This memo is a response to RFC 1550, "IP: Next Generation (IPng) White
Paper Solicitation". The statements in this paper are intended as
input to the technical discussions within IETF, and do not represent
any endorsement or commitment on the part of the cellular industry,
the Cellular Digital Packet Data (CDPD) consortium of service
providers or any of its constituent companies.
This is a memo of the requirements for IPng as envisioned by
representatives of the Cellular Digital Packet Data (CDPD) consortium
of service providers. As the leading service providers for this
nascent technology, which will provide the capability for mobility of
native mainstream connectionless network layer-based applications it
is our intention to support whatever form IPng takes. However, there
are several requirements which we feel IPng must meet.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133527.RFC at ISI.EDU>
SEND /rfc/rfc1674.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1674.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133527.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10307;
5 Aug 94 16:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10296;
5 Aug 94 16:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16210;
5 Aug 94 16:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10281;
5 Aug 94 16:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10212;
5 Aug 94 16:37 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16182;
5 Aug 94 16:37 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05030>; Fri, 5 Aug 1994 13:38:01 -0700
Message-Id: <199408052038.AA05030 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1674 on A Cellular Industry View of IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:38:29 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1674:
Title: A Cellular Industry View of IPng
Author: M. Taylor
Mailbox: mark.s.taylor at airdata.com
Pages: 3
Characters: 6,157
Updates/Obsoletes: none
This memo is a response to RFC 1550, "IP: Next Generation (IPng) White
Paper Solicitation". The statements in this paper are intended as
input to the technical discussions within IETF, and do not represent
any endorsement or commitment on the part of the cellular industry,
the Cellular Digital Packet Data (CDPD) consortium of service
providers or any of its constituent companies.
This is a memo of the requirements for IPng as envisioned by
representatives of the Cellular Digital Packet Data (CDPD) consortium
of service providers. As the leading service providers for this
nascent technology, which will provide the capability for mobility of
native mainstream connectionless network layer-based applications it
is our intention to support whatever form IPng takes. However, there
are several requirements which we feel IPng must meet.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133527.RFC at ISI.EDU>
SEND /rfc/rfc1674.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1674.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133527.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10418;
5 Aug 94 16:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16293;
5 Aug 94 16:42 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10397;
5 Aug 94 16:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10338;
5 Aug 94 16:40 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16245;
5 Aug 94 16:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05071>; Fri, 5 Aug 1994 13:40:34 -0700
Message-Id: <199408052040.AA05071 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1675 on Security Concerns for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:41:03 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1675:
Title: Security Concerns for IPng
Author: S. Bellovin
Mailbox: smb at research.att.com
Pages: 4
Characters: 8,290
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
A number of the candidates for IPng have some features that are
somewhat worrisome from a security perspective. While it is not
necessary that IPng be an improvement over IPv4, it is mandatory that
it not make things worse. In this memo, the author outlines a number
of areas of concern. In some cases, there are features that would
have a negative impact on security if nothing else is done. It may be
desirable to adopt the features anyway, but in that case, the
corrective action is mandatory.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133854.RFC at ISI.EDU>
SEND /rfc/rfc1675.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1675.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133854.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10418;
5 Aug 94 16:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16293;
5 Aug 94 16:42 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10397;
5 Aug 94 16:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10338;
5 Aug 94 16:40 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16245;
5 Aug 94 16:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05071>; Fri, 5 Aug 1994 13:40:34 -0700
Message-Id: <199408052040.AA05071 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1675 on Security Concerns for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:41:03 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1675:
Title: Security Concerns for IPng
Author: S. Bellovin
Mailbox: smb at research.att.com
Pages: 4
Characters: 8,290
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
A number of the candidates for IPng have some features that are
somewhat worrisome from a security perspective. While it is not
necessary that IPng be an improvement over IPv4, it is mandatory that
it not make things worse. In this memo, the author outlines a number
of areas of concern. In some cases, there are features that would
have a negative impact on security if nothing else is done. It may be
desirable to adopt the features anyway, but in that case, the
corrective action is mandatory.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133854.RFC at ISI.EDU>
SEND /rfc/rfc1675.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1675.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133854.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10437;
5 Aug 94 16:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10418;
5 Aug 94 16:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16293;
5 Aug 94 16:42 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10397;
5 Aug 94 16:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10338;
5 Aug 94 16:40 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16245;
5 Aug 94 16:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05071>; Fri, 5 Aug 1994 13:40:34 -0700
Message-Id: <199408052040.AA05071 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1675 on Security Concerns for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:41:03 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1675:
Title: Security Concerns for IPng
Author: S. Bellovin
Mailbox: smb at research.att.com
Pages: 4
Characters: 8,290
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
A number of the candidates for IPng have some features that are
somewhat worrisome from a security perspective. While it is not
necessary that IPng be an improvement over IPv4, it is mandatory that
it not make things worse. In this memo, the author outlines a number
of areas of concern. In some cases, there are features that would
have a negative impact on security if nothing else is done. It may be
desirable to adopt the features anyway, but in that case, the
corrective action is mandatory.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805133854.RFC at ISI.EDU>
SEND /rfc/rfc1675.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1675.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805133854.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10643;
5 Aug 94 16:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16417;
5 Aug 94 16:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10632;
5 Aug 94 16:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10536;
5 Aug 94 16:45 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16345;
5 Aug 94 16:45 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05178>; Fri, 5 Aug 1994 13:45:22 -0700
Message-Id: <199408052045.AA05178 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1677 on IPng Tactical RF Requirements
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:45:51 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1677:
Title: Tactical Radio Frequency Communication Requirments
for IPng
Author: B. Adamson
Mailbox: adamson at itd.nrl.navy.mil
Pages: 9
Characters: 24,065
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
This paper describes requirements for Internet Protocol next
generation (IPng) candidates with respect to their application to
military tactical radio frequency (RF) communication networks. The
foundation for these requirements are experiences in the NATO
Communication System Network Interoperability (CSNI) project, the
Naval Research Laboratory Data/Voice Integration Advanced Technology
Demonstration (D/V ATD), and the Navy Communication Support System
(CSS) architecture development.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134352.RFC at ISI.EDU>
SEND /rfc/rfc1677.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1677.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134352.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10643;
5 Aug 94 16:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16417;
5 Aug 94 16:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10632;
5 Aug 94 16:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10536;
5 Aug 94 16:45 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16345;
5 Aug 94 16:45 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05178>; Fri, 5 Aug 1994 13:45:22 -0700
Message-Id: <199408052045.AA05178 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1677 on IPng Tactical RF Requirements
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:45:51 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1677:
Title: Tactical Radio Frequency Communication Requirments
for IPng
Author: B. Adamson
Mailbox: adamson at itd.nrl.navy.mil
Pages: 9
Characters: 24,065
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
This paper describes requirements for Internet Protocol next
generation (IPng) candidates with respect to their application to
military tactical radio frequency (RF) communication networks. The
foundation for these requirements are experiences in the NATO
Communication System Network Interoperability (CSNI) project, the
Naval Research Laboratory Data/Voice Integration Advanced Technology
Demonstration (D/V ATD), and the Navy Communication Support System
(CSS) architecture development.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134352.RFC at ISI.EDU>
SEND /rfc/rfc1677.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1677.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134352.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10655;
5 Aug 94 16:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10643;
5 Aug 94 16:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16417;
5 Aug 94 16:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10632;
5 Aug 94 16:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10536;
5 Aug 94 16:45 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16345;
5 Aug 94 16:45 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05178>; Fri, 5 Aug 1994 13:45:22 -0700
Message-Id: <199408052045.AA05178 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1677 on IPng Tactical RF Requirements
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:45:51 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1677:
Title: Tactical Radio Frequency Communication Requirments
for IPng
Author: B. Adamson
Mailbox: adamson at itd.nrl.navy.mil
Pages: 9
Characters: 24,065
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
This paper describes requirements for Internet Protocol next
generation (IPng) candidates with respect to their application to
military tactical radio frequency (RF) communication networks. The
foundation for these requirements are experiences in the NATO
Communication System Network Interoperability (CSNI) project, the
Naval Research Laboratory Data/Voice Integration Advanced Technology
Demonstration (D/V ATD), and the Navy Communication Support System
(CSS) architecture development.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134352.RFC at ISI.EDU>
SEND /rfc/rfc1677.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1677.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134352.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10766;
5 Aug 94 16:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16543;
5 Aug 94 16:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10755;
5 Aug 94 16:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10681;
5 Aug 94 16:48 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16435;
5 Aug 94 16:48 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05233>; Fri, 5 Aug 1994 13:48:26 -0700
Message-Id: <199408052048.AA05233 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1678 on IPng Requirements of Large Corporate Networks
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:48:55 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1678:
Title: IPng Requirements of Large Corporate Networks
Author: E. Britton & J. Tavs
Mailbox: brittone at vnet.ibm.com, tavs at vnet.ibm.com
Pages: 8
Characters: 18,650
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This memo summarizes
some of the requirements of large corporate networks for the next
generation of the Internet protocol suite.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134614.RFC at ISI.EDU>
SEND /rfc/rfc1678.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1678.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134614.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10766;
5 Aug 94 16:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16543;
5 Aug 94 16:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10755;
5 Aug 94 16:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10681;
5 Aug 94 16:48 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16435;
5 Aug 94 16:48 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05233>; Fri, 5 Aug 1994 13:48:26 -0700
Message-Id: <199408052048.AA05233 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1678 on IPng Requirements of Large Corporate Networks
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:48:55 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1678:
Title: IPng Requirements of Large Corporate Networks
Author: E. Britton & J. Tavs
Mailbox: brittone at vnet.ibm.com, tavs at vnet.ibm.com
Pages: 8
Characters: 18,650
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This memo summarizes
some of the requirements of large corporate networks for the next
generation of the Internet protocol suite.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134614.RFC at ISI.EDU>
SEND /rfc/rfc1678.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1678.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134614.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10777;
5 Aug 94 16:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10766;
5 Aug 94 16:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16543;
5 Aug 94 16:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10755;
5 Aug 94 16:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10681;
5 Aug 94 16:48 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16435;
5 Aug 94 16:48 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05233>; Fri, 5 Aug 1994 13:48:26 -0700
Message-Id: <199408052048.AA05233 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1678 on IPng Requirements of Large Corporate Networks
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:48:55 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1678:
Title: IPng Requirements of Large Corporate Networks
Author: E. Britton & J. Tavs
Mailbox: brittone at vnet.ibm.com, tavs at vnet.ibm.com
Pages: 8
Characters: 18,650
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This memo summarizes
some of the requirements of large corporate networks for the next
generation of the Internet protocol suite.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134614.RFC at ISI.EDU>
SEND /rfc/rfc1678.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1678.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134614.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10855;
5 Aug 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16628;
5 Aug 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10832;
5 Aug 94 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10793;
5 Aug 94 16:51 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16584;
5 Aug 94 16:51 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05276>; Fri, 5 Aug 1994 13:51:28 -0700
Message-Id: <199408052051.AA05276 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1679 on HPN IPng Requirements
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:51:57 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1679:
Title: HPN Working Group Input to the IPng Requirements
Solicitation
Author: D. Green, P. Irey, D. Marlow & K. O'Donoghue
Mailbox: dtgreen at relay.nswc.navy.mil,
pirey at relay.nswc.navy.mil,
dmarlow at relay.nswc.navy.mil,
kodonog at relay.nswc.navy.mil
Pages: 10
Characters: 22,974
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
The Navy's High Performance Network (HPN) working group has been
established to study future network architectures for mission critical
applications aboard Navy platforms. As a result, the HPN working
group is interested in the results of the IPng selection and
development process. This document is a product of discussions within
the HPN working group.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134951.RFC at ISI.EDU>
SEND /rfc/rfc1679.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1679.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134951.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10855;
5 Aug 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16628;
5 Aug 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10832;
5 Aug 94 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10793;
5 Aug 94 16:51 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16584;
5 Aug 94 16:51 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05276>; Fri, 5 Aug 1994 13:51:28 -0700
Message-Id: <199408052051.AA05276 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1679 on HPN IPng Requirements
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:51:57 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1679:
Title: HPN Working Group Input to the IPng Requirements
Solicitation
Author: D. Green, P. Irey, D. Marlow & K. O'Donoghue
Mailbox: dtgreen at relay.nswc.navy.mil,
pirey at relay.nswc.navy.mil,
dmarlow at relay.nswc.navy.mil,
kodonog at relay.nswc.navy.mil
Pages: 10
Characters: 22,974
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
The Navy's High Performance Network (HPN) working group has been
established to study future network architectures for mission critical
applications aboard Navy platforms. As a result, the HPN working
group is interested in the results of the IPng selection and
development process. This document is a product of discussions within
the HPN working group.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134951.RFC at ISI.EDU>
SEND /rfc/rfc1679.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1679.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134951.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10866;
5 Aug 94 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10855;
5 Aug 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16628;
5 Aug 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10832;
5 Aug 94 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10793;
5 Aug 94 16:51 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16584;
5 Aug 94 16:51 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05276>; Fri, 5 Aug 1994 13:51:28 -0700
Message-Id: <199408052051.AA05276 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1679 on HPN IPng Requirements
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:51:57 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1679:
Title: HPN Working Group Input to the IPng Requirements
Solicitation
Author: D. Green, P. Irey, D. Marlow & K. O'Donoghue
Mailbox: dtgreen at relay.nswc.navy.mil,
pirey at relay.nswc.navy.mil,
dmarlow at relay.nswc.navy.mil,
kodonog at relay.nswc.navy.mil
Pages: 10
Characters: 22,974
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
The Navy's High Performance Network (HPN) working group has been
established to study future network architectures for mission critical
applications aboard Navy platforms. As a result, the HPN working
group is interested in the results of the IPng selection and
development process. This document is a product of discussions within
the HPN working group.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805134951.RFC at ISI.EDU>
SEND /rfc/rfc1679.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1679.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805134951.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10953;
5 Aug 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16671;
5 Aug 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10933;
5 Aug 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10839;
5 Aug 94 16:53 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16622;
5 Aug 94 16:53 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05331>; Fri, 5 Aug 1994 13:53:59 -0700
Message-Id: <199408052053.AA05331 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1680 on IPng Support for ATM Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:54:28 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1680:
Title: IPng Support for ATM Services
Author: C. Brazdziunas
Mailbox: crb at faline.bellcore.com
Pages: 7
Characters: 17,846
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper describes engineering considerations for IPng as
solicited by RFC 1550. IPng should provide support for existing and
emerging link technologies that it will be transported over. Link
technologies like Ethernet simply multiplex traffic from upper layer
protocols onto a single channel. "Sophisticated" link technologies
like ATM are emerging in the marketplace allowing several virtual
channels to be established over a single wire (or fiber) potentially
based on an applications' network performance objectives.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805135224.RFC at ISI.EDU>
SEND /rfc/rfc1680.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1680.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805135224.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10953;
5 Aug 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16671;
5 Aug 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10933;
5 Aug 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10839;
5 Aug 94 16:53 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16622;
5 Aug 94 16:53 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05331>; Fri, 5 Aug 1994 13:53:59 -0700
Message-Id: <199408052053.AA05331 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1680 on IPng Support for ATM Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:54:28 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1680:
Title: IPng Support for ATM Services
Author: C. Brazdziunas
Mailbox: crb at faline.bellcore.com
Pages: 7
Characters: 17,846
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper describes engineering considerations for IPng as
solicited by RFC 1550. IPng should provide support for existing and
emerging link technologies that it will be transported over. Link
technologies like Ethernet simply multiplex traffic from upper layer
protocols onto a single channel. "Sophisticated" link technologies
like ATM are emerging in the marketplace allowing several virtual
channels to be established over a single wire (or fiber) potentially
based on an applications' network performance objectives.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805135224.RFC at ISI.EDU>
SEND /rfc/rfc1680.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1680.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805135224.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10964;
5 Aug 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10953;
5 Aug 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16671;
5 Aug 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10933;
5 Aug 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10839;
5 Aug 94 16:53 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16622;
5 Aug 94 16:53 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05331>; Fri, 5 Aug 1994 13:53:59 -0700
Message-Id: <199408052053.AA05331 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1680 on IPng Support for ATM Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:54:28 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1680:
Title: IPng Support for ATM Services
Author: C. Brazdziunas
Mailbox: crb at faline.bellcore.com
Pages: 7
Characters: 17,846
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper describes engineering considerations for IPng as
solicited by RFC 1550. IPng should provide support for existing and
emerging link technologies that it will be transported over. Link
technologies like Ethernet simply multiplex traffic from upper layer
protocols onto a single channel. "Sophisticated" link technologies
like ATM are emerging in the marketplace allowing several virtual
channels to be established over a single wire (or fiber) potentially
based on an applications' network performance objectives.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805135224.RFC at ISI.EDU>
SEND /rfc/rfc1680.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1680.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805135224.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11202;
5 Aug 94 17:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16721;
5 Aug 94 16:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11057;
5 Aug 94 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10988;
5 Aug 94 16:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16697;
5 Aug 94 16:57 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05381>; Fri, 5 Aug 1994 13:57:28 -0700
Message-Id: <199408052057.AA05381 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1681 on On Many Addresses per Host
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:57:56 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1681:
Title: On Many Addresses per Host
Author: S. Bellovin
Mailbox: smb at research.att.com
Pages: 5
Characters: 11,964
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
Currently, most hosts have only one address. With comparatively rare
exceptions, hosts as hosts -- as opposed to hosts acting as routers or
PPP servers -- are single-homed. Our address space calculations
reflect this; we are assuming that we can estimate the size of the
address space by counting hosts. But this may be a serious error.
The author suggests in this memo that that model may -- and should --
change.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805135506.RFC at ISI.EDU>
SEND /rfc/rfc1681.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1681.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805135506.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11202;
5 Aug 94 17:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16721;
5 Aug 94 16:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11057;
5 Aug 94 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10988;
5 Aug 94 16:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16697;
5 Aug 94 16:57 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05381>; Fri, 5 Aug 1994 13:57:28 -0700
Message-Id: <199408052057.AA05381 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1681 on On Many Addresses per Host
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:57:56 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1681:
Title: On Many Addresses per Host
Author: S. Bellovin
Mailbox: smb at research.att.com
Pages: 5
Characters: 11,964
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
Currently, most hosts have only one address. With comparatively rare
exceptions, hosts as hosts -- as opposed to hosts acting as routers or
PPP servers -- are single-homed. Our address space calculations
reflect this; we are assuming that we can estimate the size of the
address space by counting hosts. But this may be a serious error.
The author suggests in this memo that that model may -- and should --
change.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805135506.RFC at ISI.EDU>
SEND /rfc/rfc1681.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1681.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805135506.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11213;
5 Aug 94 17:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11202;
5 Aug 94 17:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16721;
5 Aug 94 16:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11057;
5 Aug 94 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10988;
5 Aug 94 16:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16697;
5 Aug 94 16:57 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05381>; Fri, 5 Aug 1994 13:57:28 -0700
Message-Id: <199408052057.AA05381 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1681 on On Many Addresses per Host
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 05 Aug 94 13:57:56 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1681:
Title: On Many Addresses per Host
Author: S. Bellovin
Mailbox: smb at research.att.com
Pages: 5
Characters: 11,964
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list.
Currently, most hosts have only one address. With comparatively rare
exceptions, hosts as hosts -- as opposed to hosts acting as routers or
PPP servers -- are single-homed. Our address space calculations
reflect this; we are assuming that we can estimate the size of the
address space by counting hosts. But this may be a serious error.
The author suggests in this memo that that model may -- and should --
change.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940805135506.RFC at ISI.EDU>
SEND /rfc/rfc1681.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1681.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940805135506.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05020;
6 Aug 94 17:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05016;
6 Aug 94 17:33 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa09980;
6 Aug 94 17:33 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.8.1/1.2)
id PAA03488; Sat, 6 Aug 1994 15:33:11 -0600
Received: by noc-gw.lanl.gov (8.6.8.1/SMI-4.1)
id PAA24196; Sat, 6 Aug 1994 15:32:23 -0600
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.8.1/SMI-4.1)
id PAA24193; Sat, 6 Aug 1994 15:32:22 -0600
Received: from feta.cisco.com by mailhost.lanl.gov (8.6.8.1/1.2)
id PAA03478; Sat, 6 Aug 1994 15:32:24 -0600
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA13564; Sat, 6 Aug 1994 14:32:28 -0700
Date: Sat, 6 Aug 1994 14:32:28 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408062132.OAA13564 at feta.cisco.com>
To: ietf at CNRI.Reston.VA.US
Cc: sipp at sunroof.eng.sun.com, ipng at sunroof.eng.sun.com, tuba at lanl.gov,
catnip at world.std.com
Subject: IPng Address Autoconfiguration Mailing List
Apologies in advance for the cross-posting.
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of
the formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05042;
6 Aug 94 17:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05038;
6 Aug 94 17:34 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa09998; 6 Aug 94 17:34 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA13655; Sat, 6 Aug 94 14:33:13 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA03837; Sat, 6 Aug 94 14:33:24 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA07386; Sat, 6 Aug 94 14:35:24 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA07380; Sat, 6 Aug 94 14:35:17 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1)
id AA21312; Sat, 6 Aug 94 14:32:46 PDT
Received: from feta.cisco.com by Sun.COM (sun-barr.Sun.COM)
id AA13634; Sat, 6 Aug 94 14:32:37 PDT
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA13564; Sat, 6 Aug 1994 14:32:28 -0700
Date: Sat, 6 Aug 1994 14:32:28 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408062132.OAA13564 at feta.cisco.com>
To: ietf at CNRI.Reston.VA.US
Cc: sipp at sunroof.eng.sun.com, ipng at sunroof.eng.sun.com, tuba at lanl.gov,
catnip at world.std.com
Subject: (sipp) IPng Address Autoconfiguration Mailing List
X-Orig-Sender: owner-sipp at sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp at sunroof.eng.sun.com
Apologies in advance for the cross-posting.
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of
the formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
------------------------------------------------------------------------------
IETF SIPP Working Group - Archives: parcftp.xerox.com:/pub/sipp
Unsubscribe: unsubscribe sipp (as message body, not subject)
Direct all administrative requests to majordomo at sunroof.eng.sun.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05082;
6 Aug 94 17:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05078;
6 Aug 94 17:39 EDT
Received: from ftp.std.com by CNRI.Reston.VA.US id aa10060; 6 Aug 94 17:39 EDT
Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0)
id RAA07475; Sat, 6 Aug 1994 17:36:21 -0400
Received: by world.std.com (5.65c/Spike-2.0)
id AA10820; Sat, 6 Aug 1994 17:32:24 -0400
Errors-To: catnip-request at world.std.com
X-Orig-Sender: catnip-request at world.std.com
Reply-To: catnip at world.std.com
Precedence: bulk
Received: from feta.cisco.com by world.std.com (5.65c/Spike-2.0)
id AA10813; Sat, 6 Aug 1994 17:32:23 -0400
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA13564; Sat, 6 Aug 1994 14:32:28 -0700
Date: Sat, 6 Aug 1994 14:32:28 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408062132.OAA13564 at feta.cisco.com>
To: ietf at CNRI.Reston.VA.US
Cc: sipp at sunroof.eng.sun.com, ipng at sunroof.eng.sun.com, tuba at lanl.gov,
catnip at world.std.com
Subject: IPng Address Autoconfiguration Mailing List
Apologies in advance for the cross-posting.
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of
the formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05147;
6 Aug 94 17:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05137;
6 Aug 94 17:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10138;
6 Aug 94 17:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05117;
6 Aug 94 17:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05006;
6 Aug 94 17:31 EDT
Received: from feta.cisco.com by CNRI.Reston.VA.US id aa09960;
6 Aug 94 17:31 EDT
Received: (dkatz at localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA13564; Sat, 6 Aug 1994 14:32:28 -0700
Date: Sat, 6 Aug 1994 14:32:28 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199408062132.OAA13564 at feta.cisco.com>
To: ietf at CNRI.Reston.VA.US
Cc: sipp at sunroof.eng.sun.com, ipng at sunroof.eng.sun.com, tuba at lanl.gov,
catnip at world.std.com
Subject: IPng Address Autoconfiguration Mailing List
Apologies in advance for the cross-posting.
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of
the formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06106;
7 Aug 94 20:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13792;
7 Aug 94 20:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06025;
7 Aug 94 20:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05691;
7 Aug 94 19:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13392;
7 Aug 94 19:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05686;
7 Aug 94 19:59 EDT
To: IETF-Announce: ;
cc: minutes at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: minutes at CNRI.Reston.VA.US
Subject: July IETF: On-line Minutes
Date: Sun, 07 Aug 94 19:59:20 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9408071959.aa05686 at IETF.CNRI.Reston.VA.US>
Below is a list of minutes and arrea reports from the July IETF which
will be available from the IETF remote directories tomorrow.
Debra
========
July IETF Area Reports
----------------------
94jul/area.netmanagement.94jul.txt
94jul/area.security.94jul.txt
94jul/area.userservices.94jul.txt
July IETF Minutes
-----------------
94jul/acct2-minutes-94jul.txt
94jul/fibreip-minutes-94jul.txt
94jul/printjob-minutes-94jul.txt
94jul/ssh-minutes-94jul.txt
94jul/tacit-minutes-94jul.txt
94jul/testing-minutes-94jul.txt
dnssec/dnssec-minutes-94jul.txt
gisd/gisd-minutes-94jul.txt
idmr/idmr-minutes-94jul.txt
ifmib/ifmib-minutes-94jul.txt
imap/imap-minutes-94jul.txt
ipatm/ipatm-minutes-94jul.txt
isis/isis-minutes-94jul.txt
opstat/opstat-minutes-94jul.txt
pem/pem-minutes-94jul.txt
ripv2/ripv2-minutes-94jul.txt
rmonmib/rmonmib-minutes-94jul.txt
sdr/sdr-minutes-94jul.txt
uri/uri-minutes-94jul.txt
whip/whip-minutes-94jul.txt
wnils/wnils-minutes-94jul.txt
Interim Minutes
---------------
printmib/printmib-minutes-94apr.txt
printmib/printmib-minutes-94jun.txt
snanau/snanau-minutes-94jun.txt
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06106;
7 Aug 94 20:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13792;
7 Aug 94 20:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06025;
7 Aug 94 20:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05691;
7 Aug 94 19:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13392;
7 Aug 94 19:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05686;
7 Aug 94 19:59 EDT
To: IETF-Announce: ;
cc: minutes at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: minutes at CNRI.Reston.VA.US
Subject: July IETF: On-line Minutes
Date: Sun, 07 Aug 94 19:59:20 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9408071959.aa05686 at IETF.CNRI.Reston.VA.US>
Below is a list of minutes and arrea reports from the July IETF which
will be available from the IETF remote directories tomorrow.
Debra
========
July IETF Area Reports
----------------------
94jul/area.netmanagement.94jul.txt
94jul/area.security.94jul.txt
94jul/area.userservices.94jul.txt
July IETF Minutes
-----------------
94jul/acct2-minutes-94jul.txt
94jul/fibreip-minutes-94jul.txt
94jul/printjob-minutes-94jul.txt
94jul/ssh-minutes-94jul.txt
94jul/tacit-minutes-94jul.txt
94jul/testing-minutes-94jul.txt
dnssec/dnssec-minutes-94jul.txt
gisd/gisd-minutes-94jul.txt
idmr/idmr-minutes-94jul.txt
ifmib/ifmib-minutes-94jul.txt
imap/imap-minutes-94jul.txt
ipatm/ipatm-minutes-94jul.txt
isis/isis-minutes-94jul.txt
opstat/opstat-minutes-94jul.txt
pem/pem-minutes-94jul.txt
ripv2/ripv2-minutes-94jul.txt
rmonmib/rmonmib-minutes-94jul.txt
sdr/sdr-minutes-94jul.txt
uri/uri-minutes-94jul.txt
whip/whip-minutes-94jul.txt
wnils/wnils-minutes-94jul.txt
Interim Minutes
---------------
printmib/printmib-minutes-94apr.txt
printmib/printmib-minutes-94jun.txt
snanau/snanau-minutes-94jun.txt
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06117;
7 Aug 94 20:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06106;
7 Aug 94 20:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13792;
7 Aug 94 20:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06025;
7 Aug 94 20:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05691;
7 Aug 94 19:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13392;
7 Aug 94 19:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05686;
7 Aug 94 19:59 EDT
To: IETF-Announce: ;
cc: minutes at CNRI.Reston.VA.US
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: minutes at CNRI.Reston.VA.US
Subject: July IETF: On-line Minutes
Date: Sun, 07 Aug 94 19:59:20 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9408071959.aa05686 at IETF.CNRI.Reston.VA.US>
Below is a list of minutes and arrea reports from the July IETF which
will be available from the IETF remote directories tomorrow.
Debra
========
July IETF Area Reports
----------------------
94jul/area.netmanagement.94jul.txt
94jul/area.security.94jul.txt
94jul/area.userservices.94jul.txt
July IETF Minutes
-----------------
94jul/acct2-minutes-94jul.txt
94jul/fibreip-minutes-94jul.txt
94jul/printjob-minutes-94jul.txt
94jul/ssh-minutes-94jul.txt
94jul/tacit-minutes-94jul.txt
94jul/testing-minutes-94jul.txt
dnssec/dnssec-minutes-94jul.txt
gisd/gisd-minutes-94jul.txt
idmr/idmr-minutes-94jul.txt
ifmib/ifmib-minutes-94jul.txt
imap/imap-minutes-94jul.txt
ipatm/ipatm-minutes-94jul.txt
isis/isis-minutes-94jul.txt
opstat/opstat-minutes-94jul.txt
pem/pem-minutes-94jul.txt
ripv2/ripv2-minutes-94jul.txt
rmonmib/rmonmib-minutes-94jul.txt
sdr/sdr-minutes-94jul.txt
uri/uri-minutes-94jul.txt
whip/whip-minutes-94jul.txt
wnils/wnils-minutes-94jul.txt
Interim Minutes
---------------
printmib/printmib-minutes-94apr.txt
printmib/printmib-minutes-94jun.txt
snanau/snanau-minutes-94jun.txt
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02324;
8 Aug 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05336;
8 Aug 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02287;
8 Aug 94 9:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01928;
8 Aug 94 8:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04668;
8 Aug 94 8:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01923;
8 Aug 94 8:49 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Subject: IPng Address Autoconfiguration Mailing List
Date: Mon, 08 Aug 94 08:49:12 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408080849.aa01923 at IETF.CNRI.Reston.VA.US>
[Sorry for those of you who receive duplicates -- this is being re-sent
to the IETF-Announce list.]
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of the
formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02324;
8 Aug 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05336;
8 Aug 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02287;
8 Aug 94 9:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01928;
8 Aug 94 8:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04668;
8 Aug 94 8:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01923;
8 Aug 94 8:49 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Subject: IPng Address Autoconfiguration Mailing List
Date: Mon, 08 Aug 94 08:49:12 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408080849.aa01923 at IETF.CNRI.Reston.VA.US>
[Sorry for those of you who receive duplicates -- this is being re-sent
to the IETF-Announce list.]
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of the
formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02335;
8 Aug 94 9:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02324;
8 Aug 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05336;
8 Aug 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02287;
8 Aug 94 9:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01928;
8 Aug 94 8:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04668;
8 Aug 94 8:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01923;
8 Aug 94 8:49 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Subject: IPng Address Autoconfiguration Mailing List
Date: Mon, 08 Aug 94 08:49:12 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408080849.aa01923 at IETF.CNRI.Reston.VA.US>
[Sorry for those of you who receive duplicates -- this is being re-sent
to the IETF-Announce list.]
Following the Address Autoconfiguration BOF at the recent IETF meeting
in Toronto, a mailing list has been established in anticipation of the
formation of an IETF working group. The anticipated scope of this
group will be to specify a dynamic network address administration
architecture and protocol for IPv6.
The mailing list is:
addrconf at cisco.com
The request list is:
addrconf-request at cisco.com
Those of you who attended the BOF in Toronto and *did not* receive a
"welcome" message on the mailing list, please send a message to the
request list above. I was unable to read all of the email addresses
on the attendance list (and deleted several addresses that I thought
I could read, but that generated mail bounces).
-- Dave Katz (dkatz at cisco.com)
Sue Thomson (set at thumper.bellcore.com)
co-chairs
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05372;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13555;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05339;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05164;
8 Aug 94 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-lang-tag-00.txt
Date: Mon, 08 Aug 94 11:49:05 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081149.aa05164 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : Tags for the identification of languages
Author(s) : H. Alvestrand
Filename : draft-ietf-mailext-lang-tag-00.txt
Pages : 12
Date : 08/05/1994
This document describes a language tag for use in cases where it is desired
to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case
where one desires to indicate the language of something that
has RFC-822-like headers, like MIME body parts or Web documents,
and a new parameter to the Multipart/Alternative type, to aid in the
usage of the Content-Language: header.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-lang-tag-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-lang-tag-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805134356.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-lang-tag-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-lang-tag-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805134356.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05372;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13555;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05339;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05164;
8 Aug 94 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-lang-tag-00.txt
Date: Mon, 08 Aug 94 11:49:05 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081149.aa05164 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : Tags for the identification of languages
Author(s) : H. Alvestrand
Filename : draft-ietf-mailext-lang-tag-00.txt
Pages : 12
Date : 08/05/1994
This document describes a language tag for use in cases where it is desired
to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case
where one desires to indicate the language of something that
has RFC-822-like headers, like MIME body parts or Web documents,
and a new parameter to the Multipart/Alternative type, to aid in the
usage of the Content-Language: header.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-lang-tag-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-lang-tag-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805134356.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-lang-tag-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-lang-tag-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805134356.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05378;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13560;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05338;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05121;
8 Aug 94 11:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-05.txt
Date: Mon, 08 Aug 94 11:48:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081148.aa05121 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-05.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05378;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13560;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05338;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05121;
8 Aug 94 11:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-05.txt
Date: Mon, 08 Aug 94 11:48:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081148.aa05121 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-05.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05398;
8 Aug 94 11:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05372;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13555;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05339;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05164;
8 Aug 94 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-lang-tag-00.txt
Date: Mon, 08 Aug 94 11:49:05 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081149.aa05164 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : Tags for the identification of languages
Author(s) : H. Alvestrand
Filename : draft-ietf-mailext-lang-tag-00.txt
Pages : 12
Date : 08/05/1994
This document describes a language tag for use in cases where it is desired
to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case
where one desires to indicate the language of something that
has RFC-822-like headers, like MIME body parts or Web documents,
and a new parameter to the Multipart/Alternative type, to aid in the
usage of the Content-Language: header.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-lang-tag-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-lang-tag-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805134356.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-lang-tag-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-lang-tag-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805134356.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05391;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13601;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05342;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05235;
8 Aug 94 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-onions-x400p772-822-mapping-02.txt
Date: Mon, 08 Aug 94 11:49:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081149.aa05235 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mapping between X.400 P772 and RFC-822
Author(s) : G. Lunt, J. Onions
Filename : draft-onions-x400p772-822-mapping-02.txt
Pages : 7
Date : 08/05/1994
This document describes a method for allowing the exchange of P772 military
X.400 mail with RFC-822 text based mail. This allows gateways to convert
between the two provided certain criteria are met.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-onions-x400p772-822-mapping-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-onions-x400p772-822-mapping-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805135843.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-onions-x400p772-822-mapping-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-onions-x400p772-822-mapping-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805135843.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05391;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13601;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05342;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05235;
8 Aug 94 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-onions-x400p772-822-mapping-02.txt
Date: Mon, 08 Aug 94 11:49:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081149.aa05235 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mapping between X.400 P772 and RFC-822
Author(s) : G. Lunt, J. Onions
Filename : draft-onions-x400p772-822-mapping-02.txt
Pages : 7
Date : 08/05/1994
This document describes a method for allowing the exchange of P772 military
X.400 mail with RFC-822 text based mail. This allows gateways to convert
between the two provided certain criteria are met.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-onions-x400p772-822-mapping-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-onions-x400p772-822-mapping-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805135843.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-onions-x400p772-822-mapping-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-onions-x400p772-822-mapping-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805135843.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05404;
8 Aug 94 11:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05378;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13560;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05338;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05121;
8 Aug 94 11:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-05.txt
Date: Mon, 08 Aug 94 11:48:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081148.aa05121 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-05.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05426;
8 Aug 94 11:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05391;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13601;
8 Aug 94 11:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05342;
8 Aug 94 11:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05235;
8 Aug 94 11:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-onions-x400p772-822-mapping-02.txt
Date: Mon, 08 Aug 94 11:49:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408081149.aa05235 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Mapping between X.400 P772 and RFC-822
Author(s) : G. Lunt, J. Onions
Filename : draft-onions-x400p772-822-mapping-02.txt
Pages : 7
Date : 08/05/1994
This document describes a method for allowing the exchange of P772 military
X.400 mail with RFC-822 text based mail. This allows gateways to convert
between the two provided certain criteria are met.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-onions-x400p772-822-mapping-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-onions-x400p772-822-mapping-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805135843.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-onions-x400p772-822-mapping-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-onions-x400p772-822-mapping-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805135843.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06624;
8 Aug 94 13:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06620;
8 Aug 94 13:18 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa25521;
8 Aug 94 13:18 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA08472 on Mon, 8 Aug 94 11:55:19 -0400
Received: from ietf.cnri.reston.va.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA08468 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Mon, 8 Aug 94 11:55:13 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05121;
8 Aug 94 11:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: uri at bunyip.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-05.txt
Date: Mon, 08 Aug 94 11:48:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408081148.aa05121 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-05.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940805133434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09802;
8 Aug 94 16:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09794;
8 Aug 94 16:20 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa29303;
8 Aug 94 16:20 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA09770 at pad-thai.aktis.com>; Mon, 8 Aug 1994 15:53:28 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vipin.Samar at eng.sun.com
Received: from Sun.COM by MIT.EDU with SMTP
id AA14386; Mon, 8 Aug 94 15:52:06 EDT
Received: from Eng.Sun.COM (mxchange.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA05941; Mon, 8 Aug 94 12:52:01 PDT
Received: from jurassic.Eng.Sun.COM by Eng.Sun.COM (8.6.9/SMI-4.1)
id MAA19703; Mon, 8 Aug 1994 12:52:03 -0700
Received: from tiny.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4)
id AA05650; Mon, 8 Aug 1994 12:52:03 -0700
Received: by tiny.Eng.Sun.COM (5.x/SMI-SVR4)
id AA08845; Mon, 8 Aug 1994 12:52:41 -0700
Date: Mon, 8 Aug 1994 12:52:41 -0700
Message-Id: <9408081952.AA08845 at tiny.Eng.Sun.COM>
To: wray at tuxedo.enet.dec.com
Subject: RE: buffer mgmt and performance issues
Cc: cat-ietf at mit.edu
X-Sun-Charset: US-ASCII
>
>If I understand you correctly, wouldn't this technique require that the
>application know the size of the signature block before it calls gss_sign(), so
>that it knows how much room to leave for it before the start of the data? Or
>are you going to put the data into the output buffer after the signature's been
>calculated? If so, then you're willing to copy the data instead of the
>signature (which will typically be short - on the order of tens of bytes), so
>you might consider using gss_seal instead of gss_sign, as that's exactly what
>gss_seal does.
The structure inside the packet that would be sent out could be
organized in many different way. Here is one:
-------------------------------------------------------------------
|data len | Data | digest_len | signed digest |
--------------------------------------------------------------------
The buffers that I would pass to gss_sign() would be pointers to
appropriate location from the above packet. When gss_sign() returns,
I would then stuff in the digest_len field accordingly. Note that there
is no copying required. One of the problems as you noted is that the
application would have to know the length of the signed digest to able to
preallocate the buffer. One could either use a big buffer, or find this
data through some other OOB means.
Basically, what I am asking is for gss_sign() to extend the interpretation
of the output buffer. i.e. if the len field is non-zero, assume that
the buffer is already preallocated. If the given length is not sufficient,
then return GSS_S_TOO_SMALL error. if the len field is zero, then
it is life as usual. I know this will not save much in the grand scheme
of things, but every bit helps.
vipin
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12711;
8 Aug 94 19:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03242;
8 Aug 94 19:16 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12693;
8 Aug 94 19:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12606;
8 Aug 94 19:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03118;
8 Aug 94 19:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12601;
8 Aug 94 19:10 EDT
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: IMAP4 to Proposed Standard
Date: Mon, 08 Aug 94 19:10:36 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408081910.aa12601 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Internet Message Access
Protocol Working Group to consider:
o "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4"
<draft-ietf-imap-imap4-05.txt>
o "IMAP4 Authentication mechanisms" <draft-ietf-imap-auth-01.txt>
for the status of Proposed Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS"
<draft-ietf-imap-compat-00.txt>
o "DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4"
<draft-ietf-imap-model-00.txt>
be published as Informational RFCs.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12711;
8 Aug 94 19:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03242;
8 Aug 94 19:16 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12693;
8 Aug 94 19:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12606;
8 Aug 94 19:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03118;
8 Aug 94 19:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12601;
8 Aug 94 19:10 EDT
To: IETF-Announce: ;
cc: imap at cac.washington.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: IMAP4 to Proposed Standard
Date: Mon, 08 Aug 94 19:10:36 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408081910.aa12601 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Internet Message Access
Protocol Working Group to consider:
o "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4"
<draft-ietf-imap-imap4-05.txt>
o "IMAP4 Authentication mechanisms" <draft-ietf-imap-auth-01.txt>
for the status of Proposed Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS"
<draft-ietf-imap-compat-00.txt>
o "DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4"
<draft-ietf-imap-model-00.txt>
be published as Informational RFCs.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12727;
8 Aug 94 19:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12711;
8 Aug 94 19:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03242;
8 Aug 94 19:16 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12693;
8 Aug 94 19:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12606;
8 Aug 94 19:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03118;
8 Aug 94 19:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12601;
8 Aug 94 19:10 EDT
To: IETF-Announce: ;
cc: imap at cac.washington.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: IMAP4 to Proposed Standard
Date: Mon, 08 Aug 94 19:10:36 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408081910.aa12601 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Internet Message Access
Protocol Working Group to consider:
o "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4"
<draft-ietf-imap-imap4-05.txt>
o "IMAP4 Authentication mechanisms" <draft-ietf-imap-auth-01.txt>
for the status of Proposed Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS"
<draft-ietf-imap-compat-00.txt>
o "DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4"
<draft-ietf-imap-model-00.txt>
be published as Informational RFCs.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13251;
8 Aug 94 19:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13247;
8 Aug 94 19:31 EDT
Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa03546;
8 Aug 94 19:31 EDT
Received: by mx1.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA12610;
Mon, 8 Aug 94 16:11:27 -0700
Errors-To: owner-imap at cac.washington.edu
X-Orig-Sender: owner-imap at cac.washington.edu
Return-Path: <jstewart at CNRI.Reston.VA.US>
Received: from ietf.cnri.reston.va.us by mx1.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA12604;
Mon, 8 Aug 94 16:11:24 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12601;
8 Aug 94 19:10 EDT
To: IETF-Announce: ;
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: imap at cac.washington.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: IMAP4 to Proposed Standard
Date: Mon, 08 Aug 94 19:10:36 -0400
Message-Id: <9408081910.aa12601 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Internet Message Access
Protocol Working Group to consider:
o "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4"
<draft-ietf-imap-imap4-05.txt>
o "IMAP4 Authentication mechanisms" <draft-ietf-imap-auth-01.txt>
for the status of Proposed Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS"
<draft-ietf-imap-compat-00.txt>
o "DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4"
<draft-ietf-imap-model-00.txt>
be published as Informational RFCs.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13337;
8 Aug 94 19:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03604;
8 Aug 94 19:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13319;
8 Aug 94 19:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13239;
8 Aug 94 19:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03536;
8 Aug 94 19:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13232;
8 Aug 94 19:30 EDT
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: RIP Version 2 to Draft Standard
Date: Mon, 08 Aug 94 19:30:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408081930.aa13232 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the RIP Version II Working Group
to consider advancing:
o "RIP Version 2 MIB Extension" <draft-ietf-ripv2-mibext2-02.txt>
o "RIP Version 2 Protocol Applicability Statement"
<draft-ietf-ripv2-protocol-applic-01.txt>
o "RIP Version 2 Carrying Additional Information"
<draft-ietf-ripv2-protocol-01.txt>
to the status of Draft Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "RIP Version 2 Protocol Analysis" for the status of Informational.
<draft-ietf-ripv2-protocol-analysis-01.txt>
be published as an Informational RFC.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13337;
8 Aug 94 19:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03604;
8 Aug 94 19:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13319;
8 Aug 94 19:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13239;
8 Aug 94 19:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03536;
8 Aug 94 19:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13232;
8 Aug 94 19:30 EDT
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: RIP Version 2 to Draft Standard
Date: Mon, 08 Aug 94 19:30:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408081930.aa13232 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the RIP Version II Working Group
to consider advancing:
o "RIP Version 2 MIB Extension" <draft-ietf-ripv2-mibext2-02.txt>
o "RIP Version 2 Protocol Applicability Statement"
<draft-ietf-ripv2-protocol-applic-01.txt>
o "RIP Version 2 Carrying Additional Information"
<draft-ietf-ripv2-protocol-01.txt>
to the status of Draft Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "RIP Version 2 Protocol Analysis" for the status of Informational.
<draft-ietf-ripv2-protocol-analysis-01.txt>
be published as an Informational RFC.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13348;
8 Aug 94 19:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13337;
8 Aug 94 19:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03604;
8 Aug 94 19:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13319;
8 Aug 94 19:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13239;
8 Aug 94 19:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03536;
8 Aug 94 19:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13232;
8 Aug 94 19:30 EDT
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: RIP Version 2 to Draft Standard
Date: Mon, 08 Aug 94 19:30:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408081930.aa13232 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the RIP Version II Working Group
to consider advancing:
o "RIP Version 2 MIB Extension" <draft-ietf-ripv2-mibext2-02.txt>
o "RIP Version 2 Protocol Applicability Statement"
<draft-ietf-ripv2-protocol-applic-01.txt>
o "RIP Version 2 Carrying Additional Information"
<draft-ietf-ripv2-protocol-01.txt>
to the status of Draft Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "RIP Version 2 Protocol Analysis" for the status of Informational.
<draft-ietf-ripv2-protocol-analysis-01.txt>
be published as an Informational RFC.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13433;
8 Aug 94 19:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13429;
8 Aug 94 19:38 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa03705;
8 Aug 94 19:38 EDT
Received: by atlas.xylogics.com id AA04196 (5.65c/UK-2.1-940401);
Mon, 8 Aug 1994 19:40:04 -0400
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by atlas.xylogics.com with SMTP
id AA02878 (5.65c/UK-2.1-940401); Mon, 8 Aug 1994 19:39:55 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13232;
8 Aug 94 19:30 EDT
To: IETF-Announce: @cnri.reston.va.us:;
Cc: ietf-rip at xylogics.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: RIP Version 2 to Draft Standard
Date: Mon, 08 Aug 94 19:30:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-Id: <9408081930.aa13232 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the RIP Version II Working Group
to consider advancing:
o "RIP Version 2 MIB Extension" <draft-ietf-ripv2-mibext2-02.txt>
o "RIP Version 2 Protocol Applicability Statement"
<draft-ietf-ripv2-protocol-applic-01.txt>
o "RIP Version 2 Carrying Additional Information"
<draft-ietf-ripv2-protocol-01.txt>
to the status of Draft Standard. They have also asked the IESG to
consider recommending to the RFC Editor that:
o "RIP Version 2 Protocol Analysis" for the status of Informational.
<draft-ietf-ripv2-protocol-analysis-01.txt>
be published as an Informational RFC.
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 cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
22 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02049;
9 Aug 94 7:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02041;
9 Aug 94 7:22 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa03870;
9 Aug 94 7:22 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <GAA25022 at pad-thai.aktis.com>; Tue, 9 Aug 1994 06:53:18 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA16337; Tue, 9 Aug 94 06:51:48 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <03942-0 at relay1.pipex.net>; Tue, 9 Aug 1994 11:51:16 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA13604; Tue, 9 Aug 94 11:54:00 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA17322;
Tue, 9 Aug 94 11:49:51 BST
Message-Id: <9408091052.AA09717 at getafix.oasis.icl.co.uk>
Date: Tue, 9 Aug 94 11:52:24 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Windows 3.1 client GSS-API
To: cat-ietf at mit.edu
CAT WG,
We have been porting SESAME mechanism client-code to MS Windows 3.1 and
had to resolve some GSS-API interface issues which may be of wider community
interest (for the GSS-API Base RFC 1508 / 1509 anyway).
I have attached a note below which lists the subset being implemented.
Sections 1 and 2 are of more general interest than the rest.
If there is wider interest in this area, I would like to focus discussion on
three points:
A. Windows GSS-API
Given the installed base, it would seem to be very desirable to converge on
source-level compatibility (at least) between different MS Windows
implementations.
Would anyone have objections to the general approach outlined in
section 1 (and its output in section 2)? It would be desirable to
have an agreed set of prototypes so that MS Windows security-consuming
applications can be written portably - or at least an agreed set
of rules if they can be trivially applied to RFC1509.
B. GSS-API Binding Conformance
By default the approach for GSS-API implementation would be to
implement all calls, but return errors for those functions which
aren't supported.
On clients, this would be possible, but support for
gss_acquire_cred and gss_accept_context seems unnecessary on this
kind of client (whether or not dummy interface routines are present).
It doesn't seem to be of value to be required to support APIs
which are only of use in servers. An agreed client subset would
be desirable.
C. GSS-API Functional Conformance
On a related point, what is the minimum conformance subset for
GSS-API functionality such that conformance should be claimable?
Support for the C prototypes and adherence to Appendix B/C of
RFC-1508 are one measure of conformance - but they don't imply that
the implementation/mechanism has to even support authentication ...
Unless there is very good reason not to, I would suggest that
the minimum support be specified as one-way authentication,
per-message integrity, sequence, and replay protection.
Comments?
Piers
----
GSS-API C Bindings for MS Windows 3.1
Draft 0.2
ses/940716a
pvm
Contents List
1. Introduction
2. GSS-API Base Bindings
2.1 Summary
2.2 Entry Points
2.3 Exported Generic Data Structures
2.4 Exported Implementation-defined Data Structures
3. GSS-API Security Attribute and Delegation Bindings
3.1 Summary
3.2 Entry Points
3.3 Exported Data Structures
4. GSS-API Provider Encapsulation Bindings
4.1 Summary
4.2 Entry Points
1. Introduction
There are difficulties in using the UNIX GSS-API C bindings in a
MS Windows 3.1 environment where the underlying segmented addressing
mechanism can be exposed to the application programmer, and valid
assumptions about pointers for UNIX break down.
As a solution to this problem, this note describes the modified GSS-API
prototypes for the relevant PC client subset used for this environment.
In most cases this just requires the mechanistic addition of the
necessary directive keywords for the MS development environment.
Note that as the GSS-API library is implemented in a DLL, all pointers
passed to it from calling applications must be declared FAR. This
applies to all parts of the interfaces - both entry points and data
structures.
2. GSS-API Base Bindings
2.1 Summary
This section lists all GSSAPI Base bindings required for the PC client.
2.2 Entry Points
OM_uint32 FAR PASCAL _loadds _export gss_release_cred
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t FAR * /* cred_handle */
);
OM_uint32 FAR PASCAL _loadds _export gss_init_sec_context
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t, /* claimant_cred_handle */
gss_ctx_id_t FAR *, /* context_handle */
gss_name_t, /* target_name */
gss_OID, /* mech_type */
int, /* req_flags */
int, /* time_req */
gss_channel_bindings_t,/* input_chan_bindings */
gss_buffer_t, /* input_token */
gss_OID FAR *, /* actual_mech_type */
gss_buffer_t, /* output_token */
int FAR *, /* ret_flags */
OM_uint32 FAR * /* time_rec */
);
OM_uint32 FAR PASCAL _loadds _export gss_process_context_token
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t /* token_buffer */
);
OM_uint32 FAR PASCAL _loadds _export gss_delete_sec_context
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t /* output_token */
);
OM_uint32 FAR PASCAL _loadds _export gss_sign
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context handle */
int, /* qop_req */
gss_buffer_t, /* message_buffer */
gss_buffer_t /* message_token */
);
OM_uint32 FAR PASCAL _loadds _export gss_verify
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t, /* message_buffer */
gss_buffer_t, /* token_buffer */
int FAR * /* qop_state */
);
OM_uint32 FAR PASCAL _loadds _export gss_seal
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
int, /* conf_req_flag */
int, /* qop_req */
gss_buffer_t, /* input_message_buffer */
int FAR *, /* conf_state */
gss_buffer_t /* output_message_buffer */
);
OM_uint32 FAR PASCAL _loadds _export gss_unseal
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t, /* input_message_buffer */
gss_buffer_t, /* output_message_buffer */
int FAR *, /* conf_state */
int FAR * /* qop_state */
);
OM_uint32 FAR PASCAL _loadds _export gss_compare_name
(OM_uint32 FAR *, /* minor_status */
gss_name_t, /* name 1 */
gss_name_t, /* name 2 */
int FAR * /* name equal */
);
OM_uint32 FAR PASCAL _loadds _export gss_display_name
(OM_uint32 FAR *, /* minor_status */
gss_name_t, /* input_name */
gss_buffer_t, /* output_name_buffer */
gss_OID FAR * /* output_name_type */
);
OM_uint32 FAR PASCAL _loadds _export gss_import_name
(OM_uint32 FAR *, /* minor_status */
gss_buffer_t, /* input_name_buffer */
gss_OID, /* input_name_type */
gss_name_t FAR * /* output_name */
);
OM_uint32 FAR PASCAL _loadds _export gss_release_name
(OM_uint32 FAR *, /* minor_status */
gss_name_t FAR * /* name */
);
OM_uint32 FAR PASCAL _loadds _export gss_display_status
(OM_uint32 FAR *, /* minor_status */
int, /* status_value */
int, /* status_type */
gss_OID, /* mech_type */
int FAR *, /* message_context */
gss_buffer_t /* status_string */
);
OM_uint32 FAR PASCAL _loadds _export gss_context_time
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
OM_uint32 FAR * /* time_rec */
);
OM_uint32 FAR PASCAL _loadds _export gss_release_buffer
(OM_uint32 FAR *, /* minor_status */
gss_buffer_t /* buffer */
);
OM_uint32 FAR PASCAL _loadds _export gss_release_oid_set
(OM_uint32 FAR *, /* minor_status */
gss_OID_set FAR * /* set */
);
2.3 Exported Generic Data Structures
typedef struct gss_OID_desc_struct {
OM_uint32 length;
LPCSTR elements;
} gss_OID_desc, FAR *gss_OID;
typedef struct gss_OID_set_desc_struct {
int count;
gss_OID elements;
} gss_OID_set_desc, FAR *gss_OID_set;
typedef struct gss_buffer_desc_struct {
size_t length;
LPCSTR value;
} gss_buffer_desc, FAR *gss_buffer_t;
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} gss_channel_bindings_desc, FAR *gss_channel_bindings_t;
2.4 Exported Implementation-defined Data Structures
typedef unsigned int OM_uint32;
typedef unsigned int gss_ctx_id_t;
typedef unsigned int gss_cred_id_t;
typedef enum {
GSS_KRB_PRIN,
GSS_OID,
GSS_UID }
gss_name_en;
typedef union {
krb5_principal gss_krb_prin;
struct {
gss_OID oid;
gss_buffer_t val;
} value;
uid_t user_id;
}
gss_name_value;
typedef struct {
gss_name_en id_type;
gss_name_value id_value; }
gss_name_t;
3. GSS-API Security Attribute and Delegation Bindings
3.1 Summary
This section lists all GSS-API security attribute and delegation
bindings required for the PC client.
3.2 Entry Points
OM_uint32 FAR PASCAL _loadds _export gss_get_attributes
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t, /* cred_handle */
gss_ctx_id_t, /* context_handle */
gss_id_set, /*attrib_types_reqred */
gss_priv_attribute_set FAR *, /* attributes */
gss_target_control_set FAR *
/* acutal_target_controls */
);
OM_uint32 FAR PASCAL _loadds _export gss_modify_cred
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t, /* cred_handle */
OM_uint32, /* duplicate_cred_req */
OM_uint32, /* commit_cred_req */
gss_priv_attribute_set, /* required_priv attribs */
gss_target_control_set, /* required_target_cntrls */
gss_cred_id_t FAR *, /* output_cred_han */
gss_priv_attribute_set FAR *,
/* actual_privilege_attributes */
gss_target_control_set FAR *
/* actual_target_controls */
);
OM_uint32 FAR PASCAL _loadds _export
gss_release_priv_attribute_set
(OM_uint32 FAR *, /* minor_status */
gss_priv_attribute_set FAR * /* attribute_set */
);
OM_uint32 FAR PASCAL _loadds _export
gss_release_targ_control_set
(OM_uint32 FAR *, /* minor_status */
gss_target_control_set FAR * /* attribute_set */
);
3.3 Exported Data Structures
typedef enum {
gss_oid_t,
gss_integer,
gss_string,
gss_buffer }
gss_type_en;
typedef union {
gss_OID OID;
OM_uint32 FAR * integer;
char FAR * string;
gss_buffer_t buffer; }
gss_value;
typedef struct {
gss_type_en id_type;
gss_value id_value; }
gss_id;
typedef struct {
OM_uint32 cred_count;
gss_cred_id_t FAR * cred_list; }
gss_cred_list;
typedef struct {
OM_uint32 value_count;
gss_value FAR * value_list; }
gss_value_list;
typedef struct gss_attribute_desc {
gss_id attribute_type;
gss_id policy_authority;
gss_type_en value_syntax;
gss_value_list FAR * values_list; }
gss_attribute;
typedef struct gss_id_set_desc {
OM_uint32 id_count;
gss_id FAR * ids; }
gss_id_set;
typedef struct gss_attribute_set_desc {
OM_uint32 attribute_count;
gss_attribute FAR * attributes; }
gss_attribute_set;
typedef struct gss_priv_attribute_set_desc{
OM_uint32 access_flags;
gss_attribute_set FAR * priv_attributes;}
gss_priv_attribute_set;
typedef struct {
OM_uint32 time_count;
time_t FAR * time_list; }
gss_time_list;
typedef struct gss_controls_desc {
OM_uint32 FAR * check_back;
OM_uint32 FAR * usage_count; }
gss_controls;
typedef struct {
OM_uint32 control_count;
gss_controls FAR * control_list; }
gss_control_set;
typedef struct target_control_desc {
gss_attribute_set FAR * target_attributes;
gss_control_set FAR * controls_required;
gss_attribute_set FAR * optional_restrictions;
gss_attribute_set FAR * required_restrictions;
gss_attribute_set FAR * requested_attributes;
OM_uint32 delegation_flags;
}gss_target_control;
typedef struct {
gss_time_list valid_time_periods;
OM_uint32 target_control_count;
gss_target_control FAR * target_controls; }
gss_target_control_set;
4. GSS-API Provider Encapsulation Bindings
4.1 Purpose
This section lists all GSSAPI provider encapsulation bindings
required for the PC client.
4.2 Entry Points
OM_uint32 FAR PASCAL _loadds _export gss_deposit_cred
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t FAR *, /* output_cred_handle */
gss_OID, /* mech_type */
gss_buffer_t /* cred_data */
);
OM_uint32 FAR PASCAL _loadds _export gss_clear_cred
(OM_uint32 FAR * /* minor_status */
);
---end---
-------------------------------------------------------
P V McMahon 09AUG94
ICL Enterprises
post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: p.v.mcmahon at rea0803.wins.icl.co.uk
OR p.mcmahon at xopen.co.uk
phone: +44 734 634882
fax: +44 734 855106
-------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02406;
9 Aug 94 8:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02396;
9 Aug 94 8:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04519;
9 Aug 94 8:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02377;
9 Aug 94 8:12 EDT
Received: from gatekeeper.mcimail.com by IETF.CNRI.Reston.VA.US id aa02248;
9 Aug 94 7:59 EDT
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
id AA19452; Tue, 9 Aug 94 07:02:19 -0500
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id an01532;
9 Aug 94 11:56 GMT
Date: Tue, 9 Aug 94 06:57 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at IETF.CNRI.Reston.VA.US>
Subject: Please help me with some ISO - TCP wordings
Message-Id: <65940809115756/0003858921NA3EM at mcimail.com>
I just received a consultant's architecture paper. It has a definite ISO
slant and I need to check out a couple of items.
The 1st one states that TELNET, FTP, and FTAM use a common Dod/ISO
Association Control Service Element (ACSE) to manage communications between
clients & server nodes. -- What is this all about -- ???
The 2nd one states that SMP(SMVPv2) uses a common naming/directory service
based on X.500.
Can anyone shed some light on this?
Just EMail me directly, or to my test REAL internet ID of:
rgmoskowitz-3 at is.chrysler.com <-- subject to change. Working today...
Bob Moskowitz
Chrysler Corp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06887;
9 Aug 94 12:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06879;
9 Aug 94 12:34 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa12331;
9 Aug 94 12:34 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA02038 at pad-thai.aktis.com>; Tue, 9 Aug 1994 12:13:51 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA03595; Tue, 9 Aug 94 12:12:29 EDT
Received: from krypton.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19)
id AA13099; Tue, 9 Aug 94 11:12:23 CDT
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA09904; Tue, 9 Aug 94 11:12:22 CDT
Date: Tue, 9 Aug 94 11:12:22 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9408091612.AA09904 at krypton.mcc.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk's message of Tue, 9 Aug 94 11:52:24 BST <9408091052.AA09717 at getafix.oasis.icl.co.uk>
Subject: Windows 3.1 client GSS-API
Sections 3.2 and 4.2 have functions that aren't included in the GSSAPI
RFCs. Can you explain further what these are for?
In general, I think it would be good to have a MS Windows GSSAPI
Internet Draft developed.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07164;
9 Aug 94 12:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07155;
9 Aug 94 12:50 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa12648;
9 Aug 94 12:50 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA02497 at pad-thai.aktis.com>; Tue, 9 Aug 1994 12:31:57 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA04841; Tue, 9 Aug 94 12:30:35 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <23848-0 at relay1.pipex.net>; Tue, 9 Aug 1994 17:29:57 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA17605; Tue, 9 Aug 94 17:32:50 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA21780;
Tue, 9 Aug 94 17:28:42 BST
Message-Id: <9408091631.AA12623 at getafix.oasis.icl.co.uk>
Date: Tue, 9 Aug 94 17:31:13 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: Windows 3.1 client GSS-API
To: rosenthl at mcc.com
Cc: cat-ietf at mit.edu
Doug,
> Sections 3.2 and 4.2 have functions that aren't included in the GSSAPI
> RFCs. Can you explain further what these are for?
Respectively they're:
(3) APIs to enable callers to request/get security attributes from a
privilege attribute certificate (or potentially other source of
security attributes).
(4) APIs for a login program to interface with a GSS-API sub-system
> In general, I think it would be good to have a MS Windows GSSAPI
> Internet Draft developed.
If it's just a few lines, is this the best approach? Are there
precedents?
> - Doug
Piers
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07239;
9 Aug 94 12:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07229;
9 Aug 94 12:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12712;
9 Aug 94 12:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07211;
9 Aug 94 12:54 EDT
Received: from gatekeeper.mcimail.com by IETF.CNRI.Reston.VA.US id aa07149;
9 Aug 94 12:50 EDT
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
id AA11675; Tue, 9 Aug 94 11:53:24 -0500
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cb22708;
9 Aug 94 16:46 GMT
Date: Tue, 9 Aug 94 11:24 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at IETF.CNRI.Reston.VA.US>
Subject: Re: Please help me with some ISO - TCP wordings
Message-Id: <51940809162415/0003858921NA3EM at mcimail.com>
I would like to thank everyone that responded to my questions. To this ID
and my semi-real internet ID (almost real now :).
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07350;
9 Aug 94 12:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07342;
9 Aug 94 12:58 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa12828;
9 Aug 94 12:58 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA02564 at pad-thai.aktis.com>; Tue, 9 Aug 1994 12:40:09 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA05470; Tue, 9 Aug 94 12:38:52 EDT
Received: from krypton.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19)
id AA13431; Tue, 9 Aug 94 11:38:46 CDT
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA10023; Tue, 9 Aug 94 11:38:46 CDT
Date: Tue, 9 Aug 94 11:38:46 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9408091638.AA10023 at krypton.mcc.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk's message of Tue, 9 Aug 94 17:31:13 BST <9408091631.AA12623 at getafix.oasis.icl.co.uk>
Subject: Windows 3.1 client GSS-API
> Sections 3.2 and 4.2 have functions that aren't included in the GSSAPI
> RFCs. Can you explain further what these are for?
Respectively they're:
(3) APIs to enable callers to request/get security attributes from a
privilege attribute certificate (or potentially other source of
security attributes).
(4) APIs for a login program to interface with a GSS-API sub-system
> In general, I think it would be good to have a MS Windows GSSAPI
> Internet Draft developed.
If it's just a few lines, is this the best approach? Are there
precedents?
Check with John Linn (CAT WG chair - linn at cam.ov.com) about the
formalities of putting together an I-D. Also, seems like it should
only cover functions officically in the GSSAPI. I remember reading
somewhere that privilege attribute issues had been deferred to the
Authorization and Access Control (AAC) WG.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07884;
9 Aug 94 13:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07876;
9 Aug 94 13:31 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa13425;
9 Aug 94 13:31 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <NAA03189 at pad-thai.aktis.com>; Tue, 9 Aug 1994 13:06:58 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA07357; Tue, 9 Aug 94 13:05:36 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <25592-0 at relay1.pipex.net>; Tue, 9 Aug 1994 18:05:13 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA17975; Tue, 9 Aug 94 18:07:54 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA22129;
Tue, 9 Aug 94 18:03:45 BST
Message-Id: <9408091706.AA20912 at getafix.oasis.icl.co.uk>
Date: Tue, 9 Aug 94 18:06:15 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: Windows 3.1 client GSS-API
To: rosenthl at mcc.com
Cc: cat-ietf at mit.edu
> If it's just a few lines, is this the best approach? Are there
> precedents?
>
> Check with John Linn (CAT WG chair - linn at cam.ov.com) about the
> formalities of putting together an I-D. Also, seems like it should
I would like to see agreement on the principle that such a document
would be useful as a stand-alone entity.
A more pragmatic approach might be to sully the next issue of RFC1509
with a short annex (like section 1 of the memo I posted) describing
the derivation of Windows 3.1 bindings from the ANSI C bindings.
> only cover functions officically in the GSSAPI. I remember reading
Sure - but the point I was making is that the putative Windows 3.1
binding need have no C functions in it, just rules which are appied
relative to RFC1509, to derive the RFC1509 equivalents for the
Windows (or potentially other) OS environments.
[ > somewhere that privilege attribute issues had been deferred to the
> Authorization and Access Control (AAC) WG.
This is off the topic I wanted to raise, but the main focus of this IETF
group was the authorisation interface rather than these underlying GSS-API
extensions. Separately, some of the APIs in the document I posted have
been published by X/Open as a snapshot (i.e. unendorsed) spec, and await
multiple implementations in product to progress.]
Piers
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12375;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19514;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12319;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12159;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-sollins-urn-02.txt
Date: Tue, 09 Aug 94 17:43:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12159 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for Uniform Resource Names
Author(s) : K. Sollins, L. Masinter
Filename : draft-sollins-urn-02.txt
Pages : 6
Date : 08/08/1994
This document sets out the requirements for Uniform Resource Names (URNs)
within a larger Internet information architecture, which in turn is
composed of, additionally, Uniform Resource Characteristics (URCs), and
Uniform Resource Locators (URLs). URNs are used for identification, URCs
for including meta-information, and URLs for locating or finding resources.
It is provided as a basis for evaluating standards for URNs. The
discussions of this work have occurred on the mailing list uri at bunyip.com
and at the URI Working Group sessions of the IETF.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-sollins-urn-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-sollins-urn-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808140025.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-sollins-urn-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-sollins-urn-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808140025.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12375;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19514;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12319;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12159;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-sollins-urn-02.txt
Date: Tue, 09 Aug 94 17:43:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12159 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for Uniform Resource Names
Author(s) : K. Sollins, L. Masinter
Filename : draft-sollins-urn-02.txt
Pages : 6
Date : 08/08/1994
This document sets out the requirements for Uniform Resource Names (URNs)
within a larger Internet information architecture, which in turn is
composed of, additionally, Uniform Resource Characteristics (URCs), and
Uniform Resource Locators (URLs). URNs are used for identification, URCs
for including meta-information, and URLs for locating or finding resources.
It is provided as a basis for evaluating standards for URNs. The
discussions of this work have occurred on the mailing list uri at bunyip.com
and at the URI Working Group sessions of the IETF.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-sollins-urn-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-sollins-urn-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808140025.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-sollins-urn-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-sollins-urn-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808140025.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12378;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19513;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12315;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12186;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-chu-fibre-channel-mib-02.txt
Date: Tue, 09 Aug 94 17:43:31 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12186 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for the Node in Fibre
Channel Standard using SMIv2
Author(s) : J. Chu
Filename : draft-chu-fibre-channel-mib-02.txt
Pages : 27
Date : 08/08/1994
This memo defines a module of the Management Information Base (MIB) for use
with network management protocols in TCP/IP-based internets. In
particular, it defines the objects for managing the operations of the Node
in the Fiber Channel Standard.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-chu-fibre-channel-mib-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-chu-fibre-channel-mib-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808141146.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-chu-fibre-channel-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chu-fibre-channel-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808141146.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12378;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19513;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12315;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12186;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-chu-fibre-channel-mib-02.txt
Date: Tue, 09 Aug 94 17:43:31 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12186 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for the Node in Fibre
Channel Standard using SMIv2
Author(s) : J. Chu
Filename : draft-chu-fibre-channel-mib-02.txt
Pages : 27
Date : 08/08/1994
This memo defines a module of the Management Information Base (MIB) for use
with network management protocols in TCP/IP-based internets. In
particular, it defines the objects for managing the operations of the Node
in the Fiber Channel Standard.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-chu-fibre-channel-mib-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-chu-fibre-channel-mib-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808141146.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-chu-fibre-channel-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chu-fibre-channel-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808141146.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12380;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19516;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12318;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12148;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-irl-fun-req-01.txt
Date: Tue, 09 Aug 94 17:43:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12148 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Functional Requirements for Internet Resource Locators
Author(s) : J. Kunze
Filename : draft-ietf-uri-irl-fun-req-01.txt
Pages : 6
Date : 08/08/1994
This document specifies a minimum set of requirements for Internet resource
locators, which convey location and access information for resources.
Typical examples of resources include network accessible documents, WAIS
databases, FTP servers, and Telnet destinations.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-irl-fun-req-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-irl-fun-req-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-irl-fun-req-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-irl-fun-req-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12380;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19516;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12318;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12148;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-irl-fun-req-01.txt
Date: Tue, 09 Aug 94 17:43:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12148 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Functional Requirements for Internet Resource Locators
Author(s) : J. Kunze
Filename : draft-ietf-uri-irl-fun-req-01.txt
Pages : 6
Date : 08/08/1994
This document specifies a minimum set of requirements for Internet resource
locators, which convey location and access information for resources.
Typical examples of resources include network accessible documents, WAIS
databases, FTP servers, and Telnet destinations.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-irl-fun-req-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-irl-fun-req-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-irl-fun-req-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-irl-fun-req-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12385;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19518;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12321;
9 Aug 94 17:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11992;
9 Aug 94 17:38 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19304;
9 Aug 94 17:38 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05891>; Tue, 9 Aug 1994 14:39:12 -0700
Message-Id: <199408092139.AA05891 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1633 in PostScript
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 14:39:40 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
Note: This is a PostScript version of RFC 1633. The ASCII version of
this RFC is the primary reference version. The PostScript version is
secondary. For descriptive purposes, the PostScript version may
contain typographic variations (italics, boldface, etc.), figures, and
other features that promote readability and understanding.
RFC 1633:
Title: Integrated Services in the Internet Architecture:
an Overview
Author: R. Braden, D. Clark & S. Shenker
Mailbox: Braden at ISI.EDU, ddc at lcs.mit.edu,
Shenker at PARC.XEROX.COM
PS-Pages: 28
PS-Characters: 207,016
Updates/Obsoletes: none
This memo discusses a proposed extension to the Internet architecture
and protocols to provide integrated services, i.e., to support
real-time as well as the current non-real-time service of IP. This
extension is necessary to meet the growing need for real-time service
for a variety of new applications, including teleconferencing, remote
seminars, telescience, and distributed simulation.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the PostScript 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: application/postscript
Content-ID: <940809121632.RFC at ISI.EDU>
SEND /rfc/rfc1633.ps
--OtherAccess
Content-Type: Message/External-body;
name="rfc1633.ps";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: application/postscript
Content-ID: <940809121632.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12385;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19518;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12321;
9 Aug 94 17:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11992;
9 Aug 94 17:38 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19304;
9 Aug 94 17:38 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05891>; Tue, 9 Aug 1994 14:39:12 -0700
Message-Id: <199408092139.AA05891 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1633 in PostScript
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 14:39:40 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
Note: This is a PostScript version of RFC 1633. The ASCII version of
this RFC is the primary reference version. The PostScript version is
secondary. For descriptive purposes, the PostScript version may
contain typographic variations (italics, boldface, etc.), figures, and
other features that promote readability and understanding.
RFC 1633:
Title: Integrated Services in the Internet Architecture:
an Overview
Author: R. Braden, D. Clark & S. Shenker
Mailbox: Braden at ISI.EDU, ddc at lcs.mit.edu,
Shenker at PARC.XEROX.COM
PS-Pages: 28
PS-Characters: 207,016
Updates/Obsoletes: none
This memo discusses a proposed extension to the Internet architecture
and protocols to provide integrated services, i.e., to support
real-time as well as the current non-real-time service of IP. This
extension is necessary to meet the growing need for real-time service
for a variety of new applications, including teleconferencing, remote
seminars, telescience, and distributed simulation.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the PostScript 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: application/postscript
Content-ID: <940809121632.RFC at ISI.EDU>
SEND /rfc/rfc1633.ps
--OtherAccess
Content-Type: Message/External-body;
name="rfc1633.ps";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: application/postscript
Content-ID: <940809121632.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12414;
9 Aug 94 17:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12378;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19513;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12315;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12186;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-chu-fibre-channel-mib-02.txt
Date: Tue, 09 Aug 94 17:43:31 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12186 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for the Node in Fibre
Channel Standard using SMIv2
Author(s) : J. Chu
Filename : draft-chu-fibre-channel-mib-02.txt
Pages : 27
Date : 08/08/1994
This memo defines a module of the Management Information Base (MIB) for use
with network management protocols in TCP/IP-based internets. In
particular, it defines the objects for managing the operations of the Node
in the Fiber Channel Standard.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-chu-fibre-channel-mib-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-chu-fibre-channel-mib-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808141146.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-chu-fibre-channel-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chu-fibre-channel-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808141146.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12415;
9 Aug 94 17:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12375;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19514;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12319;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12159;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-sollins-urn-02.txt
Date: Tue, 09 Aug 94 17:43:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12159 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Requirements for Uniform Resource Names
Author(s) : K. Sollins, L. Masinter
Filename : draft-sollins-urn-02.txt
Pages : 6
Date : 08/08/1994
This document sets out the requirements for Uniform Resource Names (URNs)
within a larger Internet information architecture, which in turn is
composed of, additionally, Uniform Resource Characteristics (URCs), and
Uniform Resource Locators (URLs). URNs are used for identification, URCs
for including meta-information, and URLs for locating or finding resources.
It is provided as a basis for evaluating standards for URNs. The
discussions of this work have occurred on the mailing list uri at bunyip.com
and at the URI Working Group sessions of the IETF.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-sollins-urn-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-sollins-urn-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808140025.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-sollins-urn-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-sollins-urn-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808140025.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12440;
9 Aug 94 17:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12385;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19518;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12321;
9 Aug 94 17:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11992;
9 Aug 94 17:38 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19304;
9 Aug 94 17:38 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA05891>; Tue, 9 Aug 1994 14:39:12 -0700
Message-Id: <199408092139.AA05891 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1633 in PostScript
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 14:39:40 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
Note: This is a PostScript version of RFC 1633. The ASCII version of
this RFC is the primary reference version. The PostScript version is
secondary. For descriptive purposes, the PostScript version may
contain typographic variations (italics, boldface, etc.), figures, and
other features that promote readability and understanding.
RFC 1633:
Title: Integrated Services in the Internet Architecture:
an Overview
Author: R. Braden, D. Clark & S. Shenker
Mailbox: Braden at ISI.EDU, ddc at lcs.mit.edu,
Shenker at PARC.XEROX.COM
PS-Pages: 28
PS-Characters: 207,016
Updates/Obsoletes: none
This memo discusses a proposed extension to the Internet architecture
and protocols to provide integrated services, i.e., to support
real-time as well as the current non-real-time service of IP. This
extension is necessary to meet the growing need for real-time service
for a variety of new applications, including teleconferencing, remote
seminars, telescience, and distributed simulation.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the PostScript 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: application/postscript
Content-ID: <940809121632.RFC at ISI.EDU>
SEND /rfc/rfc1633.ps
--OtherAccess
Content-Type: Message/External-body;
name="rfc1633.ps";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: application/postscript
Content-ID: <940809121632.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12441;
9 Aug 94 17:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12380;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19516;
9 Aug 94 17:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12318;
9 Aug 94 17:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12148;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-irl-fun-req-01.txt
Date: Tue, 09 Aug 94 17:43:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408091743.aa12148 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Functional Requirements for Internet Resource Locators
Author(s) : J. Kunze
Filename : draft-ietf-uri-irl-fun-req-01.txt
Pages : 6
Date : 08/08/1994
This document specifies a minimum set of requirements for Internet resource
locators, which convey location and access information for resources.
Typical examples of resources include network accessible documents, WAIS
databases, FTP servers, and Telnet destinations.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-irl-fun-req-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-irl-fun-req-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-irl-fun-req-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-irl-fun-req-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13553;
9 Aug 94 19:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21063;
9 Aug 94 19:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13533;
9 Aug 94 19:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13506;
9 Aug 94 19:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20945;
9 Aug 94 19:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10642>; Tue, 9 Aug 1994 16:01:24 -0700
Message-Id: <199408092301.AA10642 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1682 on IPng BSD Host Implementation Analysis
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:01:53 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1682:
Title: IPng BSD Host Implementation Analysis
Author: J. Bound
Mailbox: bound at zk3.dec.com
Pages: 10
Characters: 22,295
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This IPng white paper
was submitted to the IPng Directorate to provide a BSD host point of
reference to assist with the engineering considerations during the
IETF process to select an IPng proposal. The University of California
Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4) system
implementation on a host is used as a point of reference for the
paper.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809154659.RFC at ISI.EDU>
SEND /rfc/rfc1682.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1682.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809154659.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13553;
9 Aug 94 19:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21063;
9 Aug 94 19:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13533;
9 Aug 94 19:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13506;
9 Aug 94 19:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20945;
9 Aug 94 19:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10642>; Tue, 9 Aug 1994 16:01:24 -0700
Message-Id: <199408092301.AA10642 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1682 on IPng BSD Host Implementation Analysis
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:01:53 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1682:
Title: IPng BSD Host Implementation Analysis
Author: J. Bound
Mailbox: bound at zk3.dec.com
Pages: 10
Characters: 22,295
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This IPng white paper
was submitted to the IPng Directorate to provide a BSD host point of
reference to assist with the engineering considerations during the
IETF process to select an IPng proposal. The University of California
Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4) system
implementation on a host is used as a point of reference for the
paper.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809154659.RFC at ISI.EDU>
SEND /rfc/rfc1682.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1682.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809154659.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13564;
9 Aug 94 19:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13553;
9 Aug 94 19:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21063;
9 Aug 94 19:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13533;
9 Aug 94 19:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13506;
9 Aug 94 19:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20945;
9 Aug 94 19:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10642>; Tue, 9 Aug 1994 16:01:24 -0700
Message-Id: <199408092301.AA10642 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1682 on IPng BSD Host Implementation Analysis
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:01:53 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1682:
Title: IPng BSD Host Implementation Analysis
Author: J. Bound
Mailbox: bound at zk3.dec.com
Pages: 10
Characters: 22,295
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. This IPng white paper
was submitted to the IPng Directorate to provide a BSD host point of
reference to assist with the engineering considerations during the
IETF process to select an IPng proposal. The University of California
Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4) system
implementation on a host is used as a point of reference for the
paper.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809154659.RFC at ISI.EDU>
SEND /rfc/rfc1682.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1682.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809154659.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13617;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21199;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13600;
9 Aug 94 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13535;
9 Aug 94 19:04 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21027;
9 Aug 94 19:03 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10932>; Tue, 9 Aug 1994 16:04:09 -0700
Message-Id: <199408092304.AA10932 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1683 on Multiprotocol Interoperability In IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:04:37 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1683:
Title: Multiprotocol Interoperability In IPng
Author: R. Clark, M. Ammar & K. Calvert
Mailbox: rjc at cc.gatech.edu, ammar at cc.gatech.edu,
calvert at cc.gatech.edu
Pages: 12
Characters: 28,201
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. The two most commonly
cited issues motivating the introduction of IPng are address depletion
and routing table growth in IPv4. Further motivation is the fact that
the Internet is witnessing an increasing diversity in the protocols
and services found in the network. When evaluating alternatives for
IPng, we should consider how well each alternative addresses the
problems arising from this diversity. In this document, we identify
several features that affect a protocol's ability to operate in a
multiprotocol environment and propose the incorporation of these
features into IPng. Our thesis, succinctly stated, is: The next
generation Internet Protocol should have features that support its use
with a variety of protocol architectures.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160245.RFC at ISI.EDU>
SEND /rfc/rfc1683.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1683.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160245.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13617;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21199;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13600;
9 Aug 94 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13535;
9 Aug 94 19:04 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21027;
9 Aug 94 19:03 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10932>; Tue, 9 Aug 1994 16:04:09 -0700
Message-Id: <199408092304.AA10932 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1683 on Multiprotocol Interoperability In IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:04:37 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1683:
Title: Multiprotocol Interoperability In IPng
Author: R. Clark, M. Ammar & K. Calvert
Mailbox: rjc at cc.gatech.edu, ammar at cc.gatech.edu,
calvert at cc.gatech.edu
Pages: 12
Characters: 28,201
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. The two most commonly
cited issues motivating the introduction of IPng are address depletion
and routing table growth in IPv4. Further motivation is the fact that
the Internet is witnessing an increasing diversity in the protocols
and services found in the network. When evaluating alternatives for
IPng, we should consider how well each alternative addresses the
problems arising from this diversity. In this document, we identify
several features that affect a protocol's ability to operate in a
multiprotocol environment and propose the incorporation of these
features into IPng. Our thesis, succinctly stated, is: The next
generation Internet Protocol should have features that support its use
with a variety of protocol architectures.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160245.RFC at ISI.EDU>
SEND /rfc/rfc1683.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1683.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160245.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13631;
9 Aug 94 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13617;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21199;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13600;
9 Aug 94 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13535;
9 Aug 94 19:04 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21027;
9 Aug 94 19:03 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10932>; Tue, 9 Aug 1994 16:04:09 -0700
Message-Id: <199408092304.AA10932 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1683 on Multiprotocol Interoperability In IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:04:37 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1683:
Title: Multiprotocol Interoperability In IPng
Author: R. Clark, M. Ammar & K. Calvert
Mailbox: rjc at cc.gatech.edu, ammar at cc.gatech.edu,
calvert at cc.gatech.edu
Pages: 12
Characters: 28,201
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet at munnari.oz.au mailing list. The two most commonly
cited issues motivating the introduction of IPng are address depletion
and routing table growth in IPv4. Further motivation is the fact that
the Internet is witnessing an increasing diversity in the protocols
and services found in the network. When evaluating alternatives for
IPng, we should consider how well each alternative addresses the
problems arising from this diversity. In this document, we identify
several features that affect a protocol's ability to operate in a
multiprotocol environment and propose the incorporation of these
features into IPng. Our thesis, succinctly stated, is: The next
generation Internet Protocol should have features that support its use
with a variety of protocol architectures.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160245.RFC at ISI.EDU>
SEND /rfc/rfc1683.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1683.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160245.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13705;
9 Aug 94 19:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21295;
9 Aug 94 19:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13680;
9 Aug 94 19:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13639;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21211;
9 Aug 94 19:08 EDT
Received: from zephyr.isi.edu by IETF.CNRI.Reston.VA.US id aa13611;
9 Aug 94 19:08 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA11342>; Tue, 9 Aug 1994 16:07:05 -0700
Message-Id: <199408092307.AA11342 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1684 on Introduction to X.500 White Pages Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:07:34 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1684:
Title: Introduction to White Pages Services based on
X.500
Author: P. Jurg
Mailbox: Peter.Jurg at surfnet.nl
Pages: 10
Characters: 22,985
Updates/Obsoletes: none
This document aims at organisations who are using local and global
electronic communication on a day to day basis and for whom using an
electronic White Pages Service is therefore indispensable. The
document provides an introduction to the international ITU-T (formerly
CCITT) X.500 and ISO 9594 standard, which is particularly suited for
providing an integrated local and global electronic White Pages
Service.
In addition, a short overview of the experience gained from the
Paradise X.500 pilot is given. References to more detailed information
are included. The document should be useful for managers of the above
mentioned organisations who need to get the necessary executive
commitment for making the address information of their organisation
available by means of X.500.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160513.RFC at ISI.EDU>
SEND /rfc/rfc1684.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1684.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160513.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13705;
9 Aug 94 19:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21295;
9 Aug 94 19:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13680;
9 Aug 94 19:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13639;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21211;
9 Aug 94 19:08 EDT
Received: from zephyr.isi.edu by IETF.CNRI.Reston.VA.US id aa13611;
9 Aug 94 19:08 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA11342>; Tue, 9 Aug 1994 16:07:05 -0700
Message-Id: <199408092307.AA11342 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1684 on Introduction to X.500 White Pages Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:07:34 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1684:
Title: Introduction to White Pages Services based on
X.500
Author: P. Jurg
Mailbox: Peter.Jurg at surfnet.nl
Pages: 10
Characters: 22,985
Updates/Obsoletes: none
This document aims at organisations who are using local and global
electronic communication on a day to day basis and for whom using an
electronic White Pages Service is therefore indispensable. The
document provides an introduction to the international ITU-T (formerly
CCITT) X.500 and ISO 9594 standard, which is particularly suited for
providing an integrated local and global electronic White Pages
Service.
In addition, a short overview of the experience gained from the
Paradise X.500 pilot is given. References to more detailed information
are included. The document should be useful for managers of the above
mentioned organisations who need to get the necessary executive
commitment for making the address information of their organisation
available by means of X.500.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160513.RFC at ISI.EDU>
SEND /rfc/rfc1684.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1684.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160513.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13716;
9 Aug 94 19:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13705;
9 Aug 94 19:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21295;
9 Aug 94 19:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13680;
9 Aug 94 19:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13639;
9 Aug 94 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21211;
9 Aug 94 19:08 EDT
Received: from zephyr.isi.edu by IETF.CNRI.Reston.VA.US id aa13611;
9 Aug 94 19:08 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA11342>; Tue, 9 Aug 1994 16:07:05 -0700
Message-Id: <199408092307.AA11342 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1684 on Introduction to X.500 White Pages Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:07:34 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1684:
Title: Introduction to White Pages Services based on
X.500
Author: P. Jurg
Mailbox: Peter.Jurg at surfnet.nl
Pages: 10
Characters: 22,985
Updates/Obsoletes: none
This document aims at organisations who are using local and global
electronic communication on a day to day basis and for whom using an
electronic White Pages Service is therefore indispensable. The
document provides an introduction to the international ITU-T (formerly
CCITT) X.500 and ISO 9594 standard, which is particularly suited for
providing an integrated local and global electronic White Pages
Service.
In addition, a short overview of the experience gained from the
Paradise X.500 pilot is given. References to more detailed information
are included. The document should be useful for managers of the above
mentioned organisations who need to get the necessary executive
commitment for making the address information of their organisation
available by means of X.500.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160513.RFC at ISI.EDU>
SEND /rfc/rfc1684.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1684.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160513.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13755;
9 Aug 94 19:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21324;
9 Aug 94 19:12 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13744;
9 Aug 94 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13667;
9 Aug 94 19:10 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21279;
9 Aug 94 19:10 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA11492>; Tue, 9 Aug 1994 16:10:55 -0700
Message-Id: <199408092310.AA11492 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1685, RTR12 on Writing X.400 O/R Names
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:11:24 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1685:
RTR 12:
Title: Writing X.400 O/R Names
Author: H. Alvestrand
Mailbox: Harald.Alvestrand at uninett.no
Pages: 11
Characters: 21,242
Updates/Obsoletes: none
There is a need for human beings who use X.400 systems to be able to
write down O/R names in a uniform way. There has been a preexisting
recommendation on how to write O/R names for human consumption in the
RARE community. Now that the ISO/ITU has adopted a recommendation on
how to do this, RARE needs to update its recommendation on writing O/R
names to take this standard into account.
This memo provides information for the Internet Community. It does
not specify an Internet Standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160816.RFC at ISI.EDU>
SEND /rfc/rfc1685.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1685.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160816.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13755;
9 Aug 94 19:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21324;
9 Aug 94 19:12 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13744;
9 Aug 94 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13667;
9 Aug 94 19:10 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21279;
9 Aug 94 19:10 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA11492>; Tue, 9 Aug 1994 16:10:55 -0700
Message-Id: <199408092310.AA11492 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1685, RTR12 on Writing X.400 O/R Names
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:11:24 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1685:
RTR 12:
Title: Writing X.400 O/R Names
Author: H. Alvestrand
Mailbox: Harald.Alvestrand at uninett.no
Pages: 11
Characters: 21,242
Updates/Obsoletes: none
There is a need for human beings who use X.400 systems to be able to
write down O/R names in a uniform way. There has been a preexisting
recommendation on how to write O/R names for human consumption in the
RARE community. Now that the ISO/ITU has adopted a recommendation on
how to do this, RARE needs to update its recommendation on writing O/R
names to take this standard into account.
This memo provides information for the Internet Community. It does
not specify an Internet Standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160816.RFC at ISI.EDU>
SEND /rfc/rfc1685.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1685.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160816.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13766;
9 Aug 94 19:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13755;
9 Aug 94 19:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21324;
9 Aug 94 19:12 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13744;
9 Aug 94 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13667;
9 Aug 94 19:10 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21279;
9 Aug 94 19:10 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA11492>; Tue, 9 Aug 1994 16:10:55 -0700
Message-Id: <199408092310.AA11492 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1685, RTR12 on Writing X.400 O/R Names
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 09 Aug 94 16:11:24 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1685:
RTR 12:
Title: Writing X.400 O/R Names
Author: H. Alvestrand
Mailbox: Harald.Alvestrand at uninett.no
Pages: 11
Characters: 21,242
Updates/Obsoletes: none
There is a need for human beings who use X.400 systems to be able to
write down O/R names in a uniform way. There has been a preexisting
recommendation on how to write O/R names for human consumption in the
RARE community. Now that the ISO/ITU has adopted a recommendation on
how to do this, RARE needs to update its recommendation on writing O/R
names to take this standard into account.
This memo provides information for the Internet Community. It does
not specify an Internet Standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940809160816.RFC at ISI.EDU>
SEND /rfc/rfc1685.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1685.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940809160816.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14441;
9 Aug 94 19:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14437;
9 Aug 94 19:37 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa21719;
9 Aug 94 19:37 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA14494 on Tue, 9 Aug 94 17:49:43 -0400
Received: from ietf.cnri.reston.va.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA14490 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Tue, 9 Aug 94 17:49:37 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12148;
9 Aug 94 17:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: uri at bunyip.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-irl-fun-req-01.txt
Date: Tue, 09 Aug 94 17:43:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408091743.aa12148 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Functional Requirements for Internet Resource Locators
Author(s) : J. Kunze
Filename : draft-ietf-uri-irl-fun-req-01.txt
Pages : 6
Date : 08/08/1994
This document specifies a minimum set of requirements for Internet resource
locators, which convey location and access information for resources.
Typical examples of resources include network accessible documents, WAIS
databases, FTP servers, and Telnet destinations.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-irl-fun-req-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-irl-fun-req-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-irl-fun-req-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-irl-fun-req-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940808135548.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15285;
9 Aug 94 21:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15277;
9 Aug 94 21:47 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa24099;
9 Aug 94 21:47 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <VAA12621 at pad-thai.aktis.com>; Tue, 9 Aug 1994 21:15:45 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA07509; Tue, 9 Aug 94 21:14:28 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA02282; Tue, 9 Aug 94 21:14:09 EDT
Date: Tue, 9 Aug 94 21:14:09 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408100114.AA02282 at tsx-11.MIT.EDU>
To: rosenthl at mcc.com
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, cat-ietf at mit.edu
In-Reply-To: Doug Rosenthal's message of Tue, 9 Aug 94 11:38:46 CDT,
<9408091638.AA10023 at krypton.mcc.com>
Subject: Re: Windows 3.1 client GSS-API
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Tue, 9 Aug 94 11:38:46 CDT
From: rosenthl at mcc.com (Doug Rosenthal)
Check with John Linn (CAT WG chair - linn at cam.ov.com) about the
formalities of putting together an I-D. Also, seems like it should
only cover functions officically in the GSSAPI. I remember reading
somewhere that privilege attribute issues had been deferred to the
Authorization and Access Control (AAC) WG.
As I mentioned to Piers in private mail, my suggestion is that I-D
should only include section one of his document --- which describes how
to take the GSSAPI specification, and add "FAR PASCAL" and "FAR *" in
the right places to create the bastardized Windows/C interface. This
way, it's more concise, and we don't necessarily need to rev that part
of the document as we upgrade the GSSAPI.
The other thing that I-D should do is nail down enough things so that we
can actually put together a DLL (dynamic link library) interface
standard. This would require nailing down the platform/mechanism
specific types which are delibarately left unspecified under RFC1509.
We should probably make them be void *'s, so that an implementation
still has some flexibility about what it needs to store.
Finally, we would also have to assign DLL #'s for each of the GSSAPI
functions.
With these two things nailed down, it should be possible to two people
to create an Windows DLL, and a program which called that DLL, without
needing to do any further coordination work.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02034;
10 Aug 94 8:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02025;
10 Aug 94 8:12 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa04544;
10 Aug 94 8:12 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <HAA22188 at pad-thai.aktis.com>; Wed, 10 Aug 1994 07:42:49 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA21380; Wed, 10 Aug 94 07:41:31 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <HAA22184 at pad-thai.aktis.com>; Wed, 10 Aug 1994 07:42:46 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA00220; Wed, 10 Aug 94 07:42:44 EDT
Message-Id: <9408101142.AA00220 at winkl.aktis.com>
To: minutes at CNRI.Reston.VA.US
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: CAT Toronto minutes
Date: Wed, 10 Aug 1994 07:42:44 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
COMMON AUTHENTICATION TECHNOLOGY (CAT) MINUTES, TORONTO, JULY 1994
Minutes compiled by John Linn (OpenVision); revised from initial
draft in response to mailing list discussion.
The Common Authentication Technology (CAT) WG met for two sessions in
Toronto, with a total of 59 rostered attendees. Approximately half
the attendees had attended one or more previous CAT meetings, and
approximately one third were subscribed to the WG mailing list.
Carlisle Adams (BNR) gave a presentation on the Simple Public-Key
Mechanism (SPKM), a proposed GSS-API mechanism based on public-key
technology, offering 2-way and 3-way authentication exchange variants,
generalized use of OIDs for flexibility, parameter negotiation, and
provisions for non-repudiation services. We reached rough consensus
on outstanding issues of GSS-API buffer sizes, continuation processing
of long messages, and context expiration, pending review by the
mailing list. Advancement of FTP security is pending on revision of
the Internet-Draft. We also received a presentation on IMAP
authentication by by John Myers (CMU).
Topics receiving significant discussion, summarized in
later sections of these minutes, included:
- The Simple Public-Key Mechanism (SPKM)
- Interactive Mail Access Protocol (IMAP) authentication
- Context expiration in Kerberos V5 mechanism and GSS-API
- Continuation processing and large message handling in GSS-API
SHORT TOPICS
In opening agenda discussion, P. Rajaram (Bellcore) asked whether discussion
of authorization extensions to GSS-API, such as those proposed in X/Open
by Project SESAME, was an appropriate topic for CAT WG discussion. Piers
McMahon (ICL) commented that the SESAME work was outside the CAT WG's
current scope. It was also noted that a separate IETF Authorization and
Access Control (aac) WG exists and is chartered to pursue such activities,
but that the aac WG has not met recently.
Other topics, discussed briefly, included:
Kerberos principal object support; WG members were asked to review
the text in draft-ietf-cat-kerb5gss-01.txt proposing routines for
import and export of non-printable name objects and to consider
whether these routines should be migrated to successors to RFCs 1508
and 1509.
Negotiated mechanism: Don Stephenson (Sun) and P. Rajaram
to investigate reactivation of former work, possible availability of
code; any added application requirements for negotiation solicited
(one desirable: be able to make the negotiation messages compact for
insertion within existing size-limited protocols; another, enable
ordered preferences to be specified)
"SERVICE:"; prefix for service names: Ted Ts'o to send note to list,
summarizing issues and background. This prefix had been used to
distinguish service entities, in conjunction with a null mechanism
type. Its use now appears redundant along with the service name type,
(as described in the current draft), which serves as a hint to
gss_import_name() as to how to process a name in the course of
importation. There are some backward compatibility issues with
existing code. We need to decide how, and whether, to preserve use of
this convention.
Store-and-forward support service extensions to GSS-API: no consensus
within group on pursuing this topic at the meeting, but discussion is
proceeding on the mailing list. P. Kirstein (UCL) and P. McMahon
(ICL) noted that the European Community's TDP consortium is interested
in using (or defining, if needed) GSS-API compatible extensions in
this area, and that there would be interest in any work which might
emerge from the IETF.
Service-to-client one-way authentication (as desired, e.g., for use
by some Mosaic services):
at present, best available approach is to authenticate mutually from
accessing client to server, even though the client-server path isn't
an application requirement. It is also possible, if supported by
an underlying mechanism, to apply one-way authentication on a context
initiated by the Mosaic service and accepted by the Mosaic client.
Buffer sizes across GSS-API interface: It was believed that the 2Kbyte
threshold included in draft-ietf-kerb5gss-01.txt was smaller than
desirable, and that a change to 16Kbytes would be acceptable to known
implementors and would permit more efficient operation. It is
therefore proposed that the limit be increased to 16Kbytes.
Stream support ("CATS" protocol) - Ted Ts'o (MIT) to resend working
notes to list.
Status of FTP security draft - pending revision in response to posted
comments.
SPKM PRESENTATION
Carlisle Adams (BNR) gave a presentation on a proposed Simple
Public-Key Mechanism (SPKM), as described in Internet-Draft
draft-ietf-cat-spkmgss-00.txt. SPKM is based on a public key
infrastructure, offers (as separate mechanisms with different OIDs)
2-way and 3-way mutual authentication (thereby available to
environments without secure time); uses OIDs wherever possible to
allow maximum flexibility and growth; uses negotiation at context
establishment time to allow interoperability between environments (for
SPKM-specific parameter negotiation, within the mechanism); QOP
parameter (from application) selects the data integrity mechanism to
be used; non-repudiation can be applied to context if desired.
BNR's work began with an interface for store-and-forward messaging
support, subsequently generalized for on-line, association-oriented
operation. BNR intends to offer the proposal as the basis for an
Internet standards track protocol. The development and distribution
status of a reference implementation for SPKM is not currently known,
but implementation is underway at Northern Telecom and/or BNR, and
feedback on the proposed approach is solicited.
Example tokens and exchanges were presented: A Req_Token initiates all
exchanges. The token structure is X.509-compliant, with some elements
optional. A key establishment OID's value describes the exchange
which is to follow. Context_Data provides the parameters describing a
context. The Seal token bears OIDs for each of the integrity,
sequence, and confidentiality algorithms: it carries an explicit OID
if the parameters established at context initiation allow more than
one, and is otherwise NULL. Questions about alignment and padding of
variable-length fields were raised and discussed.
Issue: how do you handle later validation of a long-term signature,
once the context handle is no longer valid? Long-term signing was an
interest and a design consideration but is not a requirement.
Carlisle's conclusions slide summarized the following observations:
SPKM has advantages over alternatives, in terms of flexibility,
non-repudiation, negotiation support, and no required reliance on
secure timestamps.
IMAP AUTHENTICATION
In the CAT WG's second session, John Myers (CMU) led a discussion on
Interactive Mail Access Protocol (IMAP) authentication. This
approach, currently in last call for advancement to Proposed Standard,
implements an IMAP4 AUTHENTICATE command, based on FTP security's
AUTH/ADAT commands. It identifies authentication mechanisms by name,
and supports an arbitrary number of base64-encoded exchanges. Privacy
and integrity protection are supported; the authorization userid is
independent of the authentication ID. In contrast to FTP security,
there is no separate data vs. control channel. User-ID, protection
mechanism, and buffer size are negotiated during the authentication
exchange. Use of a protection mechanism is optional. IMAP
authentication has no interaction with plaintext login.
Examples were shown using Kerberos V4 and S/Key; a GSS-API mechanism
is defined as well (protecting option exchange with GSS_Seal()).
GSS-API and S/Key mechanisms are not yet implemented; Ted Ts'o
expressed interest in integrating with the Kerberos V5 development
stream via GSS-API if the IMAP code is distributable. In the IMAP
Kerberos mechanism, the client closes out the exchange by mutually
authenticating back to the server and declaring accepted service
options. Design intentionally uses server-issued challenges, so as to
protect against replays even within the Kerberos 5 minute timestamp
window. Couldn't use S/Key with FTP security as it stands, since the
FTP security draft demands integrity on negotiation. It was suggested
that we consider changing the FTP security draft to enable conformant
use of S/Key.
DISCUSSION OF PROPOSED GSS-API CONTINUATION PROCESSING OF
LONG MESSAGES
During the course of the SPKM presentation slot, Carlisle Adams
suggested a GSS-API extension to accept segments of long buffers with
continuation flag parameters: add to gss_seal an "end_flag" which can
accept GSS_S_CONTINUE_NEEDED and add to gss_unseal the ability to
indicate that non-final vs. final segments are being emitted. Ted
Ts'o noted that the primary problem in the area of long message
processing is that the sender doesn't know how big a token the
receiver can handle. Carlisle was more concerned with the local
interface issue than with the issue of sizes supported by remote
peers. Bill Sommerfeld (HP) observed that application and GSS-API
should "cooperate" in terms of segment sizes.
The argument was made that the use of sequencing mechanisms and
per-message integrity vs. a single binding signature spanning multiple
data units is sufficient within the scope of an association-oriented
context; the binding signature might be more valuable in a
store-and-forward document scenario.
Three possible measures present themselves:
(1) Application calls a new GSS-API facility to find out how big a
token it can pass in in order to get an output token no bigger than
the maximum acceptable size. Compression can introduces variability
in the output size which will result for different data of the same
input size. The new facility needs to accept as input the QOP value
which is to be requested for data protection. Action: Incorporate
this facility for GSSV2.
(2) Constrain mechanisms so that arbitrary fragments, split within the
GSS-API or below, can be independently validated. (This had been a
discussion topic at the Seattle meeting, with Steve Lunt and others.)
We agreed not to impose this constraint.
(3) There was interest in a facility to distinguish an ordered stream
of non-initial segments from a final segment. P. Rajaram argued that
this would resolve the issue of not having enough memory to process
the data unit as a whole. Controversy revolved around whether this
was an appropriate facility at the level of the interface rather than
an application-specific issue above the interface. In Ted Ts'o's
proposed CATS package, connection close was indicated explicitly by
the CATS protocol, rendering moot the need to distinguish a final
message at the level of the GSS-API interface. After discussion, we
resolved (pending mailing list confirmation) not to incorporate
interface-level message continuation facilities.
CONTEXT EXPIRATION
We discussed context expiration within the Kerberos mechanism,
distinguishing enforced expiration (disabling per-message protection
when expiration time is reached) vs. advisory expiration (continuing
to perform per-message protection operations, with informatory status)
vs. no expiration. Advisory and enforced expiration cases can be
further subdivided into uniformly-performed expiration vs. expiration
performed only if requested by a caller at context expiration time.
Much of the interest in application-selectable expiration relates to
use as a trigger to garbage-collect keys and related data. Possible
inputs to an expiration policy would include (some combination of)
user-requested time, expiration time(s) of relevant tickets, local
configuration data, and input received from a peer.
In any of these scenarios, except "no expiration", applications must
be able to accomodate the occurrence of a no-longer-valid context,
effectively renewing by initiating a new one. It was suggested as a
possibly useful extension for init_context or an alternative routine
thereto to be able to accept an existing context handle as input for
renewal through establishment of a new context, but no detailed
exploration or conclusion on this suggestion was reached.
A prospect of "soft expiration", where advisory errors would be
received at a point in time before the context no longer operated, was
discussed but rejected as introducing unneeded complexity and being
ineffective for recovery after a context has been idle across both of
its "soft" and "hard" expiration times (e.g., after a user walks away
from a terminal, returns sometime later, and attempts to resume a
session). It was also observed that an application desiring a "soft"
warning could easily pass a time value appropriately less than the
context_time output as received from init_sec_context to an
OS-specific timer facility outside GSS-API.
In initial discussion relative to the Kerberos mechanism, popular
sentiment favored no expiration, but a range of views were expressed.
Bill Sommerfeld noted that DCE enforces hard expiration (with some
time windowing), but that this appeared more feasible in the DCE RPC
environment where RPC calls are typically short-lived than in the
general GSS-API case. In DCE RPC, expiration is enforced only for
call establishment, not within an already-established call. Ted Ts'o
asserted that expiration should not be enforced for at least the class
of rlogin-like applications, to avoid disrupting outstanding
associations. P. Rajaram also argued that enforced expiration was
unacceptably disruptive for certain applications, and that advisory
expiration wasn't a useful service for GSS-API to provide; Bill
Sommerfeld observed that advisory expiration could be a convenient
timing service, but that the motivation didn't appear compelling.
Piers McMahon observed that context expiration didn't enable a useful
policy enforcement mechanism, recognizing that use of all GSS-API
facilities is at an application's discretion.
Jeff Schiller (MIT) proposed that no context should last forever, and
that for the Kerberos mechanism the expiration time should be no later
than the expiration of the ticket(s) which are used to establish the
context; other inputs (e.g., caller request, configuration) could
result in an earlier expiration time. P. Rajaram argued that context
expiration should not be forced by ticket expiration times, but should
instead be based on an administratively-configurable parameter. After
active discussion, Jeff's approach was accepted as our working
proposal. Rationales discussed included: (a) programs like rlogin
were not likely to be using GSS-API, for reasons of performance in
character-at-a-time applications, and (b) applications for which
expiration was unacceptable could perform their own encryption outside
GSS-API, possibly using a GSS-API context as a means to securely
transfer their own keys. Mailing list discussion on context
expiration topics is continuing.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10197;
10 Aug 94 15:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14588;
10 Aug 94 15:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10152;
10 Aug 94 15:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08883;
10 Aug 94 14:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-rekhter-ipng-arch-IPv6-addr-00.txt
Date: Wed, 10 Aug 94 14:09:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408101409.aa08883 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : An Architecture for IPv6 Unicast Address Allocation
Author(s) : Y. Rekhter, T. Li
Filename : draft-rekhter-ipng-arch-IPv6-addr-00.txt
Pages : 24
Date : 08/09/1994
This document provides an architecture for allocating IPv6 unicast
addresses in the Internet. This document does not go into the details
of an addressing plan.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rekhter-ipng-arch-IPv6-addr-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940809174936.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-ipng-arch-IPv6-addr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940809174936.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10197;
10 Aug 94 15:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14588;
10 Aug 94 15:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10152;
10 Aug 94 15:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08883;
10 Aug 94 14:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-rekhter-ipng-arch-IPv6-addr-00.txt
Date: Wed, 10 Aug 94 14:09:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408101409.aa08883 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : An Architecture for IPv6 Unicast Address Allocation
Author(s) : Y. Rekhter, T. Li
Filename : draft-rekhter-ipng-arch-IPv6-addr-00.txt
Pages : 24
Date : 08/09/1994
This document provides an architecture for allocating IPv6 unicast
addresses in the Internet. This document does not go into the details
of an addressing plan.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rekhter-ipng-arch-IPv6-addr-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940809174936.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-ipng-arch-IPv6-addr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940809174936.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10208;
10 Aug 94 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10197;
10 Aug 94 15:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14588;
10 Aug 94 15:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10152;
10 Aug 94 15:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08883;
10 Aug 94 14:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-rekhter-ipng-arch-IPv6-addr-00.txt
Date: Wed, 10 Aug 94 14:09:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408101409.aa08883 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : An Architecture for IPv6 Unicast Address Allocation
Author(s) : Y. Rekhter, T. Li
Filename : draft-rekhter-ipng-arch-IPv6-addr-00.txt
Pages : 24
Date : 08/09/1994
This document provides an architecture for allocating IPv6 unicast
addresses in the Internet. This document does not go into the details
of an addressing plan.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rekhter-ipng-arch-IPv6-addr-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940809174936.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-rekhter-ipng-arch-IPv6-addr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-ipng-arch-IPv6-addr-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940809174936.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12960;
10 Aug 94 17:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18023;
10 Aug 94 17:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12918;
10 Aug 94 17:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12807;
10 Aug 94 17:19 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa17929;
10 Aug 94 17:19 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA14596>; Wed, 10 Aug 1994 14:19:39 -0700
Message-Id: <199408102119.AA14596 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1664 on Internet DNS for Mail Mapping Tables
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:20:08 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1664:
Title: Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables
Author: C. Allocchio, A. Bonito, B. Cole, S. Giordano &
R. Hagens
Mailbox: Claudio.Allocchio at elettra.trieste.it,
bonito at cnuce.cnr.it, bcole at cisco.com,
giordano at cscs.ch, hagens at ans.net
Pages: 23
Characters: 50,783
Updates/Obsoletes: none
This memo defines how to store in the Internet Domain Name System the
mapping information needed by e-mail gateways and other tools to map
RFC822 domain names into X.400 O/R names and vice versa. Mapping
information can be managed in a distributed rather than a centralised
way. Gateways located on Internet hosts can retrieve the mapping
information querying the DNS instead of having fixed tables which need
to be centrally updated and distributed. This memo is a joint effort
of X.400 Operations Working Group (x400ops) of the IETF and the RARE
Mail and Messaging Working Group (WG-MSG).
This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810141525.RFC at ISI.EDU>
SEND /rfc/rfc1664.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1664.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810141525.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12960;
10 Aug 94 17:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18023;
10 Aug 94 17:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12918;
10 Aug 94 17:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12807;
10 Aug 94 17:19 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa17929;
10 Aug 94 17:19 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA14596>; Wed, 10 Aug 1994 14:19:39 -0700
Message-Id: <199408102119.AA14596 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1664 on Internet DNS for Mail Mapping Tables
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:20:08 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1664:
Title: Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables
Author: C. Allocchio, A. Bonito, B. Cole, S. Giordano &
R. Hagens
Mailbox: Claudio.Allocchio at elettra.trieste.it,
bonito at cnuce.cnr.it, bcole at cisco.com,
giordano at cscs.ch, hagens at ans.net
Pages: 23
Characters: 50,783
Updates/Obsoletes: none
This memo defines how to store in the Internet Domain Name System the
mapping information needed by e-mail gateways and other tools to map
RFC822 domain names into X.400 O/R names and vice versa. Mapping
information can be managed in a distributed rather than a centralised
way. Gateways located on Internet hosts can retrieve the mapping
information querying the DNS instead of having fixed tables which need
to be centrally updated and distributed. This memo is a joint effort
of X.400 Operations Working Group (x400ops) of the IETF and the RARE
Mail and Messaging Working Group (WG-MSG).
This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810141525.RFC at ISI.EDU>
SEND /rfc/rfc1664.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1664.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810141525.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12971;
10 Aug 94 17:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12960;
10 Aug 94 17:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18023;
10 Aug 94 17:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12918;
10 Aug 94 17:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12807;
10 Aug 94 17:19 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa17929;
10 Aug 94 17:19 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA14596>; Wed, 10 Aug 1994 14:19:39 -0700
Message-Id: <199408102119.AA14596 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1664 on Internet DNS for Mail Mapping Tables
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:20:08 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1664:
Title: Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables
Author: C. Allocchio, A. Bonito, B. Cole, S. Giordano &
R. Hagens
Mailbox: Claudio.Allocchio at elettra.trieste.it,
bonito at cnuce.cnr.it, bcole at cisco.com,
giordano at cscs.ch, hagens at ans.net
Pages: 23
Characters: 50,783
Updates/Obsoletes: none
This memo defines how to store in the Internet Domain Name System the
mapping information needed by e-mail gateways and other tools to map
RFC822 domain names into X.400 O/R names and vice versa. Mapping
information can be managed in a distributed rather than a centralised
way. Gateways located on Internet hosts can retrieve the mapping
information querying the DNS instead of having fixed tables which need
to be centrally updated and distributed. This memo is a joint effort
of X.400 Operations Working Group (x400ops) of the IETF and the RARE
Mail and Messaging Working Group (WG-MSG).
This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810141525.RFC at ISI.EDU>
SEND /rfc/rfc1664.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1664.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810141525.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13191;
10 Aug 94 17:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18271;
10 Aug 94 17:34 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13178;
10 Aug 94 17:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13120;
10 Aug 94 17:31 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18214;
10 Aug 94 17:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA15091>; Wed, 10 Aug 1994 14:31:43 -0700
Message-Id: <199408102131.AA15091 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1686 on A Cable Television Industry Viewpoint on IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:32:12 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1686:
Title: IPng Requirements: A Cable Television Industry
Viewpoint
Author: M. Vecchi
Mailbox: mpvecchi at twcable.com
Pages: 14
Characters: 39,052
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. The statements in this paper
are intended as input to the technical discussions within IETF, and do
not represent any endorsement or commitment on the part of the cable
television industry or any of its companies. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
This RFC provides comments on topics related to the IPng requirements
and selection criteria from a cable television industry viewpoint.
The perspective taken is to position IPng as a potential
internetworking technology to support the global requirements of the
future integrated broadband networks that the cable industry is
designing and deploying. The paper includes a section describing the
cable television industry and outlining the network architectures to
support the delivery of entertainment programming and interactive
multimedia digital services, as well as telecommunication and data
communication services.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810142123.RFC at ISI.EDU>
SEND /rfc/rfc1686.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1686.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810142123.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13191;
10 Aug 94 17:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18271;
10 Aug 94 17:34 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13178;
10 Aug 94 17:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13120;
10 Aug 94 17:31 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18214;
10 Aug 94 17:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA15091>; Wed, 10 Aug 1994 14:31:43 -0700
Message-Id: <199408102131.AA15091 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1686 on A Cable Television Industry Viewpoint on IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:32:12 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1686:
Title: IPng Requirements: A Cable Television Industry
Viewpoint
Author: M. Vecchi
Mailbox: mpvecchi at twcable.com
Pages: 14
Characters: 39,052
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. The statements in this paper
are intended as input to the technical discussions within IETF, and do
not represent any endorsement or commitment on the part of the cable
television industry or any of its companies. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
This RFC provides comments on topics related to the IPng requirements
and selection criteria from a cable television industry viewpoint.
The perspective taken is to position IPng as a potential
internetworking technology to support the global requirements of the
future integrated broadband networks that the cable industry is
designing and deploying. The paper includes a section describing the
cable television industry and outlining the network architectures to
support the delivery of entertainment programming and interactive
multimedia digital services, as well as telecommunication and data
communication services.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810142123.RFC at ISI.EDU>
SEND /rfc/rfc1686.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1686.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810142123.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13202;
10 Aug 94 17:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13191;
10 Aug 94 17:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18271;
10 Aug 94 17:34 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13178;
10 Aug 94 17:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13120;
10 Aug 94 17:31 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18214;
10 Aug 94 17:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA15091>; Wed, 10 Aug 1994 14:31:43 -0700
Message-Id: <199408102131.AA15091 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1686 on A Cable Television Industry Viewpoint on IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:32:12 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1686:
Title: IPng Requirements: A Cable Television Industry
Viewpoint
Author: M. Vecchi
Mailbox: mpvecchi at twcable.com
Pages: 14
Characters: 39,052
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. The statements in this paper
are intended as input to the technical discussions within IETF, and do
not represent any endorsement or commitment on the part of the cable
television industry or any of its companies. Comments should be
submitted to the big-internet at munnari.oz.au mailing list.
This RFC provides comments on topics related to the IPng requirements
and selection criteria from a cable television industry viewpoint.
The perspective taken is to position IPng as a potential
internetworking technology to support the global requirements of the
future integrated broadband networks that the cable industry is
designing and deploying. The paper includes a section describing the
cable television industry and outlining the network architectures to
support the delivery of entertainment programming and interactive
multimedia digital services, as well as telecommunication and data
communication services.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810142123.RFC at ISI.EDU>
SEND /rfc/rfc1686.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1686.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810142123.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13369;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18391;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13356;
10 Aug 94 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13230;
10 Aug 94 17:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18298;
10 Aug 94 17:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA15168>; Wed, 10 Aug 1994 14:35:19 -0700
Message-Id: <199408102135.AA15168 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1687 on A Large Corporate User's View of IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:35:48 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1687:
Title: A Large Corporate User's View of IPng
Author: E. Fleischman
Mailbox: ericf at atc.boeing.com
Pages: 13
Characters: 34,120
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810143400.RFC at ISI.EDU>
SEND /rfc/rfc1687.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1687.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810143400.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13369;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18391;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13356;
10 Aug 94 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13230;
10 Aug 94 17:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18298;
10 Aug 94 17:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA15168>; Wed, 10 Aug 1994 14:35:19 -0700
Message-Id: <199408102135.AA15168 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1687 on A Large Corporate User's View of IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:35:48 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1687:
Title: A Large Corporate User's View of IPng
Author: E. Fleischman
Mailbox: ericf at atc.boeing.com
Pages: 13
Characters: 34,120
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810143400.RFC at ISI.EDU>
SEND /rfc/rfc1687.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1687.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810143400.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13380;
10 Aug 94 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13369;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18391;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13356;
10 Aug 94 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13230;
10 Aug 94 17:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18298;
10 Aug 94 17:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA15168>; Wed, 10 Aug 1994 14:35:19 -0700
Message-Id: <199408102135.AA15168 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1687 on A Large Corporate User's View of IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 10 Aug 94 14:35:48 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1687:
Title: A Large Corporate User's View of IPng
Author: E. Fleischman
Mailbox: ericf at atc.boeing.com
Pages: 13
Characters: 34,120
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940810143400.RFC at ISI.EDU>
SEND /rfc/rfc1687.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1687.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940810143400.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13504;
10 Aug 94 17:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18498;
10 Aug 94 17:40 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13480;
10 Aug 94 17:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13346;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18382;
10 Aug 94 17:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13335;
10 Aug 94 17:37 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: User Documents Revisions (userdoc2) to Conclude
Date: Wed, 10 Aug 94 17:37:07 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408101737.aa13335 at IETF.CNRI.Reston.VA.US>
The User Documents Revisions Working Group (userdoc2) of
the User Services Area of the IETF has concluded. The
mailing list will remain active. Unfinished business
will be completed within the User Services Working Group.
The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13504;
10 Aug 94 17:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18498;
10 Aug 94 17:40 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13480;
10 Aug 94 17:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13346;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18382;
10 Aug 94 17:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13335;
10 Aug 94 17:37 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: User Documents Revisions (userdoc2) to Conclude
Date: Wed, 10 Aug 94 17:37:07 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408101737.aa13335 at IETF.CNRI.Reston.VA.US>
The User Documents Revisions Working Group (userdoc2) of
the User Services Area of the IETF has concluded. The
mailing list will remain active. Unfinished business
will be completed within the User Services Working Group.
The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13515;
10 Aug 94 17:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13504;
10 Aug 94 17:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18498;
10 Aug 94 17:40 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13480;
10 Aug 94 17:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13346;
10 Aug 94 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18382;
10 Aug 94 17:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13335;
10 Aug 94 17:37 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: User Documents Revisions (userdoc2) to Conclude
Date: Wed, 10 Aug 94 17:37:07 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408101737.aa13335 at IETF.CNRI.Reston.VA.US>
The User Documents Revisions Working Group (userdoc2) of
the User Services Area of the IETF has concluded. The
mailing list will remain active. Unfinished business
will be completed within the User Services Working Group.
The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04686;
11 Aug 94 10:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04675;
11 Aug 94 10:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03084;
11 Aug 94 10:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04614;
11 Aug 94 10:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04311;
11 Aug 94 10:02 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa02757;
11 Aug 94 10:02 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA28562>; Thu, 11 Aug 1994 07:03:13 -0700
Message-Id: <199408111403.AA28562 at zephyr.isi.edu>
To: ietf at CNRI.Reston.VA.US
Subject: IP6 walkthrough
Cc: trustees at isoc.org
Reply-To: pvm at isi.edu
Date: Thu, 11 Aug 94 07:03:13 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Mockapetris <pvm at isi.edu>
As part of the last call process for the IP6 (nee IPng)
recommendation, the primary developers will be presenting a structured
walkthrough of the entire IP6 suite, including transition plans, on
Aug 22, from 1000-1300 (pacific time), with expanded material,
questions, etc from 1300-1400.
The presentation will be sent over the MBONE throughout the Internet.
Xerox PARC, MIT, and ISI (at least) will make conference room-style
access available to IESG and IAB members, the external review board,
and others as space and access constraints allow. Most of the
physical presentation will originate from PARC and MIT, but we
anticipate contributions and questions from other sites.
The rough agenda is:
Deering IPng Protocol
TBD IPng ROAD
TBD IPng Autoconfiguration
Atkinson IPng Security
TBD IPng Transition
Clark Review
Here's the MBONE session info for it:
audio at 45430/50691 (fmt: idvi)
video at 36611/9270 (fmt: nv)
whiteboard at 35618/41278 (orient: landscape, recvonly)
For directions and reservations at these specific sites contact:
Xerox PARC Steve Deering (deering at parc.xerox.com)
ISI Jeanine Yamazaki (yamazaki at isi.edu)
MIT Lisa Taylor (ltaylor at lcs.mit.edu)
Please send reservation requests as soon as possible so that we can
determine the number of spaces to reserve, refreshments, etc. (Each
site is detrmining its own policy here.)
A more detailed agenda will follow.
paul
USC/Information Sciences Institute phone: 310-822-1511 x285
4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714
90292
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06113;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04396;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06058;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05837;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-mail-summary-00.txt
Date: Thu, 11 Aug 94 11:07:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05837 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Summary of Mail and Messaging Standards
Author(s) : P. Robinson
Filename : draft-robinson-mail-summary-00.txt
Pages : 46
Date : 08/10/1994
Several RFCs define all of the standards having to do with the format,
transfer and management of E-mail and messages. So many are out there that
it is often difficult to find out where a specific item is. This memo is
an attempt to give the reader a general overview of the material and to
show where to look for particular information on mail and messaging
standards.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-mail-summary-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-mail-summary-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810172757.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-mail-summary-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-mail-summary-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810172757.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06113;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04396;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06058;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05837;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-mail-summary-00.txt
Date: Thu, 11 Aug 94 11:07:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05837 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Summary of Mail and Messaging Standards
Author(s) : P. Robinson
Filename : draft-robinson-mail-summary-00.txt
Pages : 46
Date : 08/10/1994
Several RFCs define all of the standards having to do with the format,
transfer and management of E-mail and messages. So many are out there that
it is often difficult to find out where a specific item is. This memo is
an attempt to give the reader a general overview of the material and to
show where to look for particular information on mail and messaging
standards.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-mail-summary-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-mail-summary-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810172757.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-mail-summary-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-mail-summary-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810172757.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06123;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04395;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06061;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05861;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-newtelex-00.txt
Date: Thu, 11 Aug 94 11:07:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05861 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Relationship of Telex Answerback Codes to
Internet Domains (2nd Revision)
Author(s) : P. Robinson
Filename : draft-robinson-newtelex-00.txt
Pages : 62
Date : 08/10/1994
This memo provides a major revision to my Internet RFC 1394 by: including
new information which was not available to me when the original document
was released; changes to old information due to the destruction of the
Soviet Union, East Germany and Yugoslavia, and the Balkanization of
Czechslovakia; corrects minor format errors; corrects some
misunderstandings which occurred from some people's misreading of the
original RFC document; and removes some omissions which occurred in the
original RFC. As the corrections (including a whole new set of information
which is added to the original document) are substantial, the original RFC
1394 will be obsoleted rather than revised when this document is published
as an RFC.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-newtelex-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-newtelex-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810173336.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-newtelex-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-newtelex-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810173336.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06123;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04395;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06061;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05861;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-newtelex-00.txt
Date: Thu, 11 Aug 94 11:07:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05861 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Relationship of Telex Answerback Codes to
Internet Domains (2nd Revision)
Author(s) : P. Robinson
Filename : draft-robinson-newtelex-00.txt
Pages : 62
Date : 08/10/1994
This memo provides a major revision to my Internet RFC 1394 by: including
new information which was not available to me when the original document
was released; changes to old information due to the destruction of the
Soviet Union, East Germany and Yugoslavia, and the Balkanization of
Czechslovakia; corrects minor format errors; corrects some
misunderstandings which occurred from some people's misreading of the
original RFC document; and removes some omissions which occurred in the
original RFC. As the corrections (including a whole new set of information
which is added to the original document) are substantial, the original RFC
1394 will be obsoleted rather than revised when this document is published
as an RFC.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-newtelex-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-newtelex-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810173336.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-newtelex-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-newtelex-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810173336.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06135;
11 Aug 94 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06113;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04396;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06058;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05837;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-mail-summary-00.txt
Date: Thu, 11 Aug 94 11:07:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05837 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Summary of Mail and Messaging Standards
Author(s) : P. Robinson
Filename : draft-robinson-mail-summary-00.txt
Pages : 46
Date : 08/10/1994
Several RFCs define all of the standards having to do with the format,
transfer and management of E-mail and messages. So many are out there that
it is often difficult to find out where a specific item is. This memo is
an attempt to give the reader a general overview of the material and to
show where to look for particular information on mail and messaging
standards.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-mail-summary-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-mail-summary-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810172757.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-mail-summary-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-mail-summary-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810172757.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06137;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04397;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06057;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05808;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-howes-x500-schema-02.txt
Date: Thu, 11 Aug 94 11:07:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05808 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Procedures for Formalizing, Evolving, and Maintaining
the Internet X.500 Directory Schema
Author(s) : T. Howes, K. Rossen, S. Sataluri, R. Wright
Filename : draft-howes-x500-schema-02.txt
Pages : 5
Date : 08/10/1994
The IETF Schema BOF proposes a set of procedures for reviewing,
publicizing, and maintaining schema elements for use in Internet
applications using OSI Directory Services (X.500).
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-howes-x500-schema-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-howes-x500-schema-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810172137.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-howes-x500-schema-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-howes-x500-schema-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810172137.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06137;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04397;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06057;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05808;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-howes-x500-schema-02.txt
Date: Thu, 11 Aug 94 11:07:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05808 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Procedures for Formalizing, Evolving, and Maintaining
the Internet X.500 Directory Schema
Author(s) : T. Howes, K. Rossen, S. Sataluri, R. Wright
Filename : draft-howes-x500-schema-02.txt
Pages : 5
Date : 08/10/1994
The IETF Schema BOF proposes a set of procedures for reviewing,
publicizing, and maintaining schema elements for use in Internet
applications using OSI Directory Services (X.500).
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-howes-x500-schema-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-howes-x500-schema-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810172137.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-howes-x500-schema-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-howes-x500-schema-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810172137.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06154;
11 Aug 94 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06123;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04395;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06061;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05861;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-newtelex-00.txt
Date: Thu, 11 Aug 94 11:07:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05861 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Relationship of Telex Answerback Codes to
Internet Domains (2nd Revision)
Author(s) : P. Robinson
Filename : draft-robinson-newtelex-00.txt
Pages : 62
Date : 08/10/1994
This memo provides a major revision to my Internet RFC 1394 by: including
new information which was not available to me when the original document
was released; changes to old information due to the destruction of the
Soviet Union, East Germany and Yugoslavia, and the Balkanization of
Czechslovakia; corrects minor format errors; corrects some
misunderstandings which occurred from some people's misreading of the
original RFC document; and removes some omissions which occurred in the
original RFC. As the corrections (including a whole new set of information
which is added to the original document) are substantial, the original RFC
1394 will be obsoleted rather than revised when this document is published
as an RFC.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-newtelex-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-newtelex-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810173336.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-newtelex-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-newtelex-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810173336.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06174;
11 Aug 94 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06137;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04397;
11 Aug 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06057;
11 Aug 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05808;
11 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-howes-x500-schema-02.txt
Date: Thu, 11 Aug 94 11:07:17 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408111107.aa05808 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Procedures for Formalizing, Evolving, and Maintaining
the Internet X.500 Directory Schema
Author(s) : T. Howes, K. Rossen, S. Sataluri, R. Wright
Filename : draft-howes-x500-schema-02.txt
Pages : 5
Date : 08/10/1994
The IETF Schema BOF proposes a set of procedures for reviewing,
publicizing, and maintaining schema elements for use in Internet
applications using OSI Directory Services (X.500).
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-howes-x500-schema-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-howes-x500-schema-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940810172137.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-howes-x500-schema-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-howes-x500-schema-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940810172137.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07530;
11 Aug 94 12:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07526;
11 Aug 94 12:35 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa06396;
11 Aug 94 12:35 EDT
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9j) with SMTP id LAA06316; Thu, 11 Aug 1994 11:22:12 -0500
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA03481; Thu, 11 Aug 1994 11:21:28 +0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA03476; Thu, 11 Aug 1994 11:21:26 +0600
Received: from sheba.arc.nasa.gov (sheba.arc.nasa.gov [128.102.128.57]) by timbuk.cray.com (8.6.9/8.6.9j) with ESMTP id LAA06270 for <telnet-ietf at cray.com>; Thu, 11 Aug 1994 11:21:25 -0500
Received: by sheba.arc.nasa.gov (8.6.8/1.2); Thu, 11 Aug 1994 09:20:30 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steven Schoch <schoch at sheba.arc.nasa.gov>
Message-Id: <9408110920.ZM12629 at sheba.arc.nasa.gov>
Date: Thu, 11 Aug 1994 09:20:29 -0700
X-Face: K5i!Jd+&(ULhqxHaUa]Io_ZJ{~+aY1~TjL=!DDsksqJj!y<s[@<zQ1XL"b;4U\{I:u':uZZ>Fr=8[Po(4Xy,'bN>>b$8D#!GRdXO/}t=q}%T5ZxA$4P at +[hJAs7x]|+ChBdurcJqCO$'tWhNO^Y%va%r)pj!J5\zX=1s8"
X-Mailer: Z-Mail (3.0.1 23feb94)
To: telnet-ietf at cray.com
Subject: Telnet Authentication: Simple-Strong Authentication
Cc: telnet at sheba.arc.nasa.gov
Mime-Version: 1.0
Encoding: 2 TEXT BOUNDARY, 9 MESSAGE, 2 TEXT BOUNDARY, 82 MESSAGE, 3 TEXT BOUNDARY
Content-Type: multipart/mixed;
boundary="PART-BOUNDARY=.19408110920.ZM12629.arc.nasa.gov"
Content-Length: 3497
--
--PART-BOUNDARY=.19408110920.ZM12629.arc.nasa.gov
Encoding: 6 TEXT
Content-Type: text/plain; charset=us-ascii
We have a working implementation of Telnet Authentication using the
Simple-Strong Authentication method. I would like to see this proposed
as an internet-draft. Can I get some feedback from the IETF group on this?
Thanks.
Steve
--PART-BOUNDARY=.19408110920.ZM12629.arc.nasa.gov
Encoding: 77 text
X-Zm-Content-Name: ssa.txt
Content-Description: draft-ietf-X-ssa-00.txt
Content-Type: text/plain ; charset=us-ascii
Steven Schoch
NASA Ames
August 1994
Telnet Authentication: Simple-Strong Authentication
1. Command Names and Codes
Authentication Types
SSA 23 (this number may change!)
2. Command Meanings
IAC SB AUTHENTICATION IS <authentication-type-pair> <SSA token> IAC SE
This is used to pass the Simple-Strong Authentication token to
the remote side of the connection. The first octet of the
<authentication-type-pair> value is SSA, to indicate the use of
the Simple-Strong Authentication method.
The format of the Simple-Strong Authentication token is defined
as the "Authentication Value" in the NIST document "Output from
the March 1994 OSE Implementors Workshop", part 12, section
9.1.1.1, and the X.511 standard (ISO9594-3). For the purposes of
the telnet protocol, the "certification-path" element of
"StrongCredentials" is not OPTIONAL.
The token will be encoded using the ASN.1 Basic Encoding Rules (BER).
Currently, the Simple-Strong-Authentication method only supports
one-way authentication. Therefore the second octet of the
<authentication-type-pair> must be AUTH_HOW_ONE_WAY.
3. Implementation Rules
Because the purpose of this authentication type is to avoid sending
clear-text passwords over the network, it is recommended that the
client only send "Authentication-Value" tokens of type "Strong", not
"Simple". This implies that the more-restrictive Distinguished
Encoding Rules (DER) as defined in X.509 (ISO9594-8) be used.
The "Strong" authentication token has the "Intended-Recipient" as
one of its elements. Possible values for this element are the
pseudo-DN "@o=Internet at presentationAddress=Internet=<IP address>"
where <IP address> is the IP address of the server to which the
client is connected, the pesudo-DN "@cn=<host.domain-name>" where
<host.domain-name> is the fully-qualified domain name of the server,
or a real DN that has been assigned to the server. Another possibility
is to use a DN as specified in RFC-1608 or RFC-1609.
The server will determine the identity of the sender of the token
from the subject of the certificate sent as the first element of the
"Certification-Path". If no IAC SB AUTHENTICATION NAME has been
sent by the client, the server determines the user name by referring
to a table that maps DNs to user names. If an IAC SB AUTHENTICATION
NAME has been sent, the server determines whether the sender of the
token is authorized to login as the user name by referring to a
(possibly different) table which contains a list of possible user names
for each DN.
Author's Address
Steven Schoch NASA
Ames Research Center
m/s 233-18
Moffett Field, CA 94035
Phone: (415) 604-4121
EMail: schoch at sheba.arc.nasa.gov
--PART-BOUNDARY=.19408110920.ZM12629.arc.nasa.gov--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10138;
11 Aug 94 14:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10152;
11 Aug 94 14:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10121;
11 Aug 94 14:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09906;
11 Aug 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09911;
11 Aug 94 14:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09900;
11 Aug 94 14:43 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: thinosi at ulcc.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Octet sequences for upper-layer OSI to support
basic communications applications to Informational
Date: Thu, 11 Aug 94 14:43:31 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111443.aa09900 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "Octet sequences for
upper-layer OSI to support basic communications applications"
<draft-ietf-thinosi-cookbook-03.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. This
document is the product of the Minimal OSI Upper-Layers
Working Group. The IESG contact person is Allison Mankin.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10138;
11 Aug 94 14:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10152;
11 Aug 94 14:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10121;
11 Aug 94 14:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09906;
11 Aug 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09911;
11 Aug 94 14:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09900;
11 Aug 94 14:43 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: thinosi at ulcc.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Octet sequences for upper-layer OSI to support
basic communications applications to Informational
Date: Thu, 11 Aug 94 14:43:31 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111443.aa09900 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "Octet sequences for
upper-layer OSI to support basic communications applications"
<draft-ietf-thinosi-cookbook-03.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. This
document is the product of the Minimal OSI Upper-Layers
Working Group. The IESG contact person is Allison Mankin.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10152;
11 Aug 94 14:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10138;
11 Aug 94 14:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10152;
11 Aug 94 14:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10121;
11 Aug 94 14:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09906;
11 Aug 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09911;
11 Aug 94 14:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09900;
11 Aug 94 14:43 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: thinosi at ulcc.ac.uk
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Octet sequences for upper-layer OSI to support
basic communications applications to Informational
Date: Thu, 11 Aug 94 14:43:31 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111443.aa09900 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "Octet sequences for
upper-layer OSI to support basic communications applications"
<draft-ietf-thinosi-cookbook-03.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. This
document is the product of the Minimal OSI Upper-Layers
Working Group. The IESG contact person is Allison Mankin.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10177;
11 Aug 94 14:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10192;
11 Aug 94 14:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10143;
11 Aug 94 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10062;
11 Aug 94 14:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10086;
11 Aug 94 14:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10055;
11 Aug 94 14:47 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: isn-wg at unmvma.unm.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: K-12 Internetworking Guidelines to Informational
Date: Thu, 11 Aug 94 14:47:43 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111447.aa10055 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "K-12 Internetworking
Guidelines" <draft-ietf-isn-k12-guide-01.txt, .ps> and recommends
that it be published by the RFC Editor as an Informational RFC.
This document is the product of the Internet School Networking
Working Group. The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10177;
11 Aug 94 14:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10192;
11 Aug 94 14:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10143;
11 Aug 94 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10062;
11 Aug 94 14:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10086;
11 Aug 94 14:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10055;
11 Aug 94 14:47 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: isn-wg at unmvma.unm.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: K-12 Internetworking Guidelines to Informational
Date: Thu, 11 Aug 94 14:47:43 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111447.aa10055 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "K-12 Internetworking
Guidelines" <draft-ietf-isn-k12-guide-01.txt, .ps> and recommends
that it be published by the RFC Editor as an Informational RFC.
This document is the product of the Internet School Networking
Working Group. The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10188;
11 Aug 94 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10177;
11 Aug 94 14:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10192;
11 Aug 94 14:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10143;
11 Aug 94 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10062;
11 Aug 94 14:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10086;
11 Aug 94 14:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10055;
11 Aug 94 14:47 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: isn-wg at unmvma.unm.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: K-12 Internetworking Guidelines to Informational
Date: Thu, 11 Aug 94 14:47:43 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111447.aa10055 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "K-12 Internetworking
Guidelines" <draft-ietf-isn-k12-guide-01.txt, .ps> and recommends
that it be published by the RFC Editor as an Informational RFC.
This document is the product of the Internet School Networking
Working Group. The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10296;
11 Aug 94 14:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10290;
11 Aug 94 14:57 EDT
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa10381;
11 Aug 94 14:57 EDT
Via: uk.ac.ulcc.vmsfe; Thu, 11 Aug 1994 19:57:36 +0100
Via: UK.AC.NSFNET-RELAY; Thu, 11 Aug 94 19:49 GMT
Received: from ietf.cnri.reston.va.us by sun3.nsfnet-relay.ac.uk
with Internet SMTP id <sg.25955-0 at sun3.nsfnet-relay.ac.uk>;
Thu, 11 Aug 1994 19:47:59 +0100
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09900;
11 Aug 94 14:43 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: thinosi at ulcc.ac.uk
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: Octet sequences for upper-layer OSI to support basic
communications applications to Informational
Date: Thu, 11 Aug 94 14:43:31 -0400
Original-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408111443.aa09900 at IETF.CNRI.Reston.VA.US>
X-Orig-Sender: thinosi-request at ulcc.ac.uk
X-ULCC-Sequence: 208
X-ULCC-Recipient: ietf-archive%us.va.reston.cnri at uk.ac.nsfnet-relay
The IESG has reviewed the Internet-Draft "Octet sequences for
upper-layer OSI to support basic communications applications"
<draft-ietf-thinosi-cookbook-03.txt> and recommends that it be
published by the RFC Editor as an Informational RFC. This
document is the product of the Minimal OSI Upper-Layers
Working Group. The IESG contact person is Allison Mankin.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11962;
11 Aug 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13298;
11 Aug 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11935;
11 Aug 94 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11756;
11 Aug 94 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13144;
11 Aug 94 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08193>; Thu, 11 Aug 1994 13:26:32 -0700
Message-Id: <199408112026.AA08193 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1666 on SNANAU MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:27:01 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1666:
Title: Definitions of Managed Objects
for SNA NAUs using SMIv2
Author: Z. Kielczewski, D. Kostick & Shih, Editors
Mailbox: zbig at eicon.qc.ca, dck2 at mail.bellcore.com,
kmshih at novell.com
Pages: 68
Characters: 134,385
Obsoletes: 1665
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing the configuration,
monitoring and control of Physical Units (PUs) and Logical Units (LUs)
in an SNA (Systems Network Architecture) environment. PUs and LUs are
two types of Network Addressable Units (NAUs) in the logical structure
of an SNA network. NAUs are the origination or destination points for
SNA data streams. This memo identifies managed objects for PU Type
1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic
objects defined here can also be used to manage LU 6.2 and any LU-LU
session. This RFC is the product of the SNA NAU Services MIB Working
Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811132412.RFC at ISI.EDU>
SEND /rfc/rfc1666.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1666.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811132412.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11962;
11 Aug 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13298;
11 Aug 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11935;
11 Aug 94 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11756;
11 Aug 94 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13144;
11 Aug 94 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08193>; Thu, 11 Aug 1994 13:26:32 -0700
Message-Id: <199408112026.AA08193 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1666 on SNANAU MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:27:01 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1666:
Title: Definitions of Managed Objects
for SNA NAUs using SMIv2
Author: Z. Kielczewski, D. Kostick & Shih, Editors
Mailbox: zbig at eicon.qc.ca, dck2 at mail.bellcore.com,
kmshih at novell.com
Pages: 68
Characters: 134,385
Obsoletes: 1665
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing the configuration,
monitoring and control of Physical Units (PUs) and Logical Units (LUs)
in an SNA (Systems Network Architecture) environment. PUs and LUs are
two types of Network Addressable Units (NAUs) in the logical structure
of an SNA network. NAUs are the origination or destination points for
SNA data streams. This memo identifies managed objects for PU Type
1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic
objects defined here can also be used to manage LU 6.2 and any LU-LU
session. This RFC is the product of the SNA NAU Services MIB Working
Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811132412.RFC at ISI.EDU>
SEND /rfc/rfc1666.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1666.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811132412.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11979;
11 Aug 94 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11962;
11 Aug 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13298;
11 Aug 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11935;
11 Aug 94 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11756;
11 Aug 94 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13144;
11 Aug 94 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08193>; Thu, 11 Aug 1994 13:26:32 -0700
Message-Id: <199408112026.AA08193 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1666 on SNANAU MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:27:01 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1666:
Title: Definitions of Managed Objects
for SNA NAUs using SMIv2
Author: Z. Kielczewski, D. Kostick & Shih, Editors
Mailbox: zbig at eicon.qc.ca, dck2 at mail.bellcore.com,
kmshih at novell.com
Pages: 68
Characters: 134,385
Obsoletes: 1665
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing the configuration,
monitoring and control of Physical Units (PUs) and Logical Units (LUs)
in an SNA (Systems Network Architecture) environment. PUs and LUs are
two types of Network Addressable Units (NAUs) in the logical structure
of an SNA network. NAUs are the origination or destination points for
SNA data streams. This memo identifies managed objects for PU Type
1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic
objects defined here can also be used to manage LU 6.2 and any LU-LU
session. This RFC is the product of the SNA NAU Services MIB Working
Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811132412.RFC at ISI.EDU>
SEND /rfc/rfc1666.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1666.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811132412.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12071;
11 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13358;
11 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12039;
11 Aug 94 16:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11904;
11 Aug 94 16:29 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13259;
11 Aug 94 16:29 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08261>; Thu, 11 Aug 1994 13:29:55 -0700
Message-Id: <199408112029.AA08261 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1676 on INFN Requirements for an IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:30:24 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1676:
Title: INFN Requirements for an IPng
Author: A. Ghiselli, D. Salomoni & C. Vistoli
Mailbox: Salomoni at infn.it, Vistoli at infn.it,
Ghiselli at infn.it
Pages: 4
Characters: 8,493
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper is sent by INFN network team, the Italian National
Institute for nuclear physics, whose network, named INFNet, is a
nationwide network founded to provide the access to existing national
and international HEP laboratory and to facilitate communications
between the researchers. With this paper we would like to emphasize
the key points that we would to consider if charged with IPng plan. We
do not really expect to add original items to the selection, but we
think that it could be useful to submit the opinions and ideas that
come from our network experience.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811132741.RFC at ISI.EDU>
SEND /rfc/rfc1676.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1676.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811132741.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12071;
11 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13358;
11 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12039;
11 Aug 94 16:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11904;
11 Aug 94 16:29 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13259;
11 Aug 94 16:29 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08261>; Thu, 11 Aug 1994 13:29:55 -0700
Message-Id: <199408112029.AA08261 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1676 on INFN Requirements for an IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:30:24 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1676:
Title: INFN Requirements for an IPng
Author: A. Ghiselli, D. Salomoni & C. Vistoli
Mailbox: Salomoni at infn.it, Vistoli at infn.it,
Ghiselli at infn.it
Pages: 4
Characters: 8,493
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper is sent by INFN network team, the Italian National
Institute for nuclear physics, whose network, named INFNet, is a
nationwide network founded to provide the access to existing national
and international HEP laboratory and to facilitate communications
between the researchers. With this paper we would like to emphasize
the key points that we would to consider if charged with IPng plan. We
do not really expect to add original items to the selection, but we
think that it could be useful to submit the opinions and ideas that
come from our network experience.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811132741.RFC at ISI.EDU>
SEND /rfc/rfc1676.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1676.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811132741.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12082;
11 Aug 94 16:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12071;
11 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13358;
11 Aug 94 16:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12039;
11 Aug 94 16:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11904;
11 Aug 94 16:29 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13259;
11 Aug 94 16:29 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08261>; Thu, 11 Aug 1994 13:29:55 -0700
Message-Id: <199408112029.AA08261 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1676 on INFN Requirements for an IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:30:24 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1676:
Title: INFN Requirements for an IPng
Author: A. Ghiselli, D. Salomoni & C. Vistoli
Mailbox: Salomoni at infn.it, Vistoli at infn.it,
Ghiselli at infn.it
Pages: 4
Characters: 8,493
Updates/Obsoletes: none
This document was submitted to the IETF IPng area in response to
RFC 1550. Publication of this document does not imply acceptance
by the IPng area of any ideas expressed within. Comments should
be submitted to the big-internet at munnari.oz.au mailing list.
This white paper is sent by INFN network team, the Italian National
Institute for nuclear physics, whose network, named INFNet, is a
nationwide network founded to provide the access to existing national
and international HEP laboratory and to facilitate communications
between the researchers. With this paper we would like to emphasize
the key points that we would to consider if charged with IPng plan. We
do not really expect to add original items to the selection, but we
think that it could be useful to submit the opinions and ideas that
come from our network experience.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811132741.RFC at ISI.EDU>
SEND /rfc/rfc1676.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1676.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811132741.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12230;
11 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13575;
11 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12216;
11 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12120;
11 Aug 94 16:33 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13473;
11 Aug 94 16:33 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08354>; Thu, 11 Aug 1994 13:33:44 -0700
Message-Id: <199408112033.AA08354 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1688 on IPng Mobility
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:34:12 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1688:
Title: IPng Mobility Considerations
Author: W. Simpson
Mailbox: Bill.Simpson at um.cc.umich.edu
Pages: 9
Characters: 19,151
Updates/Obsoletes: none
This document was submitted to the IPng Area in response to RFC 1550.
Publication of this document does not imply acceptance by the IPng
Area of any ideas expressed within. Comments should be submitted to
the big-internet at munnari.oz.au mailing list. This RFC specifies
criteria related to mobility for consideration in design and selection
of the Next Generation of IP.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811133058.RFC at ISI.EDU>
SEND /rfc/rfc1688.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1688.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811133058.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12230;
11 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13575;
11 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12216;
11 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12120;
11 Aug 94 16:33 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13473;
11 Aug 94 16:33 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08354>; Thu, 11 Aug 1994 13:33:44 -0700
Message-Id: <199408112033.AA08354 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1688 on IPng Mobility
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:34:12 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1688:
Title: IPng Mobility Considerations
Author: W. Simpson
Mailbox: Bill.Simpson at um.cc.umich.edu
Pages: 9
Characters: 19,151
Updates/Obsoletes: none
This document was submitted to the IPng Area in response to RFC 1550.
Publication of this document does not imply acceptance by the IPng
Area of any ideas expressed within. Comments should be submitted to
the big-internet at munnari.oz.au mailing list. This RFC specifies
criteria related to mobility for consideration in design and selection
of the Next Generation of IP.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811133058.RFC at ISI.EDU>
SEND /rfc/rfc1688.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1688.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811133058.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12241;
11 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12230;
11 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13575;
11 Aug 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12216;
11 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12120;
11 Aug 94 16:33 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13473;
11 Aug 94 16:33 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08354>; Thu, 11 Aug 1994 13:33:44 -0700
Message-Id: <199408112033.AA08354 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1688 on IPng Mobility
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 11 Aug 94 13:34:12 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1688:
Title: IPng Mobility Considerations
Author: W. Simpson
Mailbox: Bill.Simpson at um.cc.umich.edu
Pages: 9
Characters: 19,151
Updates/Obsoletes: none
This document was submitted to the IPng Area in response to RFC 1550.
Publication of this document does not imply acceptance by the IPng
Area of any ideas expressed within. Comments should be submitted to
the big-internet at munnari.oz.au mailing list. This RFC specifies
criteria related to mobility for consideration in design and selection
of the Next Generation of IP.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940811133058.RFC at ISI.EDU>
SEND /rfc/rfc1688.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1688.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940811133058.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13323;
11 Aug 94 17:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13315;
11 Aug 94 17:10 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14283;
11 Aug 94 17:10 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA00609 at pad-thai.aktis.com>; Thu, 11 Aug 1994 16:45:32 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA06632; Thu, 11 Aug 94 16:44:07 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <27420-0 at relay1.pipex.net>; Thu, 11 Aug 1994 21:39:06 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA11035; Thu, 11 Aug 94 21:40:45 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA07324;
Thu, 11 Aug 94 21:37:47 BST
Message-Id: <9408112040.AA17161 at getafix.oasis.icl.co.uk>
Date: Thu, 11 Aug 94 21:40:25 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Windows 3.1 client GSS-API
To: cat-ietf at mit.edu
> The other thing that I-D should do is nail down enough things so that we
> can actually put together a DLL (dynamic link library) interface
> standard. This would require nailing down the platform/mechanism
> specific types which are delibarately left unspecified under RFC1509.
> We should probably make them be void *'s, so that an implementation
> still has some flexibility about what it needs to store.
Iff this requirement isn't contentious - implying a trivial code change for
existing implementations, and a recompile for existing applications - then
agreement on a link-level compatibility standard is achievable.
With this wider scope, I think that there would be enough material to make
a separate document warranted. Unless anyone else wants to volunteer, I will
try to post a proposal in the next week or so.
[BTW: I would suggest that passing in these implementation-dependent types
by reference is an improving (as opposed to bastardizing) delta to
RFC1509.
It wouldn't be a bad idea for ANSI C GSS-API either - for the same reasons -
but such a change is probably too late now.]
Piers
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15999;
11 Aug 94 20:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18566;
11 Aug 94 20:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15986;
11 Aug 94 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15938;
11 Aug 94 20:39 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18495;
11 Aug 94 20:39 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA14374>; Thu, 11 Aug 1994 17:39:45 -0700
Message-Id: <199408120039.AA14374 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: cooper at isi.edu, IETF-Announce: ;
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and EMAIL
Reply-To: cooper at isi.edu
Date: Thu, 11 Aug 94 17:39:45 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using RFC-INFO Service
------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at cnri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the IMRs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9407
--OtherAccess
Content-Type: Message/External-body;
name="imr9407.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15999;
11 Aug 94 20:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18566;
11 Aug 94 20:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15986;
11 Aug 94 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15938;
11 Aug 94 20:39 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18495;
11 Aug 94 20:39 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA14374>; Thu, 11 Aug 1994 17:39:45 -0700
Message-Id: <199408120039.AA14374 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: cooper at isi.edu, IETF-Announce: ;
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and EMAIL
Reply-To: cooper at isi.edu
Date: Thu, 11 Aug 94 17:39:45 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using RFC-INFO Service
------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at cnri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the IMRs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9407
--OtherAccess
Content-Type: Message/External-body;
name="imr9407.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16010;
11 Aug 94 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15999;
11 Aug 94 20:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18566;
11 Aug 94 20:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15986;
11 Aug 94 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15938;
11 Aug 94 20:39 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa18495;
11 Aug 94 20:39 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA14374>; Thu, 11 Aug 1994 17:39:45 -0700
Message-Id: <199408120039.AA14374 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: cooper at isi.edu, IETF-Announce: ;
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and EMAIL
Reply-To: cooper at isi.edu
Date: Thu, 11 Aug 94 17:39:45 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using RFC-INFO Service
------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at cnri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the IMRs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9407
--OtherAccess
Content-Type: Message/External-body;
name="imr9407.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06394;
12 Aug 94 13:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06383;
12 Aug 94 13:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11279;
12 Aug 94 13:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06342;
12 Aug 94 13:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06075;
12 Aug 94 12:43 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa10894;
12 Aug 94 12:42 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA28614>; Fri, 12 Aug 1994 09:42:18 -0700
Message-Id: <199408121642.AA28614 at zephyr.isi.edu>
To: ietf at CNRI.Reston.VA.US
Cc: cooper at isi.edu
Subject: Internet Monthly Report - Jully 1994
Reply-To: cooper at isi.edu
Date: Fri, 12 Aug 94 09:42:17 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
July 1994
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to:
Ann Westine Cooper (Cooper at ISI.EDU)
NSF Regional reports - To obtain the procedure describing how to
submit information for the Internet Monthly Report, send an email
message to mailserv at is.internic.net and put "send imr-procedure" in
the body of the message (add only that one line; do not put a
signature).
!Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
Details on obtaining the current IMR, or back issues, via FTP or
EMAIL may be obtained by sending an EMAIL message to "rfc-
info at ISI.EDU" with the message body "help: ways_to_get_imrs". For
example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
Cooper [Page 1]
Internet Monthly Report July 1994
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
INTERNET RESEARCH REPORTS . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
ANSNET/NSFNET BACKBONE ENGINEERING . . . . . . . . . . . page 9
BOLT BERANEK AND NEWMAN, INC., . . . . . . . . . . . . . page 12
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 13
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 18
MERIT/NSFNET ENGINEERING. . . . . . . . . . . . . . . . . page 26
NEARNET . . . . . . . . . . . . . . . . . . . . . . . . . page 27
NORTHWESTNET . . . . . . . . . . . . . . . . . . . . . . page 29
NYSERNET. . . . . . . . . . . . . . . . . . . . . . . . . page 29
PREPnet . . . . . . . . . . . . . . . . . . . . . . . . . page 32
RARE SECRETARIAT. . . . . . . . . . . . . . . . . . . . . page 34
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 38
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . page 39
Rare List of Meetings . . . . . . . . . . . . . . . . . page 42
Cooper [Page 2]
Internet Monthly Report July 1994
INTERNET RESEARCH REPORTS
- -------------------------
INTERNET ENGINEERING REPORTS
- ----------------------------
1. The 30th meeting of the IETF was held in Toronto, Ontario,
Canada from July 25 through July 29, 1994. The meeting was
hosted by The University of Toronto. Though not yet final,
there were over 700 attendees.
The next IETF meeting will be in San Jose, California from
December 5-9, 1994. Following that, the IETF will be meeting in
Danvers (a suburb of Boston) from April 3-7, 1995. We currently
working on the summer IETF meeting to be held in Stockholm,
Sweden. Once all the arrangements have been made, notifications
will be sent to the IETF Announcement list. Remember that
information on future IETF meetings can be always be found in
the file 0mtg-sites.txt which is located on the IETF shadow
directories.
2. The IETF Secretariat has joined the Web! The URL for the IETF
Home Page is "http://www.ietf.cnri.reston.va.us/home.html"; and
contains information on IETF Working Groups, Internet-Drafts,
RFCs, etc. The proceedings from the Seattle IETF meeting (March,
1994) are on the Web as well.
3. The IESG approved or recommended the following four Protocol
Actions during the month of July, 1994:
o Definitions of Managed Objects for SMDS Interface is a Draft
Standard.
o Definitions of Managed Objects for ATM Management Version
8.0 is a Proposed Standard.
o RDBMS-MIB is a Proposed Standard.
o Modem MIB is a Proposed Standard.
4. The IESG issued one Last Call to the IETF during the month of
July, 1994:
o Post Office Protocol - Version 3 <draft-rose-pop3-again-03>
for consideration as a Draft Standard.
Cooper [Page 3]
Internet Monthly Report July 1994
5. One Working Group was created during this period:
Mail Extensions (mailext)
Additionally, one Working Groups was concluded:
Character MIB (charmib)
6. A total of 75 Internet-Draft actions were taken during the month
of July, 1994:
(Revised draft (o), New Draft (+) )
WG I-D Title <Filename>
------ -----------------------------------------------------
(isis) o Integrated IS-IS Management Information Base
<draft-ietf-isis-mib-04.txt>
(mhsds) o Representing Tables and Subtrees in the Directory
<draft-ietf-mhsds-subtrees-05.txt, .ps>
(mhsds) o Representing the O/R Address hierarchy in the
Directory Information Tree
<draft-ietf-mhsds-infotree-05.txt, .ps>
(mhsds) o Use of the Directory to support mapping between
X.400 and RFC 822 Addresses
<draft-ietf-mhsds-supmapping-05.txt, .ps>
(mhsds) o MHS use of Directory to support MHS Routing
<draft-ietf-mhsds-routdirectory-05.txt, .ps>
(bgp) o BGP4/IDRP for IP---OSPF Interaction
<draft-ietf-bgp-bgp4ospf-interact-04.txt>
(ospf) o OSPF Version 2 Management Information Base
<draft-ietf-ospf-mib-04.txt>
(pem) o PEM Security Services and MIME
<draft-ietf-pem-mime-06.txt>
(avt) o RTP: A Transport Protocol for Real-Time Applications
<draft-ietf-avt-rtp-05.txt, .ps>
(isis) o Use of OSI IS-IS for Routing in TCP/IP and
Multi-Protocol Environments
<draft-ietf-isis-tcpip-01.txt>
(rolc) o NBMA Next Hop Resolution Protocol (NHRP)
<draft-ietf-rolc-nhrp-01.txt>
(uri) o Uniform Resource Locators (URL)
<draft-ietf-uri-url-04.txt>
(mhsds) o Introducing Project Long Bud: Internet Pilot Project
for the Deployment of X.500 Directory Information
in Support of X.400 Routing
<draft-ietf-mhsds-long-bud-intro-01.txt>
Cooper [Page 4]
Internet Monthly Report July 1994
(wnils) o Whois and Network Information Lookup Service Whois++
<draft-ietf-wnils-whois-lookup-01.txt>
(none) o Internet Authentication Guidelines
<draft-haller-auth-requirements-05.txt>
(notary) o An Extensible Message Format for Delivery Status
Notifications
<draft-ietf-notary-mime-delivery-02.txt>
(ripv2) o RIP Version 2 Carrying Additional Information
<draft-ietf-ripv2-protocol-01.txt>
(ifmib) o Management Information Base for Management of
Network Connections
<draft-ietf-ifmib-conntable-02.txt>
(svrloc) o Service Location Protocol
<draft-ietf-svrloc-protocol-04.txt>
(pppext) o PPP Stacker LZS Compression Protocol
<draft-ietf-pppext-stacker-01.txt>
(ripv2) o RIP Version 2 MIB Extension
<draft-ietf-ripv2-mibext2-01.txt>
(rsvp) o Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification
<draft-ietf-rsvp-spec-03.txt, .ps>
(osids) o Connection-less Lightweight Directory Access
Protocol <draft-ietf-osids-cldap-01.txt>
(none) o Post Office Protocol - Version 3
<draft-rose-pop3-again-03.txt>
(sipp) o Simple Internet Protocol Plus (SIPP): Addressing
Architecture <draft-ietf-sipp-routing-addr-02.txt>
(imap) o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
<draft-ietf-imap-imap4-04.txt>
(ospf) o IP Forwarding Table MIB
<draft-ietf-ospf-cidr-route-mib-03.txt>
(sipp) o Simple Internet Protocol Plus (SIPP) Specification
(128-bit address version)
<draft-ietf-sipp-spec-01.txt>
(isn) o K-12 Internetworking Guidelines
<draft-ietf-isn-k12-guide-01.txt, .ps>
(none) o Conventional IP over ATM
<draft-ohta-ip-over-atm-01.txt>
(cat) o The Kerberos Version 5 GSS-API Mechanism
<draft-ietf-cat-kerb5gss-01.txt>
(tuba) o Transition Plan for TUBA/CLNP
<draft-ietf-tuba-transition-01.txt>
(isis) o Integrated ISIS Protocol Analysis
<draft-ietf-isis-prot-anal-01.txt>
(isis) o Experience with the Integrated ISIS Protocol
<draft-ietf-isis-opexp-01.txt>
(none) o Requirements for Uniform Resource Names
<draft-sollins-urn-01.txt>
Cooper [Page 5]
Internet Monthly Report July 1994
(mobileip) o IP Mobility Support
<draft-ietf-mobileip-protocol-05.txt>
(none) o Procedures for Formalizing, Evolving, and
Maintaining the Internet X.500 Directory Schema
<draft-howes-x500-schema-01.txt>
(ipatm) o ATM Signaling Support for IP over ATM
<draft-ietf-ipatm-sig-01.txt>
(pppext) o Proposal for Callback Control Protocol (CBCP).
<draft-ietf-pppext-callback-cp-02.txt>
(pem) o Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted <draft-ietf-pem-sigenc-01.txt>
(printmib) o Printer MIB <draft-ietf-printmib-printer-mib-02.txt>
(none) o Shared Media Architecture for the Internet
<draft-ohta-shared-media-01.txt>
(none) o Socks Protocol Version 4
<draft-leech-socks-protocol-v4-01.txt>
(none) + Accounting Meter Services MIB
<draft-brownlee-acct-meter-mib-00.txt>
(none) + BigTen (BT) Packet Format
<draft-ford-bigten-bt-format-00.txt>
(sdr) + SDRP Route Construction
<draft-ietf-sdr-route-construction-00.txt, .ps>
(cat) + The Simple Public-Key GSS-API Mechanism (SPKM)
<draft-ietf-cat-spkmgss-00.txt>
(none) + A Primer On Internet and TCP/IP Tools (DRAFT)
<draft-ietf-uswg-primer-00.txt>
(uri) + Encoding and Use of Uniform Resource Characteristics
<draft-ietf-uri-urc-spec-00.txt>
(ifmib) + IEEE 802.5 MIB
<draft-ietf-ifmib-tokenringmib-00.txt>
(ripv2) o RIP Version 2 Protocol Applicability Statement
<draft-ietf-ripv2-protocol-applic-01.txt>
(none) + PPP Serial Data Transport Protocol (SDTP)
<draft-schneider-ppp-sdtp-00.txt>
(dnsind) + Dynamic Updates in the Domain Name System (DNS):
Architecture and Mechanism
<draft-ietf-dnsind-dynDNS-arch-00.txt>
(none) + The Nimrod Routing Architecture
<draft-castineyra-routing-arch-00.txt>
(dnsind) + Implementation of Domain Name System (DNS) Dynamic
Updates <draft-ietf-dnsind-dynDNS-impl-00.txt>
(none) + SC6 Hots up the Pace at its June 20th to 30th
Meeting in Tuusula, Finland
<draft-houldsworth-sc6-hot-finland-00.txt>
(none) + SMTP 521 reply code
<draft-durand-smtp-521-reply-code-00.txt>
(whip) + A Specification for the Simple Internet White Pages
Service. <draft-ietf-whip-iwps-requirements-00.txt>
Cooper [Page 6]
Internet Monthly Report July 1994
(none) + IPng Mobility Considerations
<draft-simpson-ipng-mobility-00.txt>
(sipp) + Simple SIPP Transition (SST) Overview
<draft-ietf-sipp-sst-overview-00.txt>
(idmr) + Internet Group Management Protocol MIB
<draft-ietf-idmr-igmp-mib-00.txt>
(pppext) + The PPP AppleTalk Control Protocol (ATCP)
<draft-ietf-pppext-atcp2-00.txt>
(idmr) + IP Multicast Routing MIB
<draft-ietf-idmr-multicast-routmib-00.txt>
(idmr) + Protocol Independent Multicast MIB
<draft-ietf-idmr-pim-mib-00.txt>
(snanau) + Definitions of Managed Objects for APPC
<draft-ietf-snanau-appcmib-00.txt>
(none) + Dynamic DNS <draft-ohta-dynamic-dns-00.txt>
(none) + Mobility Support for Nimrod : Requirements and
Solution Approaches
<draft-ramanathan-mobility-00.txt, .ps>
(none) + Multicast Support for Nimrod : Requirements and
Solution Approaches
<draft-ramanathan-multicast-00.txt, .ps>
(none) + An Architecture for SIPP-16 Address Allocation
<draft-rekhter-arch-sipp16-addr-00.txt>
(none) + IPng Technical Requirements Of the Nimrod Routing
and Addressing Architecture
<draft-chiappa-ipng-nimrod-arch-00.txt>
(none) + SDRP Routing Header Format for SIPP-16
<draft-ford-sdrp-sipp16-format-00.txt>
(snadlc) + Definitions of Managed Objects for SNA Data Link
Control: LLC <draft-ietf-snadlc-llc-mib-00.txt>
(pppext) + The PPP Banyan Vines Control Protocol (BVCP)
<draft-ietf-pppext-vines-00.txt>
(pppext) + PPP Kerberos version 4 Authentication Protocol
(KAPv4) <draft-ietf-pppext-kapv4-auth-00.txt>
(tuba) + Extensions to MIB-II for TUBA/CLNP systems
<draft-ietf-tuba-mib-00.txt>
7. There were 25 RFC's published during the month of July, 1994:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1610 S (iab) INTERNET OFFICIAL PROTOCOL STANDARDS
RFC1627 I (none) Network 10 Considered Harmful (Some
Practices Shouldn't be Codified)
RFC1641 E (none) Using Unicode with MIME
RFC1642 E (none) UTF-7 - A Mail-Safe Transformation Format
of Unicode
Cooper [Page 7]
Internet Monthly Report July 1994
RFC1643 S (ifmib) Definitions of Managed Objects for the
Ethernet-like Interface Types
RFC1644 E (none) T/TCP -- TCP Extensions for Transactions
Functional Specification
RFC1645 I (none) Simple Network Paging Protocol - Version
2
RFC1646 I (tn3270e) TN3270 Extensions for LUname and Printer
Selection
RFC1647 PS (tn3270e) TN3270 Enhancements
RFC1648 PS (x400ops) Postmaster Convention for X.400
Operations
RFC1649 I (x400ops) Operational Requirements for X.400
Management Domains in the GO-MHS
Community
RFC1651 DS (smtpext) SMTP Service Extensions
RFC1652 DS (smtpext) SMTP Service Extension for
8bit-MIMEtransport
RFC1653 DS (smtpext) SMTP Service Extension for Message Size
Declaration
RFC1654 PS (bgp) A Border Gateway Protocol 4 (BGP-4)
RFC1655 PS (bgp) Application of the Border Gateway
Protocol in the Internet
RFC1656 I (bgp) BGP-4 Protocol Document Roadmap and
Implementation Experience
RFC1657 PS (bgp) Definitions of Managed Objects for the
Fourth Version of the Border Gateway
Protocol (BGP-4) using SMIv2
RFC1658 DS (charmib) Definitions of Managed Objects for
Character Stream Devices using SMIv2
RFC1659 DS (charmib) Definitions of Managed Objects for
RS-232-like Hardware Devices using SMIv2
RFC1660 DS (charmib) Definitions of Managed Objects for
Parallel-printer-like Hardware Devices
using SMIv2
RFC1661 S (pppext) The Point-to-Point Protocol (PPP)
RFC1662 S (pppext) PPP in HDLC-like Framing
RFC1663 PS (pppext) PPP Reliable Transmission
RFC1665 PS (snanau) Definitions of Managed Objects for SNA
NAUs using SMIv2
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya (scoya at cnri.reston.va.us)
Cooper [Page 8]
Internet Monthly Report July 1994
INTERNET PROJECTS
ANSNET/NSFNET BACKBONE ENGINEERING
- ----------------------------------
Network Status Summary
=======================
ANSnet total packet traffic increased by about 1.75% in July'94. An
increase in the ANSnet forwarding table size of .35% was observed
during the month of July.
April Backbone Traffic Statistics
==============================
The total inbound packet count for the ANSnet (measured using SNMP
interface counters) was 62,709,811,154 on T3 ENSS interfaces, up
1.5% from June. The total packet count into the network including
all ENSS serial interfaces was 71,692,393,856 up 1.74% from June.
Router Forwarding Table Statistics
================================
The maximum number of destinations announced to the ANSnet during
July was 17,853 up .35% from June.
The number of network destinations configured for announcement to
the ANSnet but never announced (silent nets) during July was
15,894.
BGP-4/CIDR Deployment Status
============================
No new autonomous systems began exchanging routing information with
ANSnet via the BGP-4 protocol during June.
As of August 9th '94, we have observed the withdrawal of 6,732
class based destinations from the ANSnet router forwarding tables
that are now represented by 1,157 configured aggregates. Among
these configured aggregates:
1,026 of these are top-level aggregates (not nested in another
aggregate).
818 of these are actively announced to ANSnet.
683 of these have at least one subnet configured (the other 135
may be saving the Internet future subnet announcements).
Cooper [Page 9]
Internet Monthly Report July 1994
596 of these have resulted in the withdrawal of at least one
configured more specific route.
583 of these have resulted in the withdrawal of 50% of their
configured more specific routes.
570 of these have resulted in the withdrawal of most (80%+) of
their more specific routes.
For up-to-date information is available from merit.edu:
pub/nsfnet/cidr/cidr-savings.
For further details on these CIDR aggregates, see
merit.edu:pub/nsfnet/cidr/nestings.announced for full listings.
Routing Stability Measured on the T3 Network
============================================
Internal routing stability measurements are made by monitoring
short term disconnect times (disconnects of five minutes duration
or less). This is intended as a measure of overall system
stability rather than complete connectivity. Some instability was
experienced in July mostly due to router restarts required to
accomplish installation of a new AIX build and problems with gated
during reconfiguration. There were also some equipment problems
that caused instability for E222 and E163.
MONTH overall excluding configs
------ ------- -----------------
January 99.1% 99.5%
February 99.0% 99.5%
March 97.5% 99.1%
April 96.1% 97.2%
May 97.4% 98.0%
June 95.5% 96.6%
July 97.3% 97.7%
August 97.5% 97.9%
September 98.1% 98.5%
October 98.0% 98.3%
November 97.2% N/A
December 96.6% N/A
January 98.7% N/A
February 96.6% N/A
...
June 99.5% N/A
July 98.7% N/A
Cooper [Page 10]
Internet Monthly Report July 1994
Monthly histograms of the number of nodes experiencing instability
follows. During July, most of the nodes fell in the 1-2 hour range
due to the AIX deployment and gated reconfiguration problems. This
instability was during the maintenance window.
MONTH >5 hr >2 hr > 1hr >30 min >15 min <= 15min
<98.7% <99.7% <99.87% <99.93% <99.97% >=99.97%
------------------------------------------------------------
January 0 0 1 8 19 55
February 0 0 1 24 19 41
March 0 4 18 23 23 22
April 2 2 3 13 12 57
May 0 4 33 32 15 5
June 3 21 35 18 12 3
July 0 12 28 44 6 1
August 1 5 28 21 17 15
September 1 38 25 10 4 13
October 0 3 3 10 25 50
November 1 2 15 25 24 26
December 0 8 24 46 9 3
January 0 0 4 9 15 54
February 0 4 6 23 40 20
...
June 0 0 0 5 5 67
July 0 7 55 11 10 7
External route flap reports have been rewritten to accomodate
differences in the wayroutes are withdrawn in BGP-4 (there is never
an AS path included) and the support of CIDR. The new reports are
described in:
ftp.ans.net:/pub/info/routing-stats/daily-reports/README
Notable Outages for June '94
==========================
UNAM suffered extended circuit outages on 06/06 and 06/18.
E222 (InterNIC) suffered an extended circuit outage on 06/17.
E158 (MHPCC) suffered an extended outage due to site maintenance on
06/18.
E138 (Atlanta) lost T3 connectivity due to hardware problems on
06/25.
Cooper [Page 11]
Internet Monthly Report July 1994
UNAM suffered an extended outage due to site maintenance on 06/29.
Jordan Becker <becker at ans.net>
BOLT BERANEK AND NEWMAN INC.
- ----------------------------
Current BBN projects include:
"Nimrod," an architecture for next-generation internet routing and
addressing. This month, work continued on defining the functions
and protocols needed to enable interaction among the various Nimrod
components, including entity representatives, association agents,
root agents and forwarding agents. Results of this work were
presented at the Toronto IETF meeting.
Point of contact: Martha Steenstrup, msteenstrup at bbn.com
Enhancements to Inter-Domain Policy Routing. During July, work
progressed on implementation of a parser for handling the new
syntax and grammar for the IDPR configuration file. Various
improvements have been designed to make IDPR configuration easier
to understand and less painful. For example, definition of an
adjacent policy gateway and its connections used to involve
multiple configuration statements that have now been consolidated
into one. Specification of source policies used to require per-
flow definitions, and now, one can state a policy and then list all
the flows to which it applies. There are several similar
improvements that should lead to greater flexibility and reduced
verbosity.
Point of contact: Martha Steenstrup, msteenstrup at bbn.com
Determination of token bucket parameters necessary to meet service
requirements of some observed TCP flows. Results could be used,
for example, to guide the future configuration of traffic-shaping
network interfaces.
Point of contact: Craig Partridge, craig at bbn.com
Enhancing the Flow Synchronization Protocol. Under Arpa funding,
BBN developed a protocol for synchronization of multiple flows
across an internetwork. A common application for this protocol is
lip-sync: synchronization of voice and video flows in a
videoconferencing application over wide area networks. The
protocol does not require the flows' sources or their destinations
to share common hardware. It relies on network clock
synchronization protocols (e.g. NTP) to provide time
Cooper [Page 12]
Internet Monthly Report July 1994
synchronization, and it adaptively equalizes the flows' delays
through the networks to a common end-to-end delay. The adaptation
employed allows interactive applications to reach the most
desirable compromise between degree of synchronization and
resultant end-to-end delay. Experiments to date have demonstrated
lip-synchronization and synchronization of a widely dispersed
musical ensemble. A description of the protocol and these
experiments can be found in the February 1994 issue of the IEEE/ACM
Transactions on Networking (Flow Synchronization Protocol, by
Escobar, Partridge, and Deutsch). This month, work continued on
testing the new GUI-based configuration tool in preparation for a
demonstration to be presented at ACM MultiMedia '94. In addition,
a library of Sync. Protocol code and documentation for implementors
was made available via anonymous ftp.
Point of contact: Julio Escobar, jescobar at bbn.com
Joshua P. Seeger <jseeger at bbn.com>
INTERNIC
- --------
INFORMATION SERVICES
--------------------
Contact Information:
Reference Desk Information
Phone +1 619 455-4600
email info at internic.net
Fax +1 619 455-4640
InterNIC Suggestions or Complaints
Suggestions suggestions at internic.net
Complaints complaints at internic.net
NSF Network News
newsletter subscriptions newsletter-request at internic.net
newsletter comments newsletter-comments at internic.net
NICLink
General Information info at internic.net
Problems/bugs niclink-bugs at is.internic.net
InterNIC Seminar Series
General Information seminars at internic.net
Cooper [Page 13]
Internet Monthly Report July 1994
Listserv lists
net-happenings majordomo at is.internic.net
net-resources majordomo at is.internic.net
scout-report majordomo at is.internic.net
InfoGuide
Host Name is.internic.net
Host Address 192.153.156.15
URL: http://www.internic.net/
Postal address
InterNIC Information Services
General Atomics
P.O. BOX 85608
San Diego, CA 92186-9784
THE InterNIC INFOGUIDE
Usage of the InterNIC InfoGuide has been growing weekly since its
debut. It is now consistently getting over 20,000 accesses per week.
The net- happings index (which is updated daily) and the Scout Report
are among its most popular items. A new area was added to the IETF
User Services Working Group.
The InterNIC InfoGuide is a comprehensive online information service
which provides information about the Internet and online Internet
resources. Accessible through gopher and the WorldWideWeb, the
InterNIC InfoGuide replaces the older InterNIC information server, the
InfoSource. The InfoGuide includes new services such as the Scout
Report and an online hypertext version of the _NSF Network News_.
To access the InterNIC InfoGuide, point your WorldWideWeb client to:
http://www.internic.net/infoguide.html
or your gopher client to:
is.internic.net
NET-HAPPENINGS
The net-happenings list is a service of InterNIC Information
Services and the list moderator, Gleason Sackman of North Dakota's
SENDIT Network. The purpose of the list is to distribute to the
community announcements of interest to network staffers and end
users. This includes conference announcements, call for papers,
publications, newsletters, network tools updates, and network
resources. Net-happenings is a moderated, announcements-only
Cooper [Page 14]
Internet Monthly Report July 1994
mailing list which gathers announcements from many Internet sources
and concentrates them onto one list. To provide better
distribution to a wider audience, net-happenings is being turned
into a USENET newsgroup. The group, if approved, will be named
comp.internet.net-happenings.
A call for votes (CFV) is currently being conducted. Information
about the CFV is available in the net-happenings archive number
4435. To access net-happenings, point your gopher client to:
is.internic.net
and search the InterNIC InfoGuide for Net-Happenings.
THE SCOUT REPORT: A Weekly Summary of Internet Highlights
Presently the Scout Report has over 7500 subscribers and the HTML
versions on the InfoGuide are receiving thousands of accesses each
week. A new mailing list was created for easier distribution of
the HTML Scout Report, which is located at scout-report-html.
Since its formation the new list has accumulated nearly 100
subscribers.
The Scout Report is a weekly publication offered to the Internet
community as a fast, convenient way to stay informed on network
activities. Its purpose is to combine in one place the highlights
of new resource announcements and other news which occurred on the
Internet during the previous week.
The Scout Report is released every Friday in multiple formats --
electronic mail, gopher, and WorldWideWeb. WorldWideWeb versions
of the Report include links to all listed resources allowing
instantaneous browsing of items of interest. Comments and
contributions to the Scout Report are encouraged and can be sent to
scout at internic.net.
How to Get the Scout Report
To receive the electronic mail version of the Scout Report each
Friday, join the scout-report mailing list. This mailing list will
be used only to distribute the Scout Report once a week. Send mail
to:
majordomo at is.internic.net
In the body of the message, type:
subscribe scout-report youremailaddress
Cooper [Page 15]
Internet Monthly Report July 1994
To access the hypertext version of the Report, point your WWW
client to:
http://www.internic.net/infoguide.html
Gopher users can tunnel to: is.internic.net/Information Services
THE InterNIC SEMINAR SERIES
For current seminar information, including cost, dates and times,
send email to: seminars at internic.net.
NSF NETWORK NEWS
The _NSF Network News_ Vol. 1, No. 3 (July/August 1994) is
scheduled for publication at the end of August. The upcoming issue
will feature an interview with Laura Breeden, who is currently the
director of the Telecommunications and Information Infrastructure
Assistance Program (TIIAP). Also highlighted are articles
profiling the National Center for Supercomputing Applications and
its connection and history with NCSA Mosaic; a map designed by
Matrix Information and Directory Services (MIDS) especially for NSF
News readers that graphs the number of Internet Hosts per capita in
the United States; a useful Registration Services FAQ; an
informativeRhow-toS article on Internet publishing by Daniel Dern;
and the regular features of the _NSF Network News_ such as the
InterNIC Event Calendar and updates from InterNIC partners. To
subscribe, send email to newsletter-request at internic.net.
The July/August issue of the _NSF Network News_ is available on the
WorldWideWeb at
http://www.internic.net/newsletter/july-august94/index.html
The newsletter is also available via gopher to the InterNIC
InfoGuide at is.internic.net and mailserv to
mailserv at is.internic.net with the following text in the body of the
message:
get /about-internic/newsletter/archives/nsfnews-mar-94.txt
or
get /about-internic/newsletter/archives/nsfnews-sep-93.txt
Cooper [Page 16]
Internet Monthly Report July 1994
REFERENCE DESK
The following table gives a summary of Reference Desk contacts for
July:
Method Contacts % of Total
------- -------- ---------
Email 148 4
Phone 2964 78
Fax 632 17
US Mail 12 <1
Referral 35 <1
------- -------- ---------
Total 3793 100.0
Anna Knittle <aknittle at is.internic.net>
REGISTRATION SERVICES
---------------------
I. Significant Events
InterNIC Registration Services assigned over 35,000 network
addresses (30,000 to Space and Naval Warfare Command) and
registered over 1800 domains. Blocks of 256 Class C addresses were
assigned to Digital Express, UUNET of Canada, Connected Inc.,
Sprintlink, Westnet, County of Riverside, Worldlink Canada, CSUnet,
GM, EDS, and EDSlink.
I. Registration Statistics For July
Hostmaster Email 4,823
Postal/Fax Applications 240
Telephone Calls 2,220
Domain Registered 1,895
Inverse Addresses 517
Class C's Assigned 35,331
Class B's Assigned 24
ASN Assigned 49
The Registrations Services host computer supported a large volume
of information retrieval requests during the month of June.
Connections Retrievals
Gopher 46,006 25,118
WAIS 26,564 34,984
FTP 8,656 36,633
Mailserv 2,441
Cooper [Page 17]
Internet Monthly Report July 1994
In addition, for WHOIS the number of queries were:
Client Server
189,888 580,303
Scott Williamson <scottw at internic.net>
InterNIC Registration Service
ISI
- ---
NETSTATION
----------
Work this month continued to focus on protocol software
investigation and development.
Display Server Investigation
----------------------------
A graduate student, S. K. Munnangi, has split the X-display server
into two parts. The "lower" server portion will reside on the
network display peripheral being constructed. Packets will be sent
between the "higher" portion of the server to the display
peripheral to determine how practical it may be to replace the
system bus with a gigabit LAN.
The higher and lower portions will be prototyped and debugged on
two Sun workstations prior to porting the lower portion to the
display peripheral. A TMS 320C40 emulator and simulator is being
used for porting and testing prior to actual display hardware
arrival.
LANai 1.1 Software Development
------------------------------
The focus of LANai development during the past month has been on
debugging and testing of a sequenced reliable-packet protocol
implemented "inside" the ATOMIC LAN. This allows an application to
treat the LAN as a reliable medium, much as it would now treat a
DMA transmission between the CPU and a device across a system bus.
The work done by the LANai networking chips to achieve this is
straightforward.
SEND,RECV: connection maintenance
SEND,RECV: transmission and reception interrupt service
SEND: sequence number generation and insertion in packets
Cooper [Page 18]
Internet Monthly Report July 1994
SEND: retransmission event creation
SEND,RECV: bad packet, duplicate and out-of-sequence detection
RECV: ACK generation and transmission
SEND: ACK reception and processing
RECV: retranmission event removal
Currently, only one outstanding packet per connection is allowed.
The performance figure per packet is 125.5 microseconds. This
includes all "normal" work performed listed above. It is measured
from the time that the sending LANai notices that a packet should
be sent, until it has sent it, spawned a retransmission event,
processed the returned ACK, removed the retransmission event, and
marked the sending application's buffer as sent.
Testing Notes
-------------
The LANai chips were clocked at 20 MHz to match the SBus clock.
Short IP/UDP/RPC packets of approximately 120 octets were used
during these tests. Cable transmission time across the ATOMIC
network between SPARstation-2 hosts was insignificant. The LANai
channel transmission clock was 60 MB/s. Total one-way transmission
latency should therefore be under three microseconds.
The bulk of the 125 microseconds of overhead per packet for short
packets is LANai program execution at the source and destination,
which introduces a forced latency between packets. For example,
call-out queue event insertion and event removal for the
retransmission time-out consumes 30 microseconds.
The current prototype LANai 1.1 chips can be clocked 50% faster, to
30MHz, but that was not be done due to the difficulties of
interfacing to a 20 MHz SBus.
More testing and development will occur during August. The one-
outstanding-packet restriction will be relaxed to see what
improvement, if any, will be realized.
Presentations
The Los Angeles area NPR station KPCC did a one hour program on the
Internet during their Friday Airtalk program July 22nd. The local
guest speaker was Gregory Finn from USC/ISI.
Gregory G. Finn (finn at isi.edu) Bruce Parham (Parham at isi.edu),
Munnangi (Munnangi at isi.edu)
Cooper [Page 19]
Internet Monthly Report July 1994
INFRASTRUCTURE
Joyce Reynolds, Bob Braden, Jon Postel attended the IETF in
Toronto,
25 RFCs were published this month.
RFC 1610: Internet Architecture Board (IAB), J. Postel, Editor,
"Internet Official Protocol Standards", July 1994.
RFC 1627: Lear, E., (Silicon Graphics, Inc.), E. Fair (Apple
Computer, Inc.), D. Crocker (Silicon Graphics, Inc.)
T. Kessler (Sun Microsystems, Inc.), "Network 10
Considered Harmful (Some Practices Shouldn't be
Codified)", July 1994.
RFC 1641: Goldsmith, D., "Using Unicode with MIMI", Taligent,
Inc., July 1994.
RFC 1642: Goldsmith, D., "UTF-7 - A Mail-Safe Transformation
Format of Unicode, Taligent Inc., July 1994.
RFC 1643: Kastenholz, F., "Definitions of Managed Objects for
the Ethernet-like Interface Types", FTP Software, Inc.,
July 1994.
RFC 1644: Braden, R., "T/TCP -- TCP Extensions for Transactions
Functional Specification", July 1994.
RFC 1645: Gwinn, A., "Simple Network Paging Protocol --
Version 2" Southern Methodist University, July 1994.
RFC 1646: Graves, C., Butts, T., Angel, M., " TN3270 Extensions
for LUname and Printer Selection", Open Connect
Systems, July 1994.
RFC 1647: Kelly, B., "TN3270 Enhancements", Auburn University,
July 1994.
RFC 1648: Cargille, A., "Postmaster Convention for X.400 Operations
Operations University of Wisconsin, July 1994.
RFC 1649: Hagens, R (Advanced Network & Services, Inc.), and
A. Hansen (UNINETT), "Operational Requirements for
X.400 Management Domains in the GO-MHS Community,
July 1994.
Cooper [Page 20]
Internet Monthly Report July 1994
RFC 1651: Klensin, J. (WG Chair-MCI), N. Freed (Ed. Innosoft),
M. Rose (Dover Beach Consulting, Inc.), E. Stefferud
(Network Management Associates, Inc.), D. Crocker
(Silicon Graphics, Inc), "SMTP Service Extensions"
July 1994.
RFC 1652: Klensin, J. (WG Chair-MCI), N. Freed (Ed. Innosoft),
M. Rose (Dover Beach Consulting, Inc.), E. Stefferud
(Network Management Associates, Inc.), D. Crocker
(Silicon Graphics, Inc), "SMTP Service Extensions for
8bit-MIMEtransport", July 1994.
RFC 1653: Klensin, J. (WG Chair-MCI), N. Freed (Ed. Innosoft),
K. Moore, "SMTP Service Extension for Message Size
Declaration", July 1994.
RFC 1654: Rekhter, Y., (T.J. Watson Research Center, IBM Corp.),
T. Li, (CISCO Systems), "A Border Gateway Protocol 4
(BGP-4)", July 1994.
RFC 1655: Rekhter, Y., (T.J. Watson Research Center, IBM Corp.),
P. Gross (MCI), "Application of the Border Gateway
Protocol in the Internet", July 1994.
RFC 1656: Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", Cisco Systems, July 1994.
RFC 1657: Willis, S., and S. Burrus, (Wellfleet Communications
Inc.), J. Chu, Editor, (IBM Corp), "Definitions of
Managed Objects for the Fourth Version of the Border
Gateway Protocol (BGP-4) using SMIv2", July 1994.
RFC 1658: Stewart, B., "Definitions of Managed Objects for
Character Stream Devices Using SMIv2", Xplex, Inc.
July 1994.
RFC 1859: Stewart, B., "Definitions of Managed Objects for
RS-232-like Hardware Devices using SMIv2", Xyplex,
Inc., July 1994.
RFC 1660: Stewart, B., "Definitions of Managed Objects for
Parallel-printer-like Hardware Devices using SMIv2",
Xyplex, Inc., July 1994.
RFC 1661: Simpson, W., Editor, "The Point-to-Point (PPP)",
Daydreamer, July 1994.
Cooper [Page 21]
Internet Monthly Report July 1994
RFC 1662: Simpson, W., Editor, "PPP in HDLC-like Framing",
Daydreamer, July 1994.
RFC 1663: Rand, D., "PPP reliable Transmission", Novell,
July 1994.
RFC 1664: Kielczewski, Z., (Eicon Technology Corporation),
D. Kostick (Bell Communications Research), K. Shih,
(Novell), "Definitions of Managed Objects for SNA
NAUs using SMIv2", July 1994.
THE US DOMAIN
=============
Under the current ruling, only 4 year universities are allowed to
register in EDU, all other US schools must register in the US
Domain, including K12, community colleges, and technical schools.
Other related school entities may also register in the US Domain.
The US Domain has a framework established for registering K12
schools. It is in the form:
<school-name>.<district>.K12.<state-code>.US
For example: Clinton-HS.ACSD.K12.TN.US
School related Entities that go under K12:
------------------------------------------
- school districts
- school boards
- special educational service units
- state departments of education
- city and county departments of education
- consortiums connecting school districts
- state agencies connecting K12 schools
- School networks providing connectivity to
schools and school districts
- private schools under PVT pseudo district
School related Entities Registered in Other US Domain Branches:
---------------------------------------------------------------
- US Military Schools ....................> FED
- State Departments fo Education .........> STATE
- City or County Departments of Education.> LOCALITY
- Private K12 schools ....................> LOCALITY
Cooper [Page 22]
Internet Monthly Report July 1994
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 425
PHONE Inquiries 153
----------------------------
Total Contacts 578
DELEGATIONS 20
DIRECT REGISTRATIONS: 17
OTHER US DOMAIN MSGS: 540
---------------------------
Total 578
OTHER US DOMAIN MESSAGES INCLUDE: modifications, application
requests, discussion and clarification of the requests, questions
about names, referrals to other subdomains or to/from the InterNic,
resolving technical problems with zone files and name servers, and
whois listings by Email and phone.
The list of delegations below does not reflect the entire number of
registrations and delegations in the whole US Domain. Many
subdomains have been delegated and administrators of those
subdomains register applicants in their domains. Below are direct
registrations in the US Domain.
Third Level US Domain Delegations this month
--------------------------------------------
NEH.FED.US Nat'l Endowment for the Humanities
LIB.MD.US Maryland Libraries
NCSC.DNI.US National Center for State Courts
NEWAYGO.MI.US Newaygo County, Michigan, locality
KENT.OH.US Kent, Ohio locality
Other US Domain Delegations this month
--------------------------------------
CI.PASADENA.CA.US City of Pasadena, California
CO.ST-LOUIS.MO.US St. Louis, Missouri, county government
CO.ARLINGTON.VA.US Arlington, Virgnina, county government
CI.LINCOLN.ME.US City of Lincoln, Nebraska
DIT.CO.FAIRFAX.VA.US Fairfax County Dept of Information Tech.
SCOE.CO.SAC.CA.US Sacramento County Office of Education
JUD.STATE.CA.US Judicial Council of California
VCE.GEN.VA.US Virginia Cooperative Extension Service
PWSSC.GEN.AK.US Prince William Sound Science Center
Cooper [Page 23]
Internet Monthly Report July 1994
JSD.K12.AK.US Juneau, Alaska School District
NMH.NORTHFIELD.MA.US Northfield Mount Hermon School
SNS.OKC.OK.US Stardust Network Services
OKLAOSF.STATE.OK.US Oklahoma State Office of Finance
ALCATRAZ.SF.CA.US InterNex Information Services/BofA
ELECTRONIC-PRESS.CAMBRIDGE.MA.US Electronic Publ. & Data Prep. Co.
TABLE OF DELEGATED DOMAINS BY STATE
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
AK X
AL X
AR X
AZ X X X X X
-----------------------------------------------------------
CA X X X X
CO X X X X X X X
CT
DC X
-----------------------------------------------------------
DE X
FL X X X X X X X
GA X X X X
HI
-----------------------------------------------------------
IA X X X X
ID X X X X X X X
IL X X X X X
IN X X X X X X X
-----------------------------------------------------------
KS X
KY X X X X X X X
LA X X X X X
MA X
-----------------------------------------------------------
MD X X X X
ME X X
MI X X X X X
MN X X X X X X X
-----------------------------------------------------------
MO X X X X X
MS X X
MT X
NC X X X X X
-----------------------------------------------------------
Cooper [Page 24]
Internet Monthly Report July 1994
----------------------------------------------------------
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
ND X X X X X X X
NE X X X X
NH X X
NJ X
-----------------------------------------------------------
NM X X X
NV
NY X X X X X X X
OH X X X X X X X
-----------------------------------------------------------
OK
OR X X X X X X X
PA X
RI X X X
-----------------------------------------------------------
SC X X X X X X
SD X X
TN X
TX X X X X
-----------------------------------------------------------
UT X X X X
VA X X X X
VI
VT X X
-----------------------------------------------------------
WA
WI X X X
WV X X X X X X X
WY X
===========================================================
For more information about the US Domain please request an
application via the RFC-INFO service. Send a message to RFC-
INFO at ISI.EDU with the contents "Help: us_domain_application". For
example:
To: RFC-INFO at ISI.EDU
Subject: US Domain Application
help: us_domain_application
Ann Westine Cooper (Cooper at ISI.EDU)
Cooper [Page 25]
Internet Monthly Report July 1994
MULTIMEDIA CONFERENCING
At the IETF meeting held in Toronto this month, there were several
sessions relevant to multimedia teleconferencing, in particular
those of the Multiparty Multimedia Session Control (MMUSIC) Working
Group and the Audio/Video Transport (AVT) Working Group. The
MMUSIC session focused on reports from implementors of a range of
multimedia conferencing applications with the goal of identifying
common ground for interoperability of both session managers and
media agents. As a result, there was commitment by several
implementors to document their protocol choices, and to prototype
experiments on interoperation in the near term.
In the first AVT session, rough consensus was given to submit the
revised Real-time Transport Protocol specification for Area
Directorate review and IESG Last Call as a Proposed Standard. This
revision, denoted RTP version 2, incorporates changes requested by
the first AD review in November 1993. It is the refinement by
Steve Casner, Ron Frederick, Van Jacobson and Henning Schulzrinne
of the rough protocol changes presented and discussed at the March
1994 IETF meeting in Seattle. This version of the spec was posted
before the meeting as Internet Draft draft-ietf-avt-rtp-05.txt.
An overview of the revised RTP was presented in the first AVT
session, and the group concurred with the choices made on all of
the previously open issues. It was agreed that the extension hooks
provided were adequate for planned experiments with mechanisms not
included in the current protocol. A few explanatory sections of
the draft need to be completed, then it will be submitted. In the
second AVT session, video encoding specifications for H.261, JPEG
and MPEG were presented. These specifications will also be
completed as Internet Drafts and then submitted as Proposed
Standards.
Steve Casner (casner at isi.edu)
MERIT/NSFNET ENGINEERING
- ------------------------
This report summarizes recent activities of Merit's NSFNET Project
Internet Engineering and Network Management groups.
Merit's work with midlevel networks has resulted in the increasing
use of CIDR route aggregation. During July the NSF/ANSNET routing
tables increased by 62 while 784 specific routes were withdrawn in
favor of their CIDR aggregate announcement.
Joint development work continues with RIPE on the RIPE-81++ syntax
Cooper [Page 26]
Internet Monthly Report July 1994
and documentation. The current draft is available as:
ftp.ripe.net:ripe/drafts/ripe-81++.ps
Merit initially ported the RIPE code and has implemented some of
the extensions of RIPE-81++. We are in the process of designing a
transition from the PRDB to the RRDB which will include generation
of the NSFNET Backbone Router configurations from the RRDB.
Prototype gateD configuration file generators have been written for
the RRDB database. This work is seen as a predecessor for the
generation of configuration files for the Route Server.
Merit staff collaborated in the University of Michigan project to
re-establish a UM Network Operations Center. David Morse,
davmorse at noc.ns.itd.umich.edu, is the NOC manager. The University
of Michigan NOC will provide first level operational support for
the Routing Arbiter project.
Work continues in anticipation of the startup of the first Network
Access Points (NAPs) and the transition from the current backbone
service to the new architecture. On line information about the
transition plan and NAPS is available via a world wide web server
as: http://rrdb.merit.edu/home.html and via anonymous ftp in the
/pub/transition directory on the same host.
Several staff led sessions at the 30th IETF, July 25-29 in Toronto.
Jessica Yu (with Vince Fuller of BARRNET) led the session of the
CIDR Deployment Working Group (cidrd). Sue Hares hosted a workshop
for new working group Chairpersons and presented in the SDRP and
NetStat working group meetings. Elise Gerich participated in the
IAB open meeting. Several staff participated in the ATM-NAP
Workshop for the NSF new architecture awardees which also included
several Network Service Providers.
Kenneth T. Latta, II (klatta at merit.edu)
NEARNET
- -------
NEARNET EXPRESS56(sm) COMPRESSION SERVICE
NEARNET's new Express56 Service increases the throughput of a
56Kbps leased line connection to as high as 256Kbps, without
raising your telephone line costs. For more information, send
email to: nearnet-join at near.net or call the NEARNET sales staff at
617-873-8730.
Cooper [Page 27]
Internet Monthly Report July 1994
THE BBN INTERNET TRAINING GROUP
In response to the overwhelming requests from the Internet
community for more Internet-specific training, BBN has created an
Internet Training Group. In conjunction with the NEARNET staff,
the Training Group has recently begun offering training courses to
the general public.
Training courses are offered in Cambridge, Massachusetts, New York
City, and, upon request, on-site at the customer's organization.
NEARNET members and educational users are eligible for a 25 percent
introductory discount. To find out more about BBN's Internet
Training Courses, please send email to: net-train at bbn.com or call
617-873-DATA (3282).
NEARNET TRAINING PROGRAM UPDATE
The Summer set of NEARNET member training courses is scheduled for
August 10-12 in BBN's Newman Auditorium. For more information,
please contact the NEARNET Client Services Staff at nearnet-
us at near.net or call 617-873-8730.
The three full-day set of courses include: (Day 1) An Introduction
to Resources on the Internet; (Day 2) An Orientation for New
NEARNET Liaisons; and (Day 3) An Introduction to Internet
Technology.
All three days of training are available free of charge to all new
sites. The Internet Resources and Internet Technology courses are
available for existing sites and non-members for a fee. The
NEARNET Orientation is free to all NEARNET sites.
NEARNET USER SERVICES STEERING COMMITTEE (USSC) UPDATE
The latest meeting of the NEARNET USSC was held on August 1 at BBN.
Members of the Boston Computer Society (BCS) participated in the
committee meeting and presented an interesting update on the past,
present, and future activities of the BCS. The next USSC committee
meeting will be held on September 26.
by NEARNET Client Services <nearnet-us at near.net>
Cooper [Page 28]
Internet Monthly Report July 1994
NORTHWESTNET
- ------------
Dr. Eric Hood (Executive Director of NorthWestNet) chaired the July
6-8 FARNET Workshop "Transition to the New NSFNET" held in
Washington, D.C. Also attending from NorthWestNet was Dan Jordt,
Director of Technical Services.
In a continuation of NorthWestNet's regularly scheduled Internet
Training Series, three three-hour classes were held at the
NorthWestNet training facility in Bellevue, Washington. These for-
fee classes are open to the public. Topics covered included an
introduction to the Internet, Electronic Mail (PINE), File Transfer
Protocol, Telnet, and Gopher and Veronica. For information about
upcoming scheduled classes, retrieve the following via anonymous
FTP:
FTP Host: ftp.nwnet.net
directory: /training
filename: course-descriptions.txt
The upcoming series to be offered in late August adds a new course
titled "Internet Discussion Groups." This new class introduces
Usenet and its newsgroups, as well as Internet mailing lists and
LISTSERV lists.
-----------------
NorthWestNet E-mail: info at nwnet.net
15400 SE 30th Place, Suite 202 Phone: (206) 562-3000
Bellevue, WA 98007 Fax: (206) 562-4822
Dr. Eric S. Hood, Executive Director
Jan Eveleth, Director of User Services
Dan L. Jordt, Director of Technical Services
Anthony Naughtin, Director of Member Relations
NorthWestNet serves the six state region of Alaska, Idaho, Montana,
North Dakota, Oregon, and Washington.
NYSERNET
- --------
NYSERNet EDUCATION PROGRAM UPDATE
The NYSERNet Internet Training and Education Center (NITEC)
recently contributed to training for participants in Project
C.A.R.E. (Sponsored by State Senator Charles D. Cook, Project
C.A.R.E is delivering Internet connectivity to eight rural schools
Cooper [Page 29]
Internet Monthly Report July 1994
in New York's 40th district.) This first in a series of training
events for C.A.R.E. participants focused on integrating
connectivity products into each school's network environment, and
on installing and configuring Internet client software tools. In
subsequent events C.A.R.E. participants will receive training in
the use of these Internet client tools for resource discovery and
educational projects.
The NITEC Fall schedule of courses will be published this August.
To receive a copy of the schedule and be added to the NITEC mailing
list, please contact NYSERNet at training at nysernet.org or call
315-453-2912 ext. 222.
NYSERNET SPONSORED PROJECTS UPDATE
The NYSERNet Breast Cancer Information Clearinghouse welcomes the
National Breast Cancer Coalition/Breast Cancer Support Hotline
Adelphi School and Y-ME National Breast Cancer Organization as
partners in the BCIC project. Partner organizations participate in
the development and maintenance of the Clearinghouse.
To access the Breast Cancer Information Clearinghouse: With a WWW-
client (e.g. Mosaic), use: http://nysernet.org/bcic/ With a gopher
client (e.g. gopher) use: gopher nysernet.org and select item
number eight from the main menu.
Project C.A.R.E.: NYSERNet is currently in the process of getting
the sites' Internet connections up and running prior to the first
two weeks of August, when participants from the schools will
receive their second round of training. (See the NYSERNET
EDUCATION UPDATE above)
INTERNET DEMONSTRATION PROJECT
With funding from the National Center for Educational Statistics,
NYSERNet will coordinate the development of a client/server
application set designed to support the needs of education related
to the collection and dissemination of information. NYSERNet will
coordinate the efforts of six (6) project participants comprised of
representative from State Education Agencies (SEA) and federal
agencies.
This application development project will include three phases: 1)
requirements and analysis, 2) coding, and, 3) testing and
implementation. The process of development includes structured
opportunities for participation of other states, NCES and other
federal agencies during both the requirements and testing and
implementation phases.
Cooper [Page 30]
Internet Monthly Report July 1994
NEW YORK STATE CONTRACTS
The New York State Office of General Services (OGS) has selected
NYSERNet to provide network and application support to make the New
York State Contracts available on the Internet. State Contracts
will be available via Gopher menuing, with both Jughead and WAIS
indexing. The service will be Internet accessible in August, 1994.
NYSERNet has recently partnered with 11 Board of Cooperative
Educational Services (BOCES) Regional Information and Computer
Centers to establish Internet connections to K-12 schools in New
York State. Connections established at BOCES will be used as
models for delivering services to the K-12 community. Connections
will be established in August and a training program conducted by
NYSERNet in the fall.
Teen Health Issues Network
The Teen Health Issues Network of Greater Rochester NY has
completed its first pilot year. This network seeks to
electronically connect the health care givers, school nurses and
counselors, and health teachers who deal with teens in areas of
physical, mental and social health. The Rochester area has a fiber
optics telecommunications network that carries simultaneous audio
and video transmission among 8 sites (2 higher education
institutions and 6 high schools). Live interactive programs geared
for the adults were given for professional development in areas
such as Cults and Their Relationship to Alcohol and Drug Abuse,
Media Literacy and Conflict Resolution. The topics of AIDS and
Teen Pregnancy were addressed in 3 sessions for students which
provided an opportunity to discuss these timely issues openly with
HIV+ patients and pregnant/parenting teens, respectively.
Electronic discussion groups using Internet connections were formed
after each live event to allow ongoing interaction with other
participants, and the panelists, in an anonymous fashion.
The next school year will kick-off the Teen Health Issues Network
programming with a professional development discussion of the
Center for Disease Control's Survey of Youth Risks done in Monroe
County. The first student event will be on Athletic Induced Asthma
for athletes and their coaches. The continuing effort to
electronically connect, equip, and train new users on the Internet
from all sorts of professional teen healthcare settings will be a
primary focus in the second pilot year of this network.
NEW AFFILIATES
NYSERNet welcomes the following new leased-line affiliates: Monroe
Cooper [Page 31]
Internet Monthly Report July 1994
County Library System, Brooklyn Law School, Hitachi America, Ltd.,
and Hobart and William Smith Colleges.
NYSERNet CONFERENCE
NYSERNet's Conference '94 will be held at the Desmond Americana
Hotel in Albany, New York from Thursday, September 29 through
Saturday, October 1, 1994. The theme for this year's statewide
conference is "Connecting the NEW New York". Thursday afternoon's
agenda will include an Open Board Meeting of NYSERNet's Board of
Directors, and a meeting of NYSERTech, NYSERNet's technical user's
group. The NYSERNet community is welcome to attend each of these
events at no charge, although NYSERTech is only open to those
individuals who are members of NYSERTech. A wine and cheese
reception follows, to which all conference attendees are welcome.
Friday's Conference program will feature a keynote speaker, then a
full day of parallel sessions along four program tracks: Government
and Technology, Education, Libraries, and Network Technologies.
Tutorials will be held Saturday, October 1, utilizing the computing
facilities of SUNY Albany and the Rensselaer Polytechnic Institute.
Half day Tutorials scheduled will include two hands-on sessions:
"Internet Everyday (Beginners)" and "We the People (Advanced)."
Full day technical tutorials scheduled include "Linking your LAN to
Internet," "How To Cook Your UNIX Gopher Server," and "Contributing
to The World Wide Web: Selecting and Installing an HTTP Server."
Other sessions are to be announced.
NEW STAFF MEMBERS
Jeff Renk and Mary Fran Yafchak joined NYSERNet this month as
Network Information Specialists. Jeff and Mary Fran will design,
develop, deliver, and evaluate training and educational materials
on Internet tools. They will also provide help desk support for
NYSERNet affiliates.
Terri Damon (tmdamon at nysernet.ORG)
PREPNET
- -------
Note that this report covers June and July.
PREPnet New Members
- City of Meadville-GREMLAN, Meadville, PA
- Bucks County IU, Doylestown, PA
- Oasis Telecommunications, Allentown, PA
- Geneva College, Beaver Falls, PA
Cooper [Page 32]
Internet Monthly Report July 1994
- Grove City College, Grove City, PA
- Composidie, Inc., Apollo, PA
- Compudata, Philadelphia, PA
- Reality Technologies, King of Prussia, PA
- The School District of Philadelphia, Philadelphia, PA
- Icon Technologies, Inc., Mayfield, PA
With these additions, PREPnet now totals 188 members.
PREPnet News
============
Training
--------
Felicia Ferlin conducted PREPnet's Introduction to the Internet
training session at the following sites. With the help of staff on
site, live demos and hands-on training were done using site
software and hardware.
June 3 Beaver College
July 11 Central & Northern Pennsylvania Ben Franklin
Technology Center
July 12 Juniata College
Meetings & Conferences
----------------------
Date Attendee(s) Event
5/23-6/3 Tom Bajzek Internet World
6/2 Felicia Ferlin CAUSE-CNI
6/3 Sean Sasso C-CUE
6/2-3 Iain Boone North American National Operations
Group (NANOG), formerly Regional Techs
6/27-28 Felicia Ferlin Pennsylvania Rural Education
Conference
7/7-8 Tom Bajzek FARNET
Iain Boone
7/25-29 Marsha Perrott IETF
For information regarding connectivity options in the Commonwealth
of Pennsylvania, contact the PREPnet NIC:
305 S. Craig St. E-Mail: nic at prep.net
2nd Floor Telephone: (412) 268-7870
Pittsburgh, PA 15213
PREPnet NIC (nic at prep.net)
Cooper [Page 33]
Internet Monthly Report July 1994
RARE SECRETARIAT
- ----------------
A RARE UPDATE no. 12, July 1994
(Double Summer issue)
COA Information
RARE members gathered in Darmstadt, courtesy of ESOC, on 19 and 20
May 1994. Meetings included a joint meeting with the EARN Board of
Directors dedicated to the proposed merger between RARE and EARN and
subsequently the 29th CoA meeting.
The joint meeting was perceived as very constructive. The Executive
Committees of both organizations had provided the members with draft
Statutes, Rules and Regulations, a Charter, a Technical Structure and
a budget, encompassing proposals for membership fees and voting
rights. The conclusion of the meeting was that the merger was
feasible and should take place still during 1994 and this event is
scheduled to take place at the event of the next (and last) RARE
Council of Administration meeting on 20 October 1994, in Amsterdam.
A call for a new name for the merged organization has been issued and
several proposals are under investigation.
During the CoA meeting, the RARE accounts were - as is traditional
in May - presented and 1993 financial year was closed with the
approval of the Council of Administration of the accounts 1993.
Two networking organizations were unanimously accepted as RARE Full
National Members: UNICOM-B from Bulgaria and UNIBEL from the Republic
Belarus.
The CoA has asked the Executive Committee to reorganize the RIPE
NCC's management structure by the creation of a management body that
is representative of the whole customer base in order to enhance
cooperation with the RIPE NCC's commercial customers. This management
body will be involved in the fund raising for the RIPE NCC.
RARE Technical Programme
The most recent main event for the RARE Technical Programme was
the INET'94/JENC5 conference, organized by RARE and the Internet
Society (ISOC), which took place in Prague in mid-June.
All the RARE Working Groups took the opportunity to
meet at the conference and were able to present their work to
visitors from across the whole world.
Cooper [Page 34]
Internet Monthly Report July 1994
The Working Group on network operations (WG-NOP) was relaunched
under its new convenor, Manfred Bogen. The new convenors of
the Working Group on Information Services and User Support
(WG-ISUS), Dave Hartland, and the Working Group on Network
Security (WG-SEC), R=FCdiger Grimm, were able to introduce
themselves in person.
Also at the conference, the final stages of two RARE projects
were reported. The task force on Computer Emergency Response
Teams has presented plans for a European coordination centre
for liaison between the front-line support organizations dealing
with network security incidents. This is now being developed
into a business plan (which will be the subject of a call for
tender) for approval by the CoA on 20 October 1994.
The project of the Working Group on Character Sets, which is
developing software for conversion between a wide variety of
coded character sets, was presented at the conference in the
form of a live demonstration of the conversion program.
Two new RARE Technical Reports are in the course of production.
RTR12 on Writing O/R Names is a revision of the guidelines of
the Working Group on Mail and Messaging (WG-MSG) which takes
into account recent international standards in this area. RTR13
is a Status Report on Network Information Retrieval, a
regularly-updated report which gives an overview of the "state
of the art" in this field.
RTR8, 9, 10 and 11 are currently available in printed form
and can be ordered from the RARE Secretariat.
RARE has recently entered into contracts with INRIA to work on
the integration of directory-service access with the World Wide
Web. RARE is also contributing to the support and development of
the World Wibe Web project which is seen as a key element in the
development of information services for researchers.
Looking to the future, RARE has launched its UPTURN (Umbrella
Proposal for Telematics for Users and Research Networks)
initiative to encourage participation in the European Union's
fourth Framework Programme. The Fourth Framework offers the
possibility of European funding to assist in collaborative
projects between commerce and researchers which will result in
the delivery of telematic services which add to the productivity
of industrial and academic researchers. RARE is providing
information on the programme and is assisting in the information
exchange between potential participants via its UPTURN mailing
list. To join this list, send electronic mail to
Cooper [Page 35]
Internet Monthly Report July 1994
mailserver at rare.nl containing the text:
SUBSCRIBE UPTURN your-first-name your-last-name
replacing your-first-name and your-last-name as appropriate.
Once you have joined the list, you can send mail to the other
subscribers at the address upturn at rare.nl.
A large, common RARE Working Groups Meeting is planned for
December 1st and 2nd, in London, subsequent to EARN's NSC
conference, November 28-30, 1994.
Information about the UPTURN initiative, and about RARE and its
technical programme, can be obtained from:
- ftp.rare.nl (by anonymous FTP)
- gopher.rare.nl (by gopher)
- http://www.rare.nl/ (by World Wide Web)
Conferences and Seminars
INET'94/JENC5
RARE's annual Joint European Networking Conference (JENC5) was
held this year in Prague (Czech Republic), in conjunction with
the Internet Society's (ISOC) annual INET conference. In every
respect it was considered a great success. The participants
numbered around 1200 and came from over a 100 different countries.
The Czech Technical University and the Czech Educational and
Scientific NETwork (CESNET) were responsible for the local
arrangements. They furnished the terminal room with over
70 workstations, terminals and desktop computers with worldwide
Internet connectivity. The technical staff also supported the
connectivity in the demonstration area, where up to 12 highly
advanced networking applications were presented to the public
at large. With the support of various sponsors leased lines
with a total capacity of 2.5 Mbit/s connected the conference
centre to the rest of the world. This connectivity allowed
interactive Mbone broadcasts of the plenary sessions of the
conference to hundreds of sites in many countries.
That the conference was a truly global event also became apparent
in the more than 100 presentations and panel discussions in six
different topical areas: user support and training, distributed
applications, policy issues, regional issues, network engineering and
Cooper [Page 36]
Internet Monthly Report July 1994
network technology. The programme presented the developments in
technology on ATM, Multimedia, IPng, Routing and Addressing, Network
Information Tools, Broadband Technology, Performance Analysis,
Electronic Documentation, Networked Simulation and Virtual Reality
and Future Generations of Internet Technology, to mention only a
few of the subjects covered.
These new technological developments, and the exponential growth of
networking in the last few years are bringing past side issues to the
foreground. Policy issues are becoming more and more important
with the increasing number of active Internet users and its broader
scale. Also new user communities are emerging every day, and each of
them has their own specific demands with regard to service, support
and training. The conference proved a good discussion platform for
all of these important issues.
A full set of proceedings was distributed at the conference and a
number of selected papers of high quality are being prepared for
publication in a special issue of Computer Networks and ISDN Systems.
Preceding the conference there was a one day tutorial on ATM
(Asynchronous Transfer Mode), organized and sponsored by Digital
Equipment Corporation (DEC).
The week prior to the conference the workshop for Technologically
Emerging Countries took place at the Czech Technical University.
A selected number of participants (approx. 170) from around
80 countries had the unique opportunity to learn how to access and
use worldwide Internet resources, as well as build and manage
national networks in their own countries. The Soros Foundations
funded participation of many Eastern European and CIS attendees.
RARE, with the financial support of NATO, took direct responsibility
for the Network Navigation and Services Track.
JENC6
With the Prague event still fresh in memory, preparations have
already been made for next year's conference that will take place in
the new Dan Panorama Convention Center in Tel Aviv, Israel from 15-18
May. The Programme Committee, under the leadership of Jose Barabera
(FUNDESCO, Spain), has already prepared a Call for Papers that is
available from jenc6-sec at rare.nl.
The conference theme, "Bringing the World to the Desktop", may be
looked upon as a metaphor for two major changes under way:
- the increasing penetration of daily research/educational work and
practices by networks and networking technology;
- the new set of requirements that desktop networking implies for the
Cooper [Page 37]
Internet Monthly Report July 1994
underlying technology and the structures of service provision.
The goal of this conference is to survey the current situation in
networking, to illuminate major unresolved issues and technologies,
but most of all to stimulate discussion on possible future
directions.
The local arrangements are taken care of by ILAN.
For more information about RARE contact:
Internet: raresec at rare.nl or kiers at rare.nl
X.400: C=3Dnl; ADMD=3D400net; PRMD=3Dsurf; O=3Drare; S=3Dkiers
X.400: C=3Dnl; ADMD=3D400net; PRMD=3Dsurf; O=3Drare; S=3Draresec
fileserver: gohper.rare.nl, ftp.rare.nl or http://www.rare.nl/
Judith Kiers <kiers at erasmus.rare.nl>
UCL
- ----
Tony Ballardie, Peter Kirstein, and Ian Wakeman attended the
Toronto IETF. Ballardie ran the WG on Multicast, Kirstein attended
many meetings and Wakeman gave presentations on the UCL work on
Class Based Queueing and on the Conference Control Channel
Protocol.
En route to Toronto, Wakeman had stopped off at SURA, where with
much help from ARPA, and from Erik Sherk and Jennifer Blake-Hedges,
we were able to get the Class Based Queueing code (& Solaris, and
an FDDI card and 2nd Ether card and gated) installed one day. We
will be coordinating with BBN and ULCC to get the routes changed to
load this up with the UK-US traffic to test the resource allocation
and link share code over the next month.
Meanwhile, the CCCP implementation has passed alpha stage, and is
being used to develop a simple floor control protocol, by
Crowcroft.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 38]
Internet Monthly Report July 1994
CALENDAR
- --------
Last update 8/3/94
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at cnri.reston.va.us>
************************************************************************
1994
- ------------
Jul. 18-Aug. 3 ISO/IEC JTC 1/SC 21
WGs and Plenary Southampton, UK
Aug. (mid) SNOWMASS
Aug. 2-5 HPDC-3 San Francisco, CA
Aug. 4 Special Interest Group on
Netwkd Info., Disc. Retrieval McLean, VA
Aug. 7-12 SHARE (IBM) Boston, MA
Aug. 10-12 IFIP Protocols Vancouver, BC
Aug. 22-26 6th Joint EPS-APS Phyicics Lugano, Switzerland
Aug. 28-Sep 2 IFIP World Congress Hamburg, Germany
Aug. 29-Sep 2 SIGCOMM 94 London, England
Sep. IEEE P802.11 Interim TBD
Sep. 7-9 Windows Solutions San Francisco, CA.
Sep. 12-16 NetWorld+Interop Atlanta, GA
Sep. 12-16 OIW
Sep. 13-16 Seybold San Francisco, CA
Sep. 14-16 4th Int'l CCHP Vienna, Austria
Sep. 26-28 2nd IWACA Heidelberg, Germany
Sep. 28 Intnt'l Computer Comm. & Ntwks Bangkik, Thailand
Sep. 29-Oct. 1 NYSERNet Conference '94 Albany, NY
Sep. 29-Oct. 1 NATO Adv. Wkshp on Ntwking
in the NIS Moscow
Oct. 2-5 IEEE Leading Edge Comp. Ntwg Minneapolis, MN
Oct. 6-8 Parallel & Dist. Compt. Sys Las Vegas, NV
Oct. 15-20 ACM Conference on Multimedia San Francisco, CA
Oct. 16-20 ACM SIGUCCS
Oct. 24-28 NetWorld+Interop '94 Paris, France
October/November Windows Solutions Germany
Oct. 31-Nov. 1 1st Intntl ACM/SIGCAPH Conf.
Assistive Technolgies (ASSETS) Marina del Rey, CA
Oct. 31-Nov. 3 EDUCOM
Cooper [Page 39]
Internet Monthly Report July 1994
Nov. 2-4 Gigabit testbed jamboree Reston, VA
Nov. 2-4 ACM Conf. of Computer and Comm Fairfax, VA
Security
Nov. 7-11 IEEE P802.11 Plenary Incline Village, NV
Nov. 8-11 German Soc. of Internet Users Munich
Nov. 11-14 ICCCN '94 San Francisco, CA
Nov. 14-15 CEC Cist 237 M-media Vienna, Austria
Nov. 14-18 Supercomputing '94 Washington, DC
Nov. 14-18 USENIX/ACM SIGOPS Monterey, CA
Nov. 15-16 CEN/CENELEC/ETSI Conf. Brussels
Nov. 18-20 Nerdathon '94 - Windows into
the Internet Lake Tahoe
Nov. 28-30 Ntwk. Svs. Conf. (NSC'94) London, UK
Nov. 28-Dec. 2 Email World Boston, MA
Nov. 29-Dec. 2 ATM Forum Kyoto, Japan
Nov. 29-Dec. 2 Cause
Dec. 1-2 RARE Working Groups London, UK
Dec. 5-7 Australian Telecom Networks and
Applications Conf. ATNAC 94 Melbourne, AU
Dec. 5-9 31st IETF (Definite) San Jose, CA
Dec. 5-9 ANSI X3T11
Dec. 5-9 10th Comp. Sec. Applications Orlando, FL
Dec. 7-9 Windows Solutions Tokyo, JP
Dec. 7-9 IEEE R/T Systems Symposium San Juan, Puerto Rico
Dec. 12-16 OIW
1995
- ---------
Jan. 16-20 USENIX New Orleans, LA
Feb. 16-17 ISOC Symposium on Ntwk &
Distribruted System Security San Diego, CA
Feb. 20-24 UniForum Dallas CC, Dallas, TX
Feb. 26-Mar. 3 SHARE (IBM) Los Angeles, CA
Mar. 6-10 IEEE 802 Plenary (Tentative)
Mar. 13-17 OIW
Mar. 13-17 Email World (confirmed) Santa Clara, CA
Mar. 13-24 ISO/IEC JTC1/SC6 Tokyo, JP
Mar. 16-19 3rd Intntl Telecom. Systems
Modelling & Analysis Nashville, TN
Mar. 27-31 NetWorld+Interop Las Vegas, NV
April 3-7 32nd IETF (confirmed) Danvers, MA
April 19-21 5th Network & Operating System
Support (NOSSADV) Workshop Boston, MA
May 15-19 Joint European Ntwkg Conf. Tel Aviv, Israel
May 18-19 RARE Council of Admin. Tel Aviv, Israel
Jun. ISO/IEC JTC 1SC 21
WGs and Plenary (tentative) Turkey
Jun. ISOC Wkshop for Tech.
Cooper [Page 40]
Internet Monthly Report July 1994
Emerging Countries
Jun. 12-16 INET '95 (tentative) Singapore
Jun. 12-16 OIW
Jun. INET95
Jul. 4 Independence Day
Jul. 10-14 IEEE 802 Plenary (Tentative)
JULY 14 BASTILLE DAY
Jul. 17-21 33rd IETF (Tentative) Sweden
Jul. 31 - Aug. 4 33rd IETF (Tentative) Sweden
Sep. 11-15 OIW
Oct. 3-11 Telecom '95 Geneva, Switzerland
Oct. 9-13 Email World San Jose, CA
(likely to be replaced by Nov. 27-Dec. 1 dates)
Nov. 6-10 IEEE 802 Plenary (Tentative)
Nov. 13-17 34th IETF (Tentative)
Nov. 27-Dec. 1 Email World (Probable) Boston, MA
Dec. 4-8 OIW
Dec. 4-8 34th IETF (Tentative)
Dec. 4-8 ANSI X3T11 (Possible)
Dec. 4-8 Supercomputing '95 (Possible)
1996
- -----------
Mar. 11-14 UniForum San Francisco, CA
Mar. 18-22 OIW
May ISO/IEC JTC 1/SC 21
WGs and Plenary (tentative) Kansas City, US
Jun. 10-14 OIW
Sep. 2-6 14th IFIP Conf. Canberra, AU
Sep. 9-13 OIW
Dec. 9-13 OIW
1997
- -----------
Mar. 10-13 UniForum San Francisco, CA
- ---------
Via ftp: /ietf/1events.calendar.imr.txt on ietf shadow directories
Via gopher: "Internet Society / IETF / IETF Meetings /
Scheduling Calendar" on ietf.cnri.reston.va.us
=====================================================================
Cooper [Page 41]
Internet Monthly Report July 1994
Ref. RSec(94)001-ac August 1994
This list of meetings is provided for information. Many of the meetings
are closed or by invitation; if in doubt, please contact the chair of
the meeting or the RARE Secretariat. If you have
additions/corrections/comments, please mail Anne Cozanet
(e.mail address: cozanet at rare.nl).
**********************************************************************
MEETING/DATE LOCATION
============ ========
RARE Executive Committee
- ------------------------
1 September Amsterdam (RARE Secretariat)
2 September
(Joint meeting with EARN-EXEC) Amsterdam (RARE Secretariat)
RARE Council of Administration
- ------------------------------
20/21 October 1994 Amsterdam
NewOrg General Assembly
- -----------------------
GA1
20/21 October 1994 Amsterdam
GA2
18/19 May 1995 Tel Aviv
UPTURN BoF
- ----------
27 October Interop, Paris
(from 18.30 till 20.30 hrs)
RARE Technical Committee / WG Convenors
- ---------------------------------------
RARE Working Groups
- -------------------
JOINT WORKING GROUP MEETING
1-2 December London (after NSC'94)
Cooper [Page 42]
Internet Monthly Report July 1994
RIPE
- ----
12-14 September Lisboa
VARIOUS
- -------
EUROPEAN OPERATORS FORUM
12 September Lisboa
EBONE
Consortium of Contributing Organisations
02 November Munich
EBONE Management Committee
06 September Copenhagen
EOT (Ebone Operations Team)
10 October Paris
EARN
Board of Directors
30 November - 1 December London
DANTE Shareholders
20 September TBC
Euro-CCIRN
CCIRN
16/17 June 1995 Singapore
INTERNET SOCIETY Board of Trustees
15/16 December Washington DC
IETF
5-9 December San Jose, California
3-7 April 1995 Danvers, Massachusetts
Summer 1995 Stockholm, Sweden
EWOS
- ----
Technical Assembly
13-14 September Brussels
22-23 November Brussels
Steering Committee
27 September Brussels
Cooper [Page 43]
Internet Monthly Report July 1994
6 December Brussels
Workshops
10-14 October Brussels
ETSI
- ----
General Assembly
22/23 November Nice, France
Technical Assembly
18-20 October Nice, France
*******************************************************************
JENC6 - 6th Joint European Networking Conference
15-18 May 1995 in Tel Aviv, Israel
To be added to the conference email distribution list, send a message to
<jenc6-request at rare.nl>.
For information, email <jenc6-sec at rare.nl>.
To submit a paper, email <jenc6-submit at rare.nl>
*******************************************************************
OTHER CONFERENCES
(nb. For some of the following events, full text information is
available from the RARE Document Store under the directory calendar, in
which case the file name is specified under the information presented
below. The files may be retrieved via:
anonymous FTP: ftp.rare.nl
Email: server at rare.nl
Gopher: gopher.rare.nl)
6th JOINT EPS-APS INTERNATIONAL CONFERENCE ON PHYSICS COMPUTING
- ---------------------------------------------------------------
from 22 till 26 August 1994 in Lugano, Switzerland
Email <pc94 at cscs.ch>
13TH WORLD COMPUTER CONGRESS - IFIP CONGRESS 94
- -----------------------------------------------
from 28 August till 2 September 1994, in Hamburg, Germany
Tel. +49 40 3569 2242 - Fax. +49 40 3569 2343
Cooper [Page 44]
Internet Monthly Report July 1994
ACM SIGCOMM'94
- --------------
Communications Architectures, Protocols and Applications organised by
University College London
from 31 August till 2 September
(Tutorials and Workshops on 30 August)
For further information, contact <J.Crowcroft at cs.ucl.ac.uk>
SIXTH UNICODE IMPLEMENTERS' WORKSHOP
- ------------------------------------
8/9 September 1994
at Westin Hotel, Santa Clara, California
information from: <workshop at unicode.org>
THIRD INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS
- -----------------------------------------------------------------------
(ICCCN'94)
from 11-14 September 1994, San Fransisco, U.S.A.
Conference Chairman: Prof. T. Suda <suda at ics.uci.edu>
INTERNATIONAL CONFERENCE ON INTERNET TECHNOLOGY & APPLICATIONS
- --------------------------------------------------------------
28 September 1994
at Asia Hotel, Bangkok, Thailand
(limited budget to pay for local expenses of all international speakers,
ie. local transportation, hotel, meals...)
information from Srisakdi Charmonman, email <charm at abac.au.ac.th>
NATO ADVANCED WORKSHOP ON NETWORKING IN THE NIS
- -----------------------------------------------
"Establishing a cooperative framework for networking in
Russia and her neighbourhing states"
29 September until 1 October 1994
In Moscow, Russian Federation
CLOSED - BY INVITATION ONLY
OPENNET'94 - German Society of Internet Users (DIGI e.V.)
- ---------------------------------------------------------
from 8-11 November in Goettingen (Park Hotel Ropeter)
For further information contact the DIGI board via email:
<vorstand at digi.de>
CEN/CENELEC/ETSI CONFERENCE 1994
- --------------------------------
on 15 and 16 November 1994
in the European Parliament, Brussels.
Information from Kristien Van Ingelgem, fax.+32 2 519 6819
Cooper [Page 45]
Internet Monthly Report July 1994
ICT STANDARDIZATION POLICY WORKSHOP 1994
- ----------------------------------------
28, 29 and 30 November 1994
Chateau du Lac, Genval, Belgium
organised by the European Commission with logistic
support from EWOS.
For information, email <ewos at spl.y-net.be>
NETWORK SERVICES CONFERENCE 94
- ------------------------------
from 28 to 30 November 1994
in London (UK)
For further information contact David Sitman (PC Vice Chairman) via
email: <A79 at TAUNIVM.bitnet>;
Paper submissions to: <NSC94 at EARNCC.EARN.NET>
WORKSHOP ON EUROPEAN USER REQUIREMENTS FOR
INTERNATIONALISATION OF IT AND CHARACTER SET TECHNOLOGY
- -------------------------------------------------------
on 1 and 2 December 1994
in Luxembourg.
Organised by CEN/TC304, sponsored by CEC/DGIII,
EFTA and STRI.
Registrations before 30 September 1994
For information, email <tobbi at iti.is>
IS&T/SPIE SYMPOSIUM ON ELECTRONIC IMAGING
- -----------------------------------------
from 5 till 11 February 1995
San Jose Convention Center, San Jose, California USA
- -> Multimedia Computing and Networking 1995 -> Digital Video
Compression: Algorithms & Technologies 1995
Tel.(206)676 3290 - Fax.(206)647 1445
EEMA MEETINGS
- -------------
Autumn Conference
14-16 September Madrid
Winter Conference
November (tbc) Luxembourg
Cooper [Page 46]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10229;
12 Aug 94 16:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10221;
12 Aug 94 16:16 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa16050;
12 Aug 94 16:16 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA26025 at pad-thai.aktis.com>; Fri, 12 Aug 1994 15:45:11 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA05340; Fri, 12 Aug 94 15:43:51 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94)
id AA08354; Fri, 12 Aug 94 12:35:29 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA02912; Fri, 12 Aug 94 15:35:30 -0400
Message-Id: <9408121935.AA02912 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 12 Aug 94 15:35:31 EDT
Date: Fri, 12 Aug 94 15:35:31 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 12-Aug-1994 1504" <wray at tuxedo.enet.dec.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Windows 3.1 client GSS-API
>> The other thing that I-D should do is nail down enough things so that we
>> can actually put together a DLL (dynamic link library) interface
>> standard. This would require nailing down the platform/mechanism
>> specific types which are delibarately left unspecified under RFC1509.
>> We should probably make them be void *'s, so that an implementation
>> still has some flexibility about what it needs to store.
>
>Iff this requirement isn't contentious - implying a trivial code change for
>existing implementations, and a recompile for existing applications - then
>agreement on a link-level compatibility standard is achievable.
It's a little contentious with me :-)
Using (void *) as a handle type implies that it's a pointer to something in an
address-space shared by all callers who want to share a single handle. RFC
1509 goes out of its way to avoid restricting such sharing to the process
level. In particular, Digital's GSSAPI implementation over DASS allowed
credentials to be inherited across a fork/exec, which meant that one program
could create a handle, and then invoke another program that would actually use
it.
The model that this was based on was that handles should behave like Unix file
descriptors, and they were implemented as small integers. I don't think that
you could implement these semantics if handles were pointers, at least not
without violating some of the ANSI-C restrictions about pointer use.
This may not be relevant to Windows, which doesn't really have processes, but I
don't think that this restriction should be introduced into RFC 1509.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10229;
12 Aug 94 16:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10221;
12 Aug 94 16:16 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa16050;
12 Aug 94 16:16 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA26025 at pad-thai.aktis.com>; Fri, 12 Aug 1994 15:45:11 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA05340; Fri, 12 Aug 94 15:43:51 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94)
id AA08354; Fri, 12 Aug 94 12:35:29 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA02912; Fri, 12 Aug 94 15:35:30 -0400
Message-Id: <9408121935.AA02912 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 12 Aug 94 15:35:31 EDT
Date: Fri, 12 Aug 94 15:35:31 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 12-Aug-1994 1504" <wray at tuxedo.enet.dec.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: Windows 3.1 client GSS-API
>> The other thing that I-D should do is nail down enough things so that we
>> can actually put together a DLL (dynamic link library) interface
>> standard. This would require nailing down the platform/mechanism
>> specific types which are delibarately left unspecified under RFC1509.
>> We should probably make them be void *'s, so that an implementation
>> still has some flexibility about what it needs to store.
>
>Iff this requirement isn't contentious - implying a trivial code change for
>existing implementations, and a recompile for existing applications - then
>agreement on a link-level compatibility standard is achievable.
It's a little contentious with me :-)
Using (void *) as a handle type implies that it's a pointer to something in an
address-space shared by all callers who want to share a single handle. RFC
1509 goes out of its way to avoid restricting such sharing to the process
level. In particular, Digital's GSSAPI implementation over DASS allowed
credentials to be inherited across a fork/exec, which meant that one program
could create a handle, and then invoke another program that would actually use
it.
The model that this was based on was that handles should behave like Unix file
descriptors, and they were implemented as small integers. I don't think that
you could implement these semantics if handles were pointers, at least not
without violating some of the ANSI-C restrictions about pointer use.
This may not be relevant to Windows, which doesn't really have processes, but I
don't think that this restriction should be introduced into RFC 1509.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00750;
13 Aug 94 4:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00740;
13 Aug 94 4:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01645;
13 Aug 94 4:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00726;
13 Aug 94 4:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00614;
13 Aug 94 4:45 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01501;
13 Aug 94 4:45 EDT
Received: from ocean.fit.qut.edu.au by venera.isi.edu (5.65c/5.61+local-18)
id <AA02461>; Sat, 13 Aug 1994 01:46:08 -0700
Received: from water.fit.qut.edu.au (water.fit.qut.edu.au [131.181.27.1]) by ocean.fit.qut.edu.au (8.6.9/8.6.9) with ESMTP id SAA17661 for <ietf at isi.edu>; Sat, 13 Aug 1994 18:44:41 +1000
Received: (from n1471601 at localhost) by water.fit.qut.edu.au (8.6.9/8.6.6) id SAA23516 for ietf at isi.edu; Sat, 13 Aug 1994 18:42:32 +1000
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: DEONG H TING <n1471601 at student.fit.qut.edu.au>
Message-Id: <199408130842.SAA23516 at water.fit.qut.edu.au>
Subject: subscribe
To: ietf at isi.edu
Date: Sat, 13 Aug 1994 18:42:31 +1000 (EST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 82
Please kindly register me onto your mailing list for any future news.
Thank you.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01768;
13 Aug 94 8:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01760;
13 Aug 94 8:35 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa04094;
13 Aug 94 8:35 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA10799 at pad-thai.aktis.com>; Sat, 13 Aug 1994 08:00:47 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA29756; Sat, 13 Aug 94 07:59:07 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <04032-0 at relay1.pipex.net>; Sat, 13 Aug 1994 12:58:50 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA26022; Sat, 13 Aug 94 13:00:35 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA23256;
Sat, 13 Aug 94 12:57:41 BST
Message-Id: <9408131200.AA03447 at getafix.oasis.icl.co.uk>
Date: Sat, 13 Aug 94 13:00:09 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: GSS-API implementation-defined types
To: cat-ietf at mit.edu
I have changed the subject line as there didn't seem to be disagreement
(yet?) about some parameter-passing changes for a _MS Windows 3.1_ C
binding.
---
If implementation-specific types were passed by (void *)reference into
UNIX GSS-API implementations, then this would permit a fully specified
standard which could allow UNIX object code / binaries to be linkable
with different providers' GSS-API libraries / shared objects. This would
be a Good Thing.
It would seem that names, credentials, and contexts could be passed in by
reference without breaking existing portable applications' use of GSS-API
implementations (merely by recompiling once against a new gssapi.h).
Hence a change to the currently defined syntax seems at least worth
considering for V2.
Comments?
----
Some more detailed comments on other mails follow.
> >The model that this was based on was that handles should behave like Unix file
> >descriptors, and they were implemented as small integers. I don't think that
> >you could implement these semantics if handles were pointers, at least not
> >without violating some of the ANSI-C restrictions about pointer use.
>
> Something like this would work: use a named environment variable
> sprintf(buff, "DIGITAL_GSSAPI_FD=%d", gssapi__fd);
> putenv(buff);
> And return buff (or strdup(buff) :-) as the handle.
>
> Importing credentials across fork are just atoi(getenv())
K&R (2nd edition) A6.6 says:
A pointer may be converted to an integral type large enough to hold it;
the required size is implementation-dependent. The mapping function is
implementation dependent.
An object of integral type may be explicitly converted to a pointer. The
mapping always carries a sufficiently wide integer converted from a
pointer back to the same pointer, but is otherwise
implementation-dependent.
Hence, there should be no problem (other than a wish for uncontorted and
maintainable code :-) to use context pointers to hold integers, and therefore
to implement inheritable contexts within the confines of a revised syntax.
> > This may not be relevant to Windows, which doesn't really have
> > processes, but I don't think that this restriction should be
> > introduced into RFC 1509.
>
> Yes, but a portable client can not make any assumptions about what the
> handles might be --- they could be small integers, or they could be
> pointers, or they could currently be a large structure. Hence, merely
> be not specifying the type of the handle, we have in essence put this
> restriction on portable clients anyway.
>
> So if a non-portable client wanted to be able to share credentials
> across processes, if it knew that the handle was an int *, it could
> dereference the handle and pass the small integer (that was pointed to
> by the handle) across a fork/exec boundary, and the child could store it
> in an integer variable and create a handle by using the address of the
> integer variable.
>
> This is non-portable, but so is assuming that the handle was an integer
> to begin with.
Some further thoughts in the same vein as comments from Rich and Ted follow:
(originally just sent in reply to John partly as I couldn't make out
from the "cc" whether or not his message had gone to this list, and
partly because I wanted to check I had understood the implications of the
model he described correctly - which I now assume I probably did from
Ted's comments)
How did/does this approach cope with
- the downside of fd inheritance - i.e. if I fork then I must close the
credential/context if I don't want them inherited by a undeserving
program?). Does this have to be done explicitly?
- setuid programs - i.e. how can credentials/contexts be accessed if it is
created by a process under ones uid, and accessed by a (child) process under
another uid?
- ownership - i.e. need to maintain a reference count of opens? or
can multiple processes use credentials and contexts at once?
Also, how were the credential references passed - in the environment?
Doesn't this means some special processing or reserved values?
The GSS-API doesn't define how these cases are handled, so while I
see that you can pass small integers, the portable use of such
a scheme is not completely specified in 1509.
I would have thought that the requirement to portably support
credential inheritance on UNIX systems could be better accomplished
via a very few explicit set of DCE-style import/export primitives, or
even simpler, environment inheritance support calls.
e.g.: set_cred_inheritable(cred_han, &small_number); /* for parent */
get_inheritable_cred(small_number, &cred_han); /* for child */
---
Piers
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02286;
13 Aug 94 10:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02277;
13 Aug 94 10:11 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05228;
13 Aug 94 10:11 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA12351 at pad-thai.aktis.com>; Sat, 13 Aug 1994 09:48:35 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA00918; Sat, 13 Aug 94 09:47:12 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA21981; Sat, 13 Aug 94 09:47:05 EDT
Date: Sat, 13 Aug 94 09:47:05 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408131347.AA21981 at tsx-11.MIT.EDU>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk's message of Sat, 13 Aug 94 13:00:09 BST,
<9408131200.AA03447 at getafix.oasis.icl.co.uk>
Subject: Re: GSS-API implementation-defined types
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
One more thing we'll need to consider for the MS-DOS implementation
types for maximal link-type interoperability --- structure packing. Our
Windows expert suggested that we might want to mandate that structure
elements be packed on 4-byte boundaries, to make it easier to move to
32-bit code in the future (NT, Chicago, etc.). This will mean that
people will need to put in #pragma's for their current 16-bit compilers
(which typically are only aligning structures on a 2-byte boundary) but
this is apparently not hard to do. In any case, if we're shooting for
link-level compatibility, we will need say something about structure
packing.
(I assume people can see why we've ducked the issue of link-level
compatibility in the past; as soon you as raise that as a potential
requirement, all sorts of issues come bubbling up!)
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04754;
13 Aug 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04746;
13 Aug 94 16:36 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa10516;
13 Aug 94 16:36 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA17987 at pad-thai.aktis.com>; Sat, 13 Aug 1994 16:15:53 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA07976; Sat, 13 Aug 94 16:14:17 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <11212-0 at relay1.pipex.net>; Sat, 13 Aug 1994 21:14:12 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA27271; Sat, 13 Aug 94 21:15:59 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA24435;
Sat, 13 Aug 94 21:13:06 BST
Message-Id: <9408132015.AA26343 at getafix.oasis.icl.co.uk>
Date: Sat, 13 Aug 94 21:15:32 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: re: MS Windows structure alignment
To: cat-ietf at mit.edu
> this is apparently not hard to do. In any case, if we're shooting for
Putting "#pragma pack(N)" in the source is avoidable through use of
a compilation option (/ZpN for MS C/C++ V7).
> link-level compatibility, we will need say something about structure
> packing.
The default packing alignment for 16-bit targets is 2 bytes, whereas for
32-bit targets, it's 4 bytes. Given that most (but not all) members of
GSS-API structures are pointer or 32 bit integer, trying to squeeze a
few bytes by aiming for 2 byte alignment (i.e. code optimisation for
16-bit targets) seems not to be worthwhile. Hence 4 byte packing seems
sensible.
> (I assume people can see why we've ducked the issue of link-level
> compatibility in the past; as soon you as raise that as a potential
> requirement, all sorts of issues come bubbling up!)
If a general interface standard can be (sort of) achieved for winsockets, it
should be achievable for GSS-API ...
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04943;
15 Aug 94 11:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08779;
15 Aug 94 11:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04923;
15 Aug 94 11:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04626;
15 Aug 94 11:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pem-dev at tis.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-ansix9.17-00.txt
Date: Mon, 15 Aug 94 11:09:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408151109.aa04626 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : Privacy Enhancement for Internet Electronic Mail:
Part V: ANSI X9.17-Based Key Management
Author(s) : J. Backus
Filename : draft-ietf-pem-ansix9.17-00.txt
Pages : 7
Date : 08/12/1994
This document provides definitions, formats, references, and citations for
the use of ANSI X9.17 compliant key management in support of Privacy
Enhanced Mail (PEM) in the Internet community. It is intended to become
one member of the set of related PEM RFCs.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pem-ansix9.17-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-pem-ansix9.17-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pem-ansix9.17-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pem-ansix9.17-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04943;
15 Aug 94 11:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08779;
15 Aug 94 11:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04923;
15 Aug 94 11:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04626;
15 Aug 94 11:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pem-dev at tis.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-ansix9.17-00.txt
Date: Mon, 15 Aug 94 11:09:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408151109.aa04626 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : Privacy Enhancement for Internet Electronic Mail:
Part V: ANSI X9.17-Based Key Management
Author(s) : J. Backus
Filename : draft-ietf-pem-ansix9.17-00.txt
Pages : 7
Date : 08/12/1994
This document provides definitions, formats, references, and citations for
the use of ANSI X9.17 compliant key management in support of Privacy
Enhanced Mail (PEM) in the Internet community. It is intended to become
one member of the set of related PEM RFCs.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pem-ansix9.17-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-pem-ansix9.17-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pem-ansix9.17-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pem-ansix9.17-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04954;
15 Aug 94 11:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04943;
15 Aug 94 11:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08779;
15 Aug 94 11:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04923;
15 Aug 94 11:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04626;
15 Aug 94 11:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pem-dev at tis.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-ansix9.17-00.txt
Date: Mon, 15 Aug 94 11:09:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408151109.aa04626 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : Privacy Enhancement for Internet Electronic Mail:
Part V: ANSI X9.17-Based Key Management
Author(s) : J. Backus
Filename : draft-ietf-pem-ansix9.17-00.txt
Pages : 7
Date : 08/12/1994
This document provides definitions, formats, references, and citations for
the use of ANSI X9.17 compliant key management in support of Privacy
Enhanced Mail (PEM) in the Internet community. It is intended to become
one member of the set of related PEM RFCs.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pem-ansix9.17-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-pem-ansix9.17-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pem-ansix9.17-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pem-ansix9.17-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05501;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09186;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05477;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05289;
15 Aug 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09104;
15 Aug 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05283;
15 Aug 94 11:41 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Exterior Gateway Protocol formal specification to Historic
Date: Mon, 15 Aug 94 11:41:11 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151141.aa05283 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the BGP Working Group to
consider moving "Exterior Gateway Protocol formal specification"
(RFC 904) to Historic.
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 cnri.reston.va.us or ietf at cnri.reston.va.us mailing
lists by 29 August.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05501;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09186;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05477;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05289;
15 Aug 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09104;
15 Aug 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05283;
15 Aug 94 11:41 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Exterior Gateway Protocol formal specification to Historic
Date: Mon, 15 Aug 94 11:41:11 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151141.aa05283 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the BGP Working Group to
consider moving "Exterior Gateway Protocol formal specification"
(RFC 904) to Historic.
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 cnri.reston.va.us or ietf at cnri.reston.va.us mailing
lists by 29 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05512;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05501;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09186;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05477;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05289;
15 Aug 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09104;
15 Aug 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05283;
15 Aug 94 11:41 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Exterior Gateway Protocol formal specification to Historic
Date: Mon, 15 Aug 94 11:41:11 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151141.aa05283 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the BGP Working Group to
consider moving "Exterior Gateway Protocol formal specification"
(RFC 904) to Historic.
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 cnri.reston.va.us or ietf at cnri.reston.va.us mailing
lists by 29 August.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05518;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09196;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05479;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05274;
15 Aug 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09099;
15 Aug 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05269;
15 Aug 94 11:40 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Requirements for Internet gateways to Historic
Date: Mon, 15 Aug 94 11:40:56 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151140.aa05269 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the BGP Working Group to
consider moving "Requirements for Internet gateways" (RFC 1009)
to Historic.
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 cnri.reston.va.us or ietf at cnri.reston.va.us mailing
lists by 29 August.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05518;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09196;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05479;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05274;
15 Aug 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09099;
15 Aug 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05269;
15 Aug 94 11:40 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Requirements for Internet gateways to Historic
Date: Mon, 15 Aug 94 11:40:56 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151140.aa05269 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the BGP Working Group to
consider moving "Requirements for Internet gateways" (RFC 1009)
to Historic.
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 cnri.reston.va.us or ietf at cnri.reston.va.us mailing
lists by 29 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05529;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05518;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09196;
15 Aug 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05479;
15 Aug 94 11:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05274;
15 Aug 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09099;
15 Aug 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05269;
15 Aug 94 11:40 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Requirements for Internet gateways to Historic
Date: Mon, 15 Aug 94 11:40:56 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151140.aa05269 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the BGP Working Group to
consider moving "Requirements for Internet gateways" (RFC 1009)
to Historic.
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 cnri.reston.va.us or ietf at cnri.reston.va.us mailing
lists by 29 August.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05627;
15 Aug 94 11:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05623;
15 Aug 94 11:50 EDT
Received: from relay.tis.com by CNRI.Reston.VA.US id aa09341;
15 Aug 94 11:50 EDT
Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3)
id sma007173; Mon Aug 15 11:37:05 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa07780;
15 Aug 94 11:34 EDT
Received: from sol.tis.com by magellan.TIS.COM id aa07776; 15 Aug 94 11:30 EDT
Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3)
id sma007043; Mon Aug 15 11:30:29 1994
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04626;
15 Aug 94 11:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com at CNRI.Reston.VA.US, tis.com at magellan.tis.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM
Cc: pem-dev at tis.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-ansix9.17-00.txt
Date: Mon, 15 Aug 94 11:09:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408151109.aa04626 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : Privacy Enhancement for Internet Electronic Mail:
Part V: ANSI X9.17-Based Key Management
Author(s) : J. Backus
Filename : draft-ietf-pem-ansix9.17-00.txt
Pages : 7
Date : 08/12/1994
This document provides definitions, formats, references, and citations for
the use of ANSI X9.17 compliant key management in support of Privacy
Enhanced Mail (PEM) in the Internet community. It is intended to become
one member of the set of related PEM RFCs.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pem-ansix9.17-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-pem-ansix9.17-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pem-ansix9.17-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pem-ansix9.17-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940812110805.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07114;
15 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11314;
15 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07082;
15 Aug 94 13:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06943;
15 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11183;
15 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06936;
15 Aug 94 13:17 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Transport Multiplexing Protocol (TMux) to
Proposed Standard
Date: Mon, 15 Aug 94 13:17:29 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151317.aa06936 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Transport Multiplexing
Protocol (TMux)" <draft-cameron-tmux-03.txt> as a Proposed Standard.
This document is not the product of an IETF working group, but has
been reviewed in the Transport Area of the IETF. The IESG contact
person is Allison Mankin.
Technical Summary
One of the problems with the use of terminal servers is the large
number of small packets they can generate. Frequently, most of
these packets are destined for only one or two hosts. The overhead
(interrupt and other) for processing a short packet on a host or
terminal server can be very high, and terminal server vendors have
found that TCP/IP without a protocol like TMux performs poorly
compared with some proprietary protocols such as Digital Equipment
Corporation's LAT. TMux is a protocol which allows multiple short
transport segments, independent of application type, to be combined
robustly between a server and host pair.
A TMux message appears as:
| IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
Where:
TM hdr is a TMux mini-header and specifies the following
Tport segment.
Tport segment refers to the entire transport segment, including
transport headers.
Each 4 octet TMux mini-header has the following general format:
+-------------------------------+
| Length |
| |
| |
+-------------------------------+
| Protocol ID |
+-------------------------------+
| Checksum |
+-------------------------------+
| Transport segment |
| ... |
| ... |
The Protocol ID field contains the value that would normally have
been placed in the IP header Protocol field.
The 'Checksum' field is the XOR of the first 3 octets.
TMux operates as an extension to the IP datagram protocol. Hence, it
has no impact on most flow control mechanisms, since they operate at
the transport layer -- above TMux. This was the subject of careful
review by the Transport Area.
The specification includes details of a dynamic and stateless method
of turning TMux operation on and off, as well as a timeout for
accumulating short segments with suggested value supported by
performance measurements.
TMux is proposed with an Applicability Statement because it is known
by experiment to be effective in the case of a large terminal server
in the local area, and it may not be applicable for other environments.
Implementations are expected to not use TMux for packets of 700 bytes
or more. A robust and fast mechanism is specified for turning the use
of TMux on and off dynamically. The specification recommends also that
routers use protocol filtering to not forward TMux traffic (it is IP
protocol type 18). Hosts or servers that send a TMux ENQuiry message
and do not receive TMux traffic or a TMUX ENQ in reply simply send
unmultiplexed transport over IP datagrams.
Performance results for this terminal server case were detailed in
the TMux BOF at the Houston (November '93) IETF meeting. In its
applicability environment, TMux is a valuable optimization.
Working Group Summary
At the Amsterdam IETF, Peter Cameron and Jim Barnes made an
initial proposal to address the terminal server problem with
CMP (connection multiplexing protocol), a layer over TCP. It
was found to have architectural and performance faults, and the
beginnings of the TMux proposal were offered by Dave Crocker.
Jon Postel and Danny Cohen had made a very similar proposal to
TMux in IEN 90 in YEAR. The strong consensus of those attending
the Amsterdam CMP BOF was that the TMux approach was superior to
CMP and highly promising.
A TMux BOF was convened at the Houston IETF, to report on the
refinement of TMux over email and on implementation experiences.
Performance improvements fulfilling the goals of the proposal were
reported. There was strong consensus in the Houston BOF that the
protocol proposal was valid and should receive a few more
corrections and then be submitted to the standards track.
The Transport Area Director requested that an Applicability
Statement be made with the protocol proposal, because of the
specialized, though sizeable, constituency for a terminal server
optimization. There were several rounds of revision of the protocol
based on review in the Transport Area and the IETF in general. The
Last Call on the Internet-Draft of the specification did not generate
any responses, and there is consensus in the Transport Area
Directorate that the proposal merits Proposed Standard status.
Protocol Quality
The protocol specification was extensively reviewed by the Transport
Area Directorate, including written reviews by Dave Borman and Greg
Minshall, and by the area director. Experimental implementations
were done by two known groups and two vendors are known to have
completed product-quality implementations.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07114;
15 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11314;
15 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07082;
15 Aug 94 13:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06943;
15 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11183;
15 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06936;
15 Aug 94 13:17 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Transport Multiplexing Protocol (TMux) to
Proposed Standard
Date: Mon, 15 Aug 94 13:17:29 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151317.aa06936 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Transport Multiplexing
Protocol (TMux)" <draft-cameron-tmux-03.txt> as a Proposed Standard.
This document is not the product of an IETF working group, but has
been reviewed in the Transport Area of the IETF. The IESG contact
person is Allison Mankin.
Technical Summary
One of the problems with the use of terminal servers is the large
number of small packets they can generate. Frequently, most of
these packets are destined for only one or two hosts. The overhead
(interrupt and other) for processing a short packet on a host or
terminal server can be very high, and terminal server vendors have
found that TCP/IP without a protocol like TMux performs poorly
compared with some proprietary protocols such as Digital Equipment
Corporation's LAT. TMux is a protocol which allows multiple short
transport segments, independent of application type, to be combined
robustly between a server and host pair.
A TMux message appears as:
| IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
Where:
TM hdr is a TMux mini-header and specifies the following
Tport segment.
Tport segment refers to the entire transport segment, including
transport headers.
Each 4 octet TMux mini-header has the following general format:
+-------------------------------+
| Length |
| |
| |
+-------------------------------+
| Protocol ID |
+-------------------------------+
| Checksum |
+-------------------------------+
| Transport segment |
| ... |
| ... |
The Protocol ID field contains the value that would normally have
been placed in the IP header Protocol field.
The 'Checksum' field is the XOR of the first 3 octets.
TMux operates as an extension to the IP datagram protocol. Hence, it
has no impact on most flow control mechanisms, since they operate at
the transport layer -- above TMux. This was the subject of careful
review by the Transport Area.
The specification includes details of a dynamic and stateless method
of turning TMux operation on and off, as well as a timeout for
accumulating short segments with suggested value supported by
performance measurements.
TMux is proposed with an Applicability Statement because it is known
by experiment to be effective in the case of a large terminal server
in the local area, and it may not be applicable for other environments.
Implementations are expected to not use TMux for packets of 700 bytes
or more. A robust and fast mechanism is specified for turning the use
of TMux on and off dynamically. The specification recommends also that
routers use protocol filtering to not forward TMux traffic (it is IP
protocol type 18). Hosts or servers that send a TMux ENQuiry message
and do not receive TMux traffic or a TMUX ENQ in reply simply send
unmultiplexed transport over IP datagrams.
Performance results for this terminal server case were detailed in
the TMux BOF at the Houston (November '93) IETF meeting. In its
applicability environment, TMux is a valuable optimization.
Working Group Summary
At the Amsterdam IETF, Peter Cameron and Jim Barnes made an
initial proposal to address the terminal server problem with
CMP (connection multiplexing protocol), a layer over TCP. It
was found to have architectural and performance faults, and the
beginnings of the TMux proposal were offered by Dave Crocker.
Jon Postel and Danny Cohen had made a very similar proposal to
TMux in IEN 90 in YEAR. The strong consensus of those attending
the Amsterdam CMP BOF was that the TMux approach was superior to
CMP and highly promising.
A TMux BOF was convened at the Houston IETF, to report on the
refinement of TMux over email and on implementation experiences.
Performance improvements fulfilling the goals of the proposal were
reported. There was strong consensus in the Houston BOF that the
protocol proposal was valid and should receive a few more
corrections and then be submitted to the standards track.
The Transport Area Director requested that an Applicability
Statement be made with the protocol proposal, because of the
specialized, though sizeable, constituency for a terminal server
optimization. There were several rounds of revision of the protocol
based on review in the Transport Area and the IETF in general. The
Last Call on the Internet-Draft of the specification did not generate
any responses, and there is consensus in the Transport Area
Directorate that the proposal merits Proposed Standard status.
Protocol Quality
The protocol specification was extensively reviewed by the Transport
Area Directorate, including written reviews by Dave Borman and Greg
Minshall, and by the area director. Experimental implementations
were done by two known groups and two vendors are known to have
completed product-quality implementations.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07127;
15 Aug 94 13:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07114;
15 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11314;
15 Aug 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07082;
15 Aug 94 13:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06943;
15 Aug 94 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11183;
15 Aug 94 13:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06936;
15 Aug 94 13:17 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Transport Multiplexing Protocol (TMux) to
Proposed Standard
Date: Mon, 15 Aug 94 13:17:29 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151317.aa06936 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Transport Multiplexing
Protocol (TMux)" <draft-cameron-tmux-03.txt> as a Proposed Standard.
This document is not the product of an IETF working group, but has
been reviewed in the Transport Area of the IETF. The IESG contact
person is Allison Mankin.
Technical Summary
One of the problems with the use of terminal servers is the large
number of small packets they can generate. Frequently, most of
these packets are destined for only one or two hosts. The overhead
(interrupt and other) for processing a short packet on a host or
terminal server can be very high, and terminal server vendors have
found that TCP/IP without a protocol like TMux performs poorly
compared with some proprietary protocols such as Digital Equipment
Corporation's LAT. TMux is a protocol which allows multiple short
transport segments, independent of application type, to be combined
robustly between a server and host pair.
A TMux message appears as:
| IP hdr | TM hdr | Tport segment | TM hdr | Tport segment| ...|
Where:
TM hdr is a TMux mini-header and specifies the following
Tport segment.
Tport segment refers to the entire transport segment, including
transport headers.
Each 4 octet TMux mini-header has the following general format:
+-------------------------------+
| Length |
| |
| |
+-------------------------------+
| Protocol ID |
+-------------------------------+
| Checksum |
+-------------------------------+
| Transport segment |
| ... |
| ... |
The Protocol ID field contains the value that would normally have
been placed in the IP header Protocol field.
The 'Checksum' field is the XOR of the first 3 octets.
TMux operates as an extension to the IP datagram protocol. Hence, it
has no impact on most flow control mechanisms, since they operate at
the transport layer -- above TMux. This was the subject of careful
review by the Transport Area.
The specification includes details of a dynamic and stateless method
of turning TMux operation on and off, as well as a timeout for
accumulating short segments with suggested value supported by
performance measurements.
TMux is proposed with an Applicability Statement because it is known
by experiment to be effective in the case of a large terminal server
in the local area, and it may not be applicable for other environments.
Implementations are expected to not use TMux for packets of 700 bytes
or more. A robust and fast mechanism is specified for turning the use
of TMux on and off dynamically. The specification recommends also that
routers use protocol filtering to not forward TMux traffic (it is IP
protocol type 18). Hosts or servers that send a TMux ENQuiry message
and do not receive TMux traffic or a TMUX ENQ in reply simply send
unmultiplexed transport over IP datagrams.
Performance results for this terminal server case were detailed in
the TMux BOF at the Houston (November '93) IETF meeting. In its
applicability environment, TMux is a valuable optimization.
Working Group Summary
At the Amsterdam IETF, Peter Cameron and Jim Barnes made an
initial proposal to address the terminal server problem with
CMP (connection multiplexing protocol), a layer over TCP. It
was found to have architectural and performance faults, and the
beginnings of the TMux proposal were offered by Dave Crocker.
Jon Postel and Danny Cohen had made a very similar proposal to
TMux in IEN 90 in YEAR. The strong consensus of those attending
the Amsterdam CMP BOF was that the TMux approach was superior to
CMP and highly promising.
A TMux BOF was convened at the Houston IETF, to report on the
refinement of TMux over email and on implementation experiences.
Performance improvements fulfilling the goals of the proposal were
reported. There was strong consensus in the Houston BOF that the
protocol proposal was valid and should receive a few more
corrections and then be submitted to the standards track.
The Transport Area Director requested that an Applicability
Statement be made with the protocol proposal, because of the
specialized, though sizeable, constituency for a terminal server
optimization. There were several rounds of revision of the protocol
based on review in the Transport Area and the IETF in general. The
Last Call on the Internet-Draft of the specification did not generate
any responses, and there is consensus in the Transport Area
Directorate that the proposal merits Proposed Standard status.
Protocol Quality
The protocol specification was extensively reviewed by the Transport
Area Directorate, including written reviews by Dave Borman and Greg
Minshall, and by the area director. Experimental implementations
were done by two known groups and two vendors are known to have
completed product-quality implementations.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07945;
15 Aug 94 13:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11943;
15 Aug 94 13:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07908;
15 Aug 94 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07708;
15 Aug 94 13:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11845;
15 Aug 94 13:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07701;
15 Aug 94 13:43 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: Inter-Domain Routing Working Group (IDR)
Date: Mon, 15 Aug 94 13:43:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151343.aa07701 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Routing Area
of the IETF. This new working group represents the
merging of the "Border Gateway Protocol (BGP)" and "OSI
Inter-Domain Routing Protocol for IP Over IP (IPIDRP)"
Working Groups.
IESG Secretary
Inter-Domain Routing Working Group (idr)
----------------------------------------
Charter
Current status: active working group
Chair(s):
Sue Hares <skh at merit.edu>
Yakov Rekhter <yakov at watson.ibm.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:bgp at ans.net
To Subscribe: bgp-request at ans.net
Archive: merit.edu:/pub/archive/bgp
Description of Working Group:
The main list for this working group is "bgp at ans.net", but there is
also an IDRP-specific mailing list:
- List: idrp at merit.edu
- To Subscribe: idrp-request at merit.edu
- Archive: merit.edu:/pub/archive/idrp
The Inter-Domain Routing Working Group is chartered to standardize and
promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter-
Domain Routing Protocol (IDRP) as scalable inter-autonomous system
routing protocols capable of supporting policy based routing for TCP/IP
internets. The objective is to promote the use of BGP-4 to support
IP version 4 (IPv4). IDRP is seen as a protocol that will support
IPv4 as well as the next generation of IP (IPv6).
The working group will plan a smooth transition between BGP-4 and IDRP.
Documents:
1) BGP-4 (standards track)
This document contains the specification of the BGP protocol that
enables it to be used as a protocol for exchange of ``inter-
autonomous system information'' among routers to support forwarding
of IPv4 packets across multiple autonomous systems.
2) BGP-4 MIB (standards track)
This document contains the MIB definitions for BGP-4.
3) IDRP for IPv4 over IPv4 (standards track)
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support forwarding of IPv4 packets across multiple autonomous
systems.
4) IDRP MIB (standards track)
This document contains the MIB definitions for IDRP.
5) BGP/IDRP -- OSPF Interactions (standards track)
This document will specify the interactions between BGP/IDRP and
OSPF. This document will be based on a combination of the BGP -- OSPF
interactions, and IDRP -- IS-IS interaction documents.
6) BGP/IDRP for IPv4 Usage (standards track)
Most of IDRP for IPv4 Usage will reference the CIDR (supernetting)
RFCs and related Internet-Drafts. IDRP for IPv4 Usage will contain
a sample policy configuration language, and examples on how to use
IDRP for IPv4 in the Internet today.
7) IDRP for IPv6
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support the forwarding of IPv6 packets across multiple
autonomous systems.
8) IDRP for IP Next Generation Usage
The IDRP for IPv6 Usage document will contain instructions on
how to run IDRP for IPv6 over IPv4 and IPv6.
Goals and Milestones:
Jul 94 IDRP for IP Internet-Draft updated.
Jul 94 IDRP MIB Internet-Draft updated.
Jul 94 IDRP/BGP Usage Internet-Draft updated.
Aug 94 IDRP/BGP -- OSPF Interactions Internet-Draft updated.
Nov 94 IDRP for IP submitted for Proposed Standard.
Nov 94 IDRP MIB submitted for Proposed Standard.
Nov 94 IDRP/BGP Usage submitted for Proposed Standard.
Nov 94 IDRP -- OSPF Interactions submitted for Proposed Standard.
Nov 94 IDRP for IPng Internet-Draft submitted.
Dec 94 IDRP MIB for IPng Internet-Draft submitted.
Dec 94 IDRP Usage for IPng Internet-Draft submitted.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07945;
15 Aug 94 13:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11943;
15 Aug 94 13:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07908;
15 Aug 94 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07708;
15 Aug 94 13:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11845;
15 Aug 94 13:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07701;
15 Aug 94 13:43 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: Inter-Domain Routing Working Group (IDR)
Date: Mon, 15 Aug 94 13:43:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151343.aa07701 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Routing Area
of the IETF. This new working group represents the
merging of the "Border Gateway Protocol (BGP)" and "OSI
Inter-Domain Routing Protocol for IP Over IP (IPIDRP)"
Working Groups.
IESG Secretary
Inter-Domain Routing Working Group (idr)
----------------------------------------
Charter
Current status: active working group
Chair(s):
Sue Hares <skh at merit.edu>
Yakov Rekhter <yakov at watson.ibm.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:bgp at ans.net
To Subscribe: bgp-request at ans.net
Archive: merit.edu:/pub/archive/bgp
Description of Working Group:
The main list for this working group is "bgp at ans.net", but there is
also an IDRP-specific mailing list:
- List: idrp at merit.edu
- To Subscribe: idrp-request at merit.edu
- Archive: merit.edu:/pub/archive/idrp
The Inter-Domain Routing Working Group is chartered to standardize and
promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter-
Domain Routing Protocol (IDRP) as scalable inter-autonomous system
routing protocols capable of supporting policy based routing for TCP/IP
internets. The objective is to promote the use of BGP-4 to support
IP version 4 (IPv4). IDRP is seen as a protocol that will support
IPv4 as well as the next generation of IP (IPv6).
The working group will plan a smooth transition between BGP-4 and IDRP.
Documents:
1) BGP-4 (standards track)
This document contains the specification of the BGP protocol that
enables it to be used as a protocol for exchange of ``inter-
autonomous system information'' among routers to support forwarding
of IPv4 packets across multiple autonomous systems.
2) BGP-4 MIB (standards track)
This document contains the MIB definitions for BGP-4.
3) IDRP for IPv4 over IPv4 (standards track)
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support forwarding of IPv4 packets across multiple autonomous
systems.
4) IDRP MIB (standards track)
This document contains the MIB definitions for IDRP.
5) BGP/IDRP -- OSPF Interactions (standards track)
This document will specify the interactions between BGP/IDRP and
OSPF. This document will be based on a combination of the BGP -- OSPF
interactions, and IDRP -- IS-IS interaction documents.
6) BGP/IDRP for IPv4 Usage (standards track)
Most of IDRP for IPv4 Usage will reference the CIDR (supernetting)
RFCs and related Internet-Drafts. IDRP for IPv4 Usage will contain
a sample policy configuration language, and examples on how to use
IDRP for IPv4 in the Internet today.
7) IDRP for IPv6
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support the forwarding of IPv6 packets across multiple
autonomous systems.
8) IDRP for IP Next Generation Usage
The IDRP for IPv6 Usage document will contain instructions on
how to run IDRP for IPv6 over IPv4 and IPv6.
Goals and Milestones:
Jul 94 IDRP for IP Internet-Draft updated.
Jul 94 IDRP MIB Internet-Draft updated.
Jul 94 IDRP/BGP Usage Internet-Draft updated.
Aug 94 IDRP/BGP -- OSPF Interactions Internet-Draft updated.
Nov 94 IDRP for IP submitted for Proposed Standard.
Nov 94 IDRP MIB submitted for Proposed Standard.
Nov 94 IDRP/BGP Usage submitted for Proposed Standard.
Nov 94 IDRP -- OSPF Interactions submitted for Proposed Standard.
Nov 94 IDRP for IPng Internet-Draft submitted.
Dec 94 IDRP MIB for IPng Internet-Draft submitted.
Dec 94 IDRP Usage for IPng Internet-Draft submitted.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07959;
15 Aug 94 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07945;
15 Aug 94 13:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11943;
15 Aug 94 13:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07908;
15 Aug 94 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07708;
15 Aug 94 13:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11845;
15 Aug 94 13:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07701;
15 Aug 94 13:43 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: Inter-Domain Routing Working Group (IDR)
Date: Mon, 15 Aug 94 13:43:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151343.aa07701 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Routing Area
of the IETF. This new working group represents the
merging of the "Border Gateway Protocol (BGP)" and "OSI
Inter-Domain Routing Protocol for IP Over IP (IPIDRP)"
Working Groups.
IESG Secretary
Inter-Domain Routing Working Group (idr)
----------------------------------------
Charter
Current status: active working group
Chair(s):
Sue Hares <skh at merit.edu>
Yakov Rekhter <yakov at watson.ibm.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:bgp at ans.net
To Subscribe: bgp-request at ans.net
Archive: merit.edu:/pub/archive/bgp
Description of Working Group:
The main list for this working group is "bgp at ans.net", but there is
also an IDRP-specific mailing list:
- List: idrp at merit.edu
- To Subscribe: idrp-request at merit.edu
- Archive: merit.edu:/pub/archive/idrp
The Inter-Domain Routing Working Group is chartered to standardize and
promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter-
Domain Routing Protocol (IDRP) as scalable inter-autonomous system
routing protocols capable of supporting policy based routing for TCP/IP
internets. The objective is to promote the use of BGP-4 to support
IP version 4 (IPv4). IDRP is seen as a protocol that will support
IPv4 as well as the next generation of IP (IPv6).
The working group will plan a smooth transition between BGP-4 and IDRP.
Documents:
1) BGP-4 (standards track)
This document contains the specification of the BGP protocol that
enables it to be used as a protocol for exchange of ``inter-
autonomous system information'' among routers to support forwarding
of IPv4 packets across multiple autonomous systems.
2) BGP-4 MIB (standards track)
This document contains the MIB definitions for BGP-4.
3) IDRP for IPv4 over IPv4 (standards track)
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support forwarding of IPv4 packets across multiple autonomous
systems.
4) IDRP MIB (standards track)
This document contains the MIB definitions for IDRP.
5) BGP/IDRP -- OSPF Interactions (standards track)
This document will specify the interactions between BGP/IDRP and
OSPF. This document will be based on a combination of the BGP -- OSPF
interactions, and IDRP -- IS-IS interaction documents.
6) BGP/IDRP for IPv4 Usage (standards track)
Most of IDRP for IPv4 Usage will reference the CIDR (supernetting)
RFCs and related Internet-Drafts. IDRP for IPv4 Usage will contain
a sample policy configuration language, and examples on how to use
IDRP for IPv4 in the Internet today.
7) IDRP for IPv6
This document contains the appropriate adaptations of the IDRP
protocol definition that enables it to be used as a protocol for
exchange of ``inter-autonomous system information'' among routers
to support the forwarding of IPv6 packets across multiple
autonomous systems.
8) IDRP for IP Next Generation Usage
The IDRP for IPv6 Usage document will contain instructions on
how to run IDRP for IPv6 over IPv4 and IPv6.
Goals and Milestones:
Jul 94 IDRP for IP Internet-Draft updated.
Jul 94 IDRP MIB Internet-Draft updated.
Jul 94 IDRP/BGP Usage Internet-Draft updated.
Aug 94 IDRP/BGP -- OSPF Interactions Internet-Draft updated.
Nov 94 IDRP for IP submitted for Proposed Standard.
Nov 94 IDRP MIB submitted for Proposed Standard.
Nov 94 IDRP/BGP Usage submitted for Proposed Standard.
Nov 94 IDRP -- OSPF Interactions submitted for Proposed Standard.
Nov 94 IDRP for IPng Internet-Draft submitted.
Dec 94 IDRP MIB for IPng Internet-Draft submitted.
Dec 94 IDRP Usage for IPng Internet-Draft submitted.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08043;
15 Aug 94 13:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12005;
15 Aug 94 13:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08020;
15 Aug 94 13:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07912;
15 Aug 94 13:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11928;
15 Aug 94 13:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07900;
15 Aug 94 13:46 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: New Internet Routing and Addressing Architecture (nimrod)
Date: Mon, 15 Aug 94 13:46:51 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151346.aa07900 at IETF.CNRI.Reston.VA.US>
A new working group has been created in the Routing Area of
the IETF. Please contact the chairs or area director for
more information.
IESG Secretary
New Internet Routing and Addressing Architecture (nimrod)
---------------------------------------------------------
Charter
Current status: active working group
Chair(s):
J. Noel Chiappa <jnc at lcs.mit.edu>
Isidro Castineyra <isidro at bbn.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:nimrod-wg at bbn.com
To Subscribe: nimrod-wg-request at bbn.com
Archive: bbn.com:/pub/nimrod-wg/nimrod-wg.archive
Description of Working Group:
The goal of the working group is to design, specify, implement and test a
flexible new routing and addressing architecture suitable for very large
scale internets. The basic architecture for computation of routes will
be based on distribution of network topology maps, with source-specified
route selection, and unitary (i.e., not hop-by-hop) computation of routes.
The architecture will provide a single homogeneous framework for all
routing, including both inter-domain and intra-domain. It will include a
new network component naming abstraction hierarchy, starting from network
attachment points, and based on actual connectivity, but taking into
consideration policy requirements. These new names will be variable
length, with a variable number of levels of abstraction; they will not
appear in most packets, though.
Actual packet forwarding will be based both on retained non-critical
state in the switches (via flow setup for long-lived communications), and
both classical address-only, as well as source-route type instructions, in
individual packets (for datagram applications which send only one, or a very
few, packets).
Although the general design and algorithms will be usable in any
internetworking protocol family, the initial detailed protocol
specifications and implementation are currently planned for deployment
with IPv4, but support for another packet format may be substituted or
added, depending on the situation in the Internet in the future.
Interoperabilty with existing unmodified IPv4 hosts will be achieved by
re-interpreting the existing source and destination fields in IPv4
packets as endpoint identifiers.
A substantial effort to take into account support for mobility,
multicast and resource allocation will be made when designing the Nimrod
architecture; provided that so doing is neither impossible because of
incomplete work outside the scope of Nimrod, nor the cause of very
substantial delays in the first iteration of the protocol design.
Goals and Milestones:
Oct 93 Commence project.
Jan 94 Complete the review and discussion of the fundamentals of the routing
and addressing architecture.
Feb 94 Produce a draft architecture document, which will also serve as an
in-depth introduction to Nimrod.
Jul 94 Issue Internet-Drafts containing the design of the basic routing and
addressing architecture and protocols.
Sep 94 Produce a first version of the protocol specification, which embodies
the completed basic routing and addressing architecture. Issue this
document as an Internet-Draft.
Nov 94 Finish design of all the detailed mechanisms, including sample
algorithms for those parts which are outside the core specification.
Issue an Internet-Draft describing these.
Dec 94 Issue a usage guide as an Internet-Draft. This guide will describe
recommended clustering strategies and configurations.
Jul 95 Finish an initial prototype protocol implementation, suitable for
experimentation within the Internet, to allow field trials.
Oct 95 Complete an initial field trial of the prototype protocol and
implementation.
Jul 96 After assessing the performance of the protocols and sample
algorithms, based on operational experience, release an updated
protocol specification and sample algorithms.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08043;
15 Aug 94 13:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12005;
15 Aug 94 13:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08020;
15 Aug 94 13:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07912;
15 Aug 94 13:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11928;
15 Aug 94 13:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07900;
15 Aug 94 13:46 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: New Internet Routing and Addressing Architecture (nimrod)
Date: Mon, 15 Aug 94 13:46:51 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151346.aa07900 at IETF.CNRI.Reston.VA.US>
A new working group has been created in the Routing Area of
the IETF. Please contact the chairs or area director for
more information.
IESG Secretary
New Internet Routing and Addressing Architecture (nimrod)
---------------------------------------------------------
Charter
Current status: active working group
Chair(s):
J. Noel Chiappa <jnc at lcs.mit.edu>
Isidro Castineyra <isidro at bbn.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:nimrod-wg at bbn.com
To Subscribe: nimrod-wg-request at bbn.com
Archive: bbn.com:/pub/nimrod-wg/nimrod-wg.archive
Description of Working Group:
The goal of the working group is to design, specify, implement and test a
flexible new routing and addressing architecture suitable for very large
scale internets. The basic architecture for computation of routes will
be based on distribution of network topology maps, with source-specified
route selection, and unitary (i.e., not hop-by-hop) computation of routes.
The architecture will provide a single homogeneous framework for all
routing, including both inter-domain and intra-domain. It will include a
new network component naming abstraction hierarchy, starting from network
attachment points, and based on actual connectivity, but taking into
consideration policy requirements. These new names will be variable
length, with a variable number of levels of abstraction; they will not
appear in most packets, though.
Actual packet forwarding will be based both on retained non-critical
state in the switches (via flow setup for long-lived communications), and
both classical address-only, as well as source-route type instructions, in
individual packets (for datagram applications which send only one, or a very
few, packets).
Although the general design and algorithms will be usable in any
internetworking protocol family, the initial detailed protocol
specifications and implementation are currently planned for deployment
with IPv4, but support for another packet format may be substituted or
added, depending on the situation in the Internet in the future.
Interoperabilty with existing unmodified IPv4 hosts will be achieved by
re-interpreting the existing source and destination fields in IPv4
packets as endpoint identifiers.
A substantial effort to take into account support for mobility,
multicast and resource allocation will be made when designing the Nimrod
architecture; provided that so doing is neither impossible because of
incomplete work outside the scope of Nimrod, nor the cause of very
substantial delays in the first iteration of the protocol design.
Goals and Milestones:
Oct 93 Commence project.
Jan 94 Complete the review and discussion of the fundamentals of the routing
and addressing architecture.
Feb 94 Produce a draft architecture document, which will also serve as an
in-depth introduction to Nimrod.
Jul 94 Issue Internet-Drafts containing the design of the basic routing and
addressing architecture and protocols.
Sep 94 Produce a first version of the protocol specification, which embodies
the completed basic routing and addressing architecture. Issue this
document as an Internet-Draft.
Nov 94 Finish design of all the detailed mechanisms, including sample
algorithms for those parts which are outside the core specification.
Issue an Internet-Draft describing these.
Dec 94 Issue a usage guide as an Internet-Draft. This guide will describe
recommended clustering strategies and configurations.
Jul 95 Finish an initial prototype protocol implementation, suitable for
experimentation within the Internet, to allow field trials.
Oct 95 Complete an initial field trial of the prototype protocol and
implementation.
Jul 96 After assessing the performance of the protocols and sample
algorithms, based on operational experience, release an updated
protocol specification and sample algorithms.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08056;
15 Aug 94 13:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08043;
15 Aug 94 13:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12005;
15 Aug 94 13:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08020;
15 Aug 94 13:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07912;
15 Aug 94 13:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11928;
15 Aug 94 13:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07900;
15 Aug 94 13:46 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: New Internet Routing and Addressing Architecture (nimrod)
Date: Mon, 15 Aug 94 13:46:51 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408151346.aa07900 at IETF.CNRI.Reston.VA.US>
A new working group has been created in the Routing Area of
the IETF. Please contact the chairs or area director for
more information.
IESG Secretary
New Internet Routing and Addressing Architecture (nimrod)
---------------------------------------------------------
Charter
Current status: active working group
Chair(s):
J. Noel Chiappa <jnc at lcs.mit.edu>
Isidro Castineyra <isidro at bbn.com>
Routing Area Director(s):
Joel Halpern <jhalpern at newbridge.com>
Mailing lists:
General Discussion:nimrod-wg at bbn.com
To Subscribe: nimrod-wg-request at bbn.com
Archive: bbn.com:/pub/nimrod-wg/nimrod-wg.archive
Description of Working Group:
The goal of the working group is to design, specify, implement and test a
flexible new routing and addressing architecture suitable for very large
scale internets. The basic architecture for computation of routes will
be based on distribution of network topology maps, with source-specified
route selection, and unitary (i.e., not hop-by-hop) computation of routes.
The architecture will provide a single homogeneous framework for all
routing, including both inter-domain and intra-domain. It will include a
new network component naming abstraction hierarchy, starting from network
attachment points, and based on actual connectivity, but taking into
consideration policy requirements. These new names will be variable
length, with a variable number of levels of abstraction; they will not
appear in most packets, though.
Actual packet forwarding will be based both on retained non-critical
state in the switches (via flow setup for long-lived communications), and
both classical address-only, as well as source-route type instructions, in
individual packets (for datagram applications which send only one, or a very
few, packets).
Although the general design and algorithms will be usable in any
internetworking protocol family, the initial detailed protocol
specifications and implementation are currently planned for deployment
with IPv4, but support for another packet format may be substituted or
added, depending on the situation in the Internet in the future.
Interoperabilty with existing unmodified IPv4 hosts will be achieved by
re-interpreting the existing source and destination fields in IPv4
packets as endpoint identifiers.
A substantial effort to take into account support for mobility,
multicast and resource allocation will be made when designing the Nimrod
architecture; provided that so doing is neither impossible because of
incomplete work outside the scope of Nimrod, nor the cause of very
substantial delays in the first iteration of the protocol design.
Goals and Milestones:
Oct 93 Commence project.
Jan 94 Complete the review and discussion of the fundamentals of the routing
and addressing architecture.
Feb 94 Produce a draft architecture document, which will also serve as an
in-depth introduction to Nimrod.
Jul 94 Issue Internet-Drafts containing the design of the basic routing and
addressing architecture and protocols.
Sep 94 Produce a first version of the protocol specification, which embodies
the completed basic routing and addressing architecture. Issue this
document as an Internet-Draft.
Nov 94 Finish design of all the detailed mechanisms, including sample
algorithms for those parts which are outside the core specification.
Issue an Internet-Draft describing these.
Dec 94 Issue a usage guide as an Internet-Draft. This guide will describe
recommended clustering strategies and configurations.
Jul 95 Finish an initial prototype protocol implementation, suitable for
experimentation within the Internet, to allow field trials.
Oct 95 Complete an initial field trial of the prototype protocol and
implementation.
Jul 96 After assessing the performance of the protocols and sample
algorithms, based on operational experience, release an updated
protocol specification and sample algorithms.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10515;
15 Aug 94 15:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10505;
15 Aug 94 15:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14866;
15 Aug 94 15:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10494;
15 Aug 94 15:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10461;
15 Aug 94 15:49 EDT
Received: from pluto.dss.com by CNRI.Reston.VA.US id aa14821;
15 Aug 94 15:49 EDT
Received: by pluto.dss.com (4.1/SMI-4.0)
id AA02548; Mon, 15 Aug 94 15:45:02 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joachim Martillo <martillo at pluto.dss.com>
Message-Id: <9408151945.AA02548 at pluto.dss.com>
Subject: Re: IPng recommendation
To: kasten at ftp.com
Date: Mon, 15 Aug 1994 15:45:00 -0400 (EDT)
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
In-Reply-To: <9408031415.AA02333 at mailserv-D.ftp.com> from "Frank Kastenholz" at Aug 3, 94 10:15:56 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 32502
>Date: Wed, 3 Aug 94 10:15:56 EDT
>Subject: Re: IPng recommendation
>From: kasten at ftp.com (Frank Kastenholz)
>Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
>Joachim,
>First of all, comments would have been preferred during the debate.
>Certainly before the IPng choice. Comments now are roughly akin to
>locking the barn door after the horse has run off, though since there
>is still IPNG development work to be done, I am sure that the IPng
>developers will carefully consider your points.
For some reason, people who regularly take part in developing IETF
standards have a major misconception about standards development in
the context of manufacturing regimes. I recently made this point as
follows on the SNMP mailing list.
International regimes, national regimes and manufacturing regimes
produce standards. The ISO is an international regime. The Deutsche
Bundespost is a national regime. IBM with respect to SNA or Microsoft
with respect to Windows are examples of manufacturing regimes.
Another example of a manufacturing regime is the voluntary regime
among screw manufacturers governing helicity, pitch and groove width of
screws.
The IETF is a manufacturing regime like the screw regime. The goal of
the IETF should be to produce a set of standards so that purchasers of
TCP/IP based products can feel assured that TCP/IP devices can
effectively operate and interoperate in the environment of a
multiprotocol internet.
The raison d'etre of such a manufacturing regime is products not
standards. Developers of IETF standards must understand that product
developers and product customers pass ultimate judgment on IETF
standards. The real criticism begins once the IETF produces an
official RFC (which in fact does stand fo Request for Comments).
Ultimately the market will judge some IETF standards stupid just as
the market and Ken Olson ultimately judged token bus stupid. If IETF
contributors are going to freak every time people outside the
standards process have problems with an IETF standard, ultimately the
IETF may prove to have no value.
>Second, one of the 'principles' which Craig and I started using in
>refining the criteria was what has been called 'In your face'
>requirements. If the criteria were set at a relatively 'safe' or
>'low' level, then that is all we might get. You mention, for example,
>10**15 end nodes. If we had set, for example, 10**10 end nodes, then
>that is possibly all we would get. By setting a higher level, we may
>still get only 10**10, but we might also get more. Furthermore, by
>saying 10**15, the developers (and the rest of the community) may
>think more about what a truly ubiquious global internetwork might
>need and what it could do.
The use of a so-called "in your face argument" implies an inability to
present a rational argument in favor of some position to a reasonable
target audience persuasively. Certainly, using an "in your face
argument" is unprofessional and suggests some major deficiencies in
either the presenter or the position presented.
In this case, the real problem seems to be the end-address allocation.
Rather than making a requirement of order(250,000) addresses per human
a better requirement might have been that IPng provide a reasonable
end-address allocation scheme.
> > After noticing some of the discussion of IPng criteria, I ftp'd over
> > the criteria. Exactly how to interpret this document is unclear.
>This document, in its final form, was considered as a framework (not
>the only one) about which discussions of the various IPNG candidates
>could be held by the IPng directorate. You might, in effect, consider
>the section headings to be an 'agenda' of items to be evaluated in
>the various proposals.
Perhaps, if Kastenholz would learn how to write a serious technical
document, treating this document as an agenda would have been
possible. Unfortunately, as one can see from the table of contents
following, not only do the section headers contribute to a major lack
of seriousness and professionalism, but there is also little clue in
the section headers of the document in question to hint at the nature
of the document.
Table of Contents
Status of this Memo .................................... 1
1 Introduction .......................................... 2
2 Goals ................................................. 3
3 Note on Terminology ................................... 5
4 General Principles .................................... 6
4.1 Architectural Simplicity ............................ 6
4.2 One Protocol to Bind Them All ....................... 6
4.3 Live Long ........................................... 6
4.4 Live Long AND Prosper ............................... 7
4.5 Co-operative Anarchy ................................ 7
5 Criteria .............................................. 9
5.1 Scale ............................................... 9
5.2 Topological Flexibility ............................. 11
5.3 Performance ......................................... 12
5.4 Robust Service ...................................... 14
5.5 Transition .......................................... 15
5.6 Media Independence .................................. 17
5.7 Unreliable Datagram Service ......................... 19
5.8 Configuration, Administration, and Operation ........ 20
5.9 Secure Operation .................................... 22
5.10 Unique Naming ...................................... 24
5.11 Access ............................................. 25
5.12 Multicast .......................................... 26
5.13 Extensibility ...................................... 27
5.14 Network Service .................................... 29
5.15 Support for Mobility ............................... 30
5.16 Control Protocol ................................... 31
5.17 Private Networks ................................... 32
5.18 Things We Chose Not to Require ..................... 33
6 Routing ............................................... 35
6.1 Scale ............................................... 35
6.2 Policy .............................................. 35
6.3 QOS ................................................. 36
6.4 Feedback ............................................ 36
6.5 Stability ........................................... 36
6.6 Multicast ........................................... 36
7 Security Considerations ............................... 38
8 Acknowledgments ....................................... 39
9 References ............................................ 40
10 Change Log ........................................... 42
10.1 25 May 1994 ........................................ 42
10.2 10 May 1994 ........................................ 42
10.3 25 April 1994 ...................................... 42
10.4 23 March 1994 ...................................... 43
10.5 21 March 1994 ...................................... 43
10.6 10 March 1994 ...................................... 45
10.7 9 March 1994 ....................................... 45
10.8 15 February 1994 ................................... 46
10.9 9 November 1993 .................................... 47
10.10 9 September 1993 .................................. 48
10.11 14 December 1992 .................................. 48
By way of contrast, the following are section headers from a document
I wrote to propose a reasonable architecture for hybrid bridge routers
(available via anonymous ftp from pluto.dss.com in the Constellation
directory). It may not be a great document, but the section headers
do hint that the subject of the document is the architecture of hybrid
bridge routers.
I. Introduction 1
II. IP Routers 5
III. P802.1d MAC Bridges 11
IV. Contrasting Bridges and Routers 21
V. Disjoint Functionality Hybrid Bridge Routers 31
VI. Parallel Router Filtering Bridge Architecture for Hybrid Bridge
Routers 31
VII. Logical Subbridge Architecture for Hybrid Bridge Routers 35
VIII. Conclusion 39
Terminology 41
> > >5.3. Performance
> > >Furthermore, at a minimum, a
> > >host must be able to achieve data transfer rates with
> > >IPng comparable to the rates achieved with IPv4, using
> > >similar levels of host resources.
> > Since poor router performance can affect a whole internet rather than
> > simply an individual host, the criterion should have concentrated
> > attention on router performance.
>It originally did. However, it was also pointed out that if IPng made
>host performance 'very bad' then, even if the routers were blindingly
>fast, IPng would be a loser. Furthermore, IPng really should not be
>perceived as a step backwards wrt IPv4. If IPng made hosts
>significantly slower then it would be just such a step.
>Now, this might all seem trivial, obvious, irrelevant, and
>motherhood. But, on the other hand, host performance was a major
>factor in the discussion about addressing on the big-i list. If host
>performance wasn't critical then that discussion may well have had a
>different outcome.
I remember having this argument at Prime (where people used to argue
that it was reasonable to get undefined or erroneous results when,
because or even though the arguments to a function and its formal
parameter definitions were consistent and within range).
In IP-type internetworking, N-interface hosts and N-interface routers
are distinguishable in that N-interface end hosts do not forward
packets. (The single interface host is of course a degenerate case of
an N-interface host.)
One would think it would be really hard to design an IP-like
internetworking system wherein routers were blindingly fast while end
hosts performed very badly even though hosts differed from routers
only by not doing something that routers did.
> > >We limit this requirement to commercially available
> > >routers and media. If some network site can obtain a
> > >particular media technology "off the shelf", then it
> > >should also be able to obtain the needed routing
> > >technology "off the shelf." One can always go into some
> > >laboratory or research center and find newer, faster,
> > >technologies for network media and for routing. We do
> > >believe, however, that IPng should be routable at a speed
> > >sufficient to fully utilize the fastest available media,
> > >though that might require specially built, custom,
> > >devices.
> > This comment suggests that the new address structure should enable the
> > quickest possible route look-up. The quickest possible route look-up
> > means that a network number should conveniently correspond to a
> > natural register size on common communications computers and that
> > accesses to slower processor external memory should be minimized.
> > Such needs and 16 byte addresses are hard to reconcile with current
> > router technology.
>First, we attempted to stay as far away from dictating implementation
>as we could.
This assertion is an IETF situational justification. Suddenly, there
is an IETF principle which rejects dictating implementation. Then how
is the OSPF protocol "specification" justified? That novel of a
document cannot be considered in any way, shape or form a reasonable
protocol specification. It is nothing but one possible (but certainly
not obviously the best) implementation specification,
> Your comment implies that we should have said, for
>example, that addresses must have a 4-byte (or whatever number)
>network number field. This would be dangerously close to specifying
>the implementation, and not pointing out the problems that were to be
>solved. (By pointing out the problem, we in theory allowed for a wide
>variety of solutions.)
Claiming that somehow specifying a 4-byte network number field
specifies the implementation is a complete non-sequitur. Such a
specification of the network number field would say nothing about how
the network number was structured. In fact, such a network number
field could be split into an area and a non-area portion or some other
hierarchical scheme.
A similar specification of the host ID field would also say nothing
about how the host ID field was structured. In fact, such a host ID
field could be split into some sort of subnet field and subnet host ID
field or some other structured scheme.
>Second, some people are envisioning that a majority of traffic in the
>future internet will be forwarded not based on topological
>information carried around in the packet, but rather on a smaller,
>more easily handled, 'flow-id' which would have the properties you
>talk about. I note that SIPP has such a flowid.
This comment sounds like an admission that SIPP addressing is
completely broken with respect to performance and as a consequence
another level of complexity and possible errors must be added to
compensate for the damage which SIPP addressing does. Thus there may
be no way to tell from the address how a given packet might be routed
because the "flow id" will determine the routing. In any case, such a
field makes the non-data header portion even larger (a major concern
on low bandwidth channels), and provides even more bits in the header
not protected against errors by checksum.
> > >We also observe that many researchers believe that a
> > >proper IPng router should be capable of routing IPng
> > >traffic over links at speeds that are capable of fully
> > >utilizing an ATM switch on the link.
This requirement is uncorrellated. Maybe some sort of
price-performance is being required.
> > ATM is yet another fad technology whose fad may be approaching its
> > end...A better targer might be wire-speed routing in the context of a LAN
> > switch using fast Ethernet or CDDI.
>The base criterion does not mention any specific technology. We felt
>that we could not accurately predict what technology would be the
>'right' technology in 5 or 10 years.
There was no reason to care. The whole point of the internetwork
layer is the creation of a virtual network which hides the details of
specific technologies.
> > >Some predictions have been made that, as the Internet
> > >grows and as more and more technically less-sophisticated
> > >sites get connected, there will be more failures in the
> > >network. These failures may be a combination of simple
> > >size; if the size of the network goes up by a factor of n
> > >then the total number of failures in the network can be
> > >expected to increase by some function of n. Also, as the
> > >network's users become less sophisticated, it can be
> > >assumed that they will make more, innocent and well
> > >meaning, mistakes, either in configuration or use of
> > >their systems.
This failure estimate model is not reasonable.
>Also, we are envisioning a future where the entities who connect to
>the Internet will not be like they are today. They will be sites that
>are non-technical (in the networking sense) and probably will not
>have the system operations staff that current sites have. Imagine a
>dentist's office connecting to the network. This is also the reason
>why we are stressing a 'plug-and-play' configuration ability. The
>less that has to be configured, the less chance of making such errors.
Such sites will probably deal with their internetworking service needs
the same way they deal with their telephone service needs. Just as
they have a small PBX, they might have an internet interconnection
device. When the PBX doesn't work, they call the supplier. If the
internet interconnection device doesn't work, they would call the
supplier.
In any case, the section of the requirements document which dealt with
"plug-and-play" was completely confused. My Appletalk and IPX hosts
are plug-and-play, but they do not boot over the network. Network
boot and plug-and-play are completely orthogonal.
> > >5.12. Multicast
> > The above comment is idiotic. Exactly how a network layer multicast
> > is resolved to a MAC layer address for some arbitrary medium is not
> > obviously part of the network layer design.
>It says 'When mac-layer multicasting is available, use it in preference
>to broadcasts.'
This requirement is not relevant to the specification of IPng. How an
IPng packet is to be transported across a given medium is part of a
medium specific IPng encapsulation specification and not part of the
IPng protocol specification.
A sensible encapsulation specification would specify network layer
multicasts be transported with whatever MAC addresses make the most
sense. It is not to hard to envision a medium where mac-layer
multicasting might be present but where mac-layer broadcast might make
more sense as an encapsulation (e.g. a switched medium where
multicasts were limited to some small number of hosts -- perhaps 16 --
while broadcasts would reach all hosts within the communcations subnet
on a dedicated out of band channel).
> > Furthermore, as Appletalk
> > has abundantly shown a protocol that uses multicast exclusively can
> > certainly be antisocial in the sense of burning up a lot of bandwidth.
>This criterion does not say that one should use multicasts instead of
>unicasts. There are certain types of applications (eg multi-person
>conferencing, finding servers) where using unicasts is not the best
>way to go. If the existance of these applications is a given, then we
>have a choice of using MAC-level multicasts or broadcasts (where
>mcasts are available). We believe that multicasts are preferred in
>these situations.
You misunderstood my comment. Appletalk uses multicasts exclusively
in situations where IP would use broadcasts.
> > >6. Routing
> > >Routing is a very critical part of the Internet. In fact, the
> > >Internet Engineering Task Force has a separate Area which is
> > >chartered to deal only with routing issues. This Area is
> > >separate from the more general Internet Area.
> > >We see that routing is also a critical component of IPng.
> > >There are several criteria, such as Scaling, Addressing, and
> > >Network Services, which are intimately entwined with routing.
> > Shouldn't routing performance be included among these critical
> > components?
>What exactly is routing performance?
I have lead teams working on compilers, word processors, spreadsheets
and switches. Every once in a while I would review an engineer's work
and point out that a given approach would lead to unacceptably low
performance.
If the engineer then tried to suggest that there were conceptual
problems with defining performance for the target application, I had a
serious problem because the engineer was trying to rationalize away a
complete lack of understanding with respect to the technology,
performance issues or software engineering in general.
Someone who had a modicum of understanding might have consulted one of
the standard textbooks like Computer Architecture: A Quantitative
Approach or Computer Organization & Design: The Hardware/Sortware
Interface (both by Patterson & Hennessy) and tried to determine how
some of the general principles outlined there might apply to the
problem at hand.
> There are at least three
>separate functions that are commonly subsumed under the term
>'routing' and the performance could apply to any of the three.
In this case we might ask what activity is most critical to the vast
majority of users of the network.
Does he care about the distribution of routing information? In a well
functioning network, the network converges to a stable topology and
nothing should change very often.
Does he care about the calculation of routes by routers which really
should in a well functioning network come to the same result iteration
after iteration?
No, but after the speed with which packets are received or transmitted
at the local interface, he would care about how quickly packets are
switched in the routers from the incoming to the outgoing interfaces
(unless he is exceptionally patient). The ratio of data to control
information would probably concern him (especially on low bandwidth
channels).
> We
>believe that we have performance of Forwarding packets well covered.
There is no basis for this belief. With the size of addresses and
cruft like the flow ID, IPng will be a disaster on low to moderate
speed channels.
In environments where successive packets transmitted between two end
hosts are likely to follow different equal cost routes described by
possibly very different values of parameters like MTU. MTU might
continuously have to be rediscovered and many packet transmissions
will fail because MTU on an intermediate network was exceeded.
In such a network, best network performance might have been achieved
with a packet size somewhat less than the MTU on most possible paths
but which might lead to fragmentation on other paths (were
fragmentation supported).
Single frame acknowledged protocols (of which I believe Sun NFS is an
example) may suffer major performance losses because of choices made
with respect to IPng. On ethernet and other LAN networks, the
performance of a single frame acknowledged protocol could be enhanced
(with IPv4) by purposefully setting packet size larger than the medium
specific MTU. In this way several full size IP packets can be
transmitted before an acknowledgement is required.
The IPng requirements for no legitimate reason discarded this useful
capability which might in some cases provide significant performance
enhancements. Such a decision is not only bad engineering, but is
pure obnoxiousness and verges on a rape of customers who over the
years have come to depend on the existence of a feature discarded by
unjustified fiat.
>The other functions, information distribution (i.e. the routing
>protocols) and route calculation are harder to specify. Should we say
>that the 'Routing Protocols should be efficient' and 'Route
>calculation should be fast'? This seems too nebulous.
>Frank Kastenholz
>To: Joachim Martillo <martillo at dss.com>
>Cc: big-internet at munnari.oz.au, ietf at cnri.reston.va.us
>Subject: Re: IPng recommendation
>From: Craig Partridge <craig at aland.bbn.com>
>Date: Thu, 04 Aug 94 10:17:06 -0700
>Hi:
> Let me see if I can reply to some of your concerns about the IPng
>criteria document. (I'll skip spots where you agreed with it and some spots
>where I wasn't sure of what the key point was).
> First off, the concern on 10**15 end-hosts. We're quite clear
>about why we said that. We derived it straight from other work which we
>felt wasn't quite demanding enough in terms of the number of devices in the
>home. The fact that it comes out to 250,000 addresses per human only reflects
>some of the Internet's difficulties with efficient address allocation.
Then IPng requirements should have required that this difficulty be
addressed.
>> This comment suggests that the new address structure should enable the
>> quickest possible route look-up. The quickest possible route look-up
>> means that a network number should conveniently correspond to a
>> natural register size on common communications computers and that
>> accesses to slower processor external memory should be minimized.
>> Such needs and 16 byte addresses are hard to reconcile with current
>> router technology.
>Um, no, I'm afraid I don't agree with this analysis. I think a better
>answer is to say that the header size should be a small number of cache
>lines in size (the unit of access is no longer a register size). With
>128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two
>cache lines. Furthermore, most RISC systems have so many registers that
>putting the entire header into registers isn't hard -- and the address
>lookup in 90% of the cases is just a hash followed by a couple of compares.
Caches can help with the route table, and a lot of registers can help
with address comparisons. But caches do not help in groveling through
the header of a received packet, and header information must still be
exchanged between registers and slow processor external memory. The
longer the header is, the more time will be expended in this transfer
for a given hardware implementation.
At Prime the networking stars always wanted to argue that future
hardware would compensate for the lousy performance of networking
software, but in the IP internet context we have to worry about a
massive performance loss on the massive installed base of hardware
because of design decisions made in (somewhat misguided) anticipation
of the performance capabilites of future hardware.
>> BTW, after groveling through numerous packet switching implementations
>> and network drivers, almost invariably I have found that bottlenecks
>> and low performance have been due not to protocol design but poor
>> software implementations or (often even more importantly) due to the
>> host OS architecture. The protocol design has generally been an
>> extremely minor component of network/packet-switching performance.
>Yep. But there are folks working on making very very fast implementations
>and they are getting burned by protocol design issues.
I would have to analyze the implementations. An argument that a
protocol must be designed in a specific way because some researcher in
some unique environment had some sort of problem is not is not an
argument but simply an unjustified assertion.
Tony Bono, Director of Bridge Router Development at Penril Datability
Networks, came across such bogus justification with respect to task
exchange time for the OS of a packet switch. Supposedly the task
exchange had to meet some requirements which he did not have security
clearance to read. Once he got clearance, he found that there was no
such requirements and that the other engineer simply had been unable
to justify his position rationally.
>> >5.5. Transition
>> >The transition plan should address the issue of cost
>> >distribution. That is, it should identify what tasks are
>> >required of the service providers, of the end users, of
>> >the backbones and so on.
>> This comment is rather scary. The IETF collectively has no obvious
>> expertise in public finance, accounting or political economics.
>>
>> The one area where the IETF has tried to distribute costs is network
>> management, and in this case the IETF has managed to make small
>> installations subsidize the development of SNMP on behalf of a few
>> large network providers even though the small installations have no
>> real need of such a thing.
>I dunno. We've got a lot of folks who've led successful startups etc.
>Or putting this another way, if the idea is that folks who are in the IETF
>cannot at least try to address issues of finance, accounting or economics,
>why should we believe they are qualified to run businesses?
Scoring in the high tech industry often has little to do with business
qualifications. In any case, costing is a bean-counter issue. Rarely
do bean-counters become successful entrepreneurs, and few successful
entrepreneurs have started out as bean-counters. In any case, hi-tech
engineers seem particularly bad at costing, and are probably the last
ones who should be addressing such an issue.
>At some level, one just has to look at some of these problems -- so we will.
But mention of these problems is really irrelevant to the IPng
requirements specification.
>> >IP Header Checksum
>> >There has been discussion indicating that the IP Checksum
>> >does not provide enough error protection to warrant its
>> >performance impact. The argument states that there is
>> >almost always a stronger datalink level CRC, and that
>> >end-to-end protection is provided by the TCP checksum.
>> >Therefore we believe that an IPng checksum is not
>> >required per-se.
>> The IP header checksum is not intended to provide end-to-end data
>> integrity but rather provides local address integrity. Few routers
>> provide EDAC. Stuck bits in the wrong place after receive datalink
>> CRC is calculated could easily cause some poor neighboring router to
>> be inundated with misdirected packets whose lack of data integrity
>> might not be detected until much later or even never (if the new
>> address corresponds to no actual address). This problem could be
>> particularly serious in the cases of applications which rarely or
>> infrequently require acknowledgement of transmitted data packets.
>Read the paragraph again. It says that local address integrity is sufficiently
>protected by the link CRC and that end-to-end integrity of the IP datagram
>is ensured by the end-to-end TCP checksums. Simple engineering.
You need to learn more about hardware. It is simply cheaper to design
packet switch memories and hardware I/O FIFOs without error detection
or without error detection and correction.
I have grovelled through the hardware designs of 5 different
internetwork packet switches. None would guarantee local address
integrity as you seem to expect.
If anyone reading this note knows of a packet switch with the sort of
error detection circuitry which Partridge seems to assume, I would be
interested to learn about it.
>Craig
>From: Dave Katz <dkatz at cisco.com>
>Subject: IPng recommendation
>Sorry, I thought you were caught by the "can't forward to another box
>on the wire without a router" red herring.
>Address autoconfiguration has been defined at the ISO level only as a
>server-based process. However, there is nothing to explicitly bar
>other approaches. At least one ES vendor has implemented a scheme that
>falls back to being completely serverless on isolated LANs (trivial,
>since there's a "local scope" address format defined). This obviously
>can be done without being in violation of any spec (since from the outside
>you can't tell that it wasn't just statically defined).
This scheme makes a lot of sense if once the isolated LAN is connected
to an internet, the local scope addresses are supplanted by global
scope addresses.
>There is also an internet draft (draft-ietf-tuba-addr-assign-00.txt) that
>attempts to formalize the spectrum of possibilities into a single mechanism.
>So, yes, I think you've been burned by bad info again, in that there
>is no requirement per se to have a router present.
> From: Craig Partridge <craig at aland.bbn.com>
> Date: Thu, 04 Aug 94 10:56:12 -0700
> Sender: craig at aland.bbn.com
> Dave:
> You mean I've been burned by bad info again?
> My understanding was that if one wanted to do certain types of dynamic
> address assignment under OSI one had to have a router present because dynamic
> assignment required ES-IS and ES-IS required a router to be present. Is this
> incorrect?
> Craig
An important part of developing requirements for IPng should have been
learning how other protocol suites dealt with relevant issues.
Analysis and comparison could have provided insights and helped avoid
pitfalls.
IPX and Appletalk are in many ways superior to classic IP. DECNET has
been transitioned several times to newer versions that offered more
capabilities. SNA has generally provided particularly high
performance communications between end hosts.
IPng would look a lot less problematic if the WG had approached the
task of developing requirements for IPng far more systematically.
IPng would look far less parochial and far less prone to recapitulate
errors already made and fixed in other contexts, had the WG made more
extensive use of internetworking knowledge developed outside the arena
of TCP/IP.
Joachim Martillo
Manager of Internetworking Research
Penril Datability Networks
Penril Datability Advanced Communications Research Center
190 N. Main St.
Natick, MA 01760
VOICE 508-653-5313
FAX 508-653-6415
EMAIL martillo at dss.com
martillo at penril.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11040;
15 Aug 94 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11030;
15 Aug 94 16:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15453;
15 Aug 94 16:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11005;
15 Aug 94 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10941;
15 Aug 94 16:17 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa15395; 15 Aug 94 16:17 EDT
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA06782 for ietf at cnri.reston.va.us; Mon, 15 Aug 94 16:17:39 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id NAA02462; Mon, 15 Aug 1994 13:16:56 -0700
Message-Id: <199408152016.NAA02462 at aland.bbn.com>
To: Joachim Martillo <martillo at pluto.dss.com>
Cc: kasten at ftp.com, big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of Mon, 15 Aug 94 15:45:00 -0400.
<9408151945.AA02548 at pluto.dss.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Mon, 15 Aug 94 13:16:55 -0700
X-Orig-Sender: craig at aland.bbn.com
Joachim:
OK -- I'll do one last round here.
Then IPng requirements should have required that this difficulty be
addressed.
We could have also specified that it would be nice to have hardware that
delivered 1 Gbps bandwidth and cost $100 per adapter. Cray, SGI, and some
other vendors could clearly use this capability now and it would make the
Mosaic load on the network lower. But specifying it doesn't make it happen.
One specs what appears feasible.
>> This comment suggests that the new address structure should enable th
e
>> quickest possible route look-up. The quickest possible route look-up
>> means that a network number should conveniently correspond to a
>> natural register size on common communications computers and that
>> accesses to slower processor external memory should be minimized.
>> Such needs and 16 byte addresses are hard to reconcile with current
>> router technology.
>Um, no, I'm afraid I don't agree with this analysis. I think a better
>answer is to say that the header size should be a small number of cache
>lines in size (the unit of access is no longer a register size). With
>128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two
>cache lines. Furthermore, most RISC systems have so many registers that
>putting the entire header into registers isn't hard -- and the address
>lookup in 90% of the cases is just a hash followed by a couple of compares
.
Caches can help with the route table, and a lot of registers can help
with address comparisons. But caches do not help in groveling through
the header of a received packet, and header information must still be
exchanged between registers and slow processor external memory. The
longer the header is, the more time will be expended in this transfer
for a given hardware implementation.
You're changing the argument here. The original statement said there was
a need to optimize route lookup and I said that the statement was ill-formed
and now you're making a pure header sizes mean slow argument (and saying
well routing doesn't matter after all).
>Yep. But there are folks working on making very very fast implementations
>and they are getting burned by protocol design issues.
I would have to analyze the implementations. An argument that a
protocol must be designed in a specific way because some researcher in
some unique environment had some sort of problem is not is not an
argument but simply an unjustified assertion.
Go look at Van Jacobson's fast IP forwarding code (sent to the end2end-interest
list about 3 years ago as I recall).
You need to learn more about hardware. It is simply cheaper to design
packet switch memories and hardware I/O FIFOs without error detection
or without error detection and correction.
OK -- summarizing your argument, after the link CRC is computing there's
a chance the router will trash the 20 byte IP header while moving it over
data lines from the interface to the forwarding engine and that this risk
is so great we need a checksum in each packet. Right? Sounds silly to me.
I know of boxes that infrequently trash packets, but they usually sufficiently
trash them (and do so randomly enough) that the checksum isn't worthwhile.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14425;
15 Aug 94 19:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14414;
15 Aug 94 19:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19861;
15 Aug 94 19:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14389;
15 Aug 94 19:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14329;
15 Aug 94 19:19 EDT
Received: from halloran-eldar.lcs.mit.edu by CNRI.Reston.VA.US id aa19804;
15 Aug 94 19:19 EDT
Received: by halloran-eldar.lcs.mit.edu; id AA20631; Mon, 15 Aug 1994 19:19:30 -0400
Date: Mon, 15 Aug 1994 19:19:30 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Garrett Wollman <wollman at halloran-eldar.lcs.mit.edu>
Message-Id: <9408152319.AA20631 at halloran-eldar.lcs.mit.edu>
To: Joachim Martillo <martillo at pluto.dss.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: <9408151945.AA02548 at pluto.dss.com>
References: <9408031415.AA02333 at mailserv-D.ftp.com>
<9408151945.AA02548 at pluto.dss.com>
[Deleting unnecessary CCs]
<<On Mon, 15 Aug 1994 15:45:00 -0400 (EDT), martillo at pluto.dss.com (Joachim Martillo) said:
> The IETF is a manufacturing regime like the screw regime.
You are confusing the IETF was a standards organization. It is not,
although a lot of people (obviously you included) would like to make
it into one and thereby drive all the useful work elsewhere.
> The use of a so-called "in your face argument" implies an inability to
> present a rational argument in favor of some position to a reasonable
> target audience persuasively. Certainly, using an "in your face
> argument" is unprofessional and suggests some major deficiencies in
> either the presenter or the position presented.
I don't think you are the person to be lecturing Craig Partridge and
Frank Kastenholz as ``unprofessional''. The particular technique in
question was and is quite necessary when a particular part of the
target audience REFUSES to be persuaded by rational arguments of any
kind.
> In this case, the real problem seems to be the end-address allocation.
> Rather than making a requirement of order(250,000) addresses per human
> a better requirement might have been that IPng provide a reasonable
> end-address allocation scheme.
Which is absolutely useless as a requirement for anything, since one
of the fundamental points of disagreement among the various contenders
was what constitutes a ``reasonable'' address allocation scheme, or
indeed whether such a thing could even be said to ever exist.
> Perhaps, if Kastenholz would learn how to write a serious technical
> document, treating this document as an agenda would have been
> possible.
``WAAAAH! WAAAA! I don't have a sense of humor, so I might as well
whine about the fact that everybody else does.'' Get a life!
(Unfortunately, I haven't got a citation handy for my /ConneXions/
article about how the Internet community has a long-standing tradition
of using humor as a tool in public discourse.)
> This assertion is an IETF situational justification. Suddenly, there
> is an IETF principle which rejects dictating implementation. Then how
> is the OSPF protocol "specification" justified?
If you don't like the OSPF documents, then go complain to their
authors. In the appropriate forum, of course (hint: this ain't it).
>> The base criterion does not mention any specific technology. We felt
>> that we could not accurately predict what technology would be the
>> 'right' technology in 5 or 10 years.
> There was no reason to care. The whole point of the internetwork
> layer is the creation of a virtual network which hides the details of
> specific technologies.
Um, sorry, but what planet are you living on? If you design an
internetwork layer that is unusually poorly suited for what turns out
to be a common link layer technology, then you have just written
yourself into a dead end.
> You misunderstood my comment. Appletalk uses multicasts exclusively
> in situations where IP would use broadcasts.
IP doesn't chatter anywhere near as much as Appletalk. Your original
statement was completely irrelevant.
> I have lead teams working on compilers, word processors, spreadsheets
> and switches.
I bow down before your awesome power and experience.
> If the engineer then tried to suggest that there were conceptual
> problems with defining performance for the target application, I had a
> serious problem because the engineer was trying to rationalize away a
> complete lack of understanding with respect to the technology,
> performance issues or software engineering in general.
Well, since nobody else has yet determined a satisfactory way to
define routing performance in the Internet, who don't you use your
vast experience to develop a model that is satisfactory, and provide
it to the Internet community for public review?
[200 more lines of point-counterpoint deleted in the interest of time
and size.]
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman at lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25030;
16 Aug 94 2:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25020;
16 Aug 94 2:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26575;
16 Aug 94 2:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25005;
16 Aug 94 2:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24964;
16 Aug 94 2:33 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa26523;
16 Aug 94 2:33 EDT
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id OAA00620; Mon, 15 Aug 1994 14:18:09 -0700
Message-Id: <aa758a930d02102406ad at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 15 Aug 1994 14:18:13 -0700
To: Joachim Martillo <martillo at pluto.dss.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng recommendation
Cc: kasten at ftp.com, martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
Joachim,
As always, your contributions assisting the IETF to understand its
continued pattern of failure, as well as your subtle touch with personal
exchanges, is I am sure appreciated by the breadth and depth of the
Internet community. We shall, of course, endeavor to learn from the errors
you so consistently point out.
Can't imagine how we've managed to fail so completely, all these years.
d/
P.S. No need to thank me. I'm sure I can intuit your own appreciation of
my response.
-----
Dave Crocker <dcrocker at mordor.stanford.edu>
675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205
Sunnyvale, CA 94086 (USA)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25110;
16 Aug 94 2:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25100;
16 Aug 94 2:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26706;
16 Aug 94 2:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25091;
16 Aug 94 2:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25069;
16 Aug 94 2:45 EDT
Received: from bridge2.NSD.3Com.COM by CNRI.Reston.VA.US id aa26696;
16 Aug 94 2:45 EDT
Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA25496
(5.65c/IDA-1.4.4nsd for <ietf at CNRI.Reston.VA.US>); Mon, 15 Aug 1994 23:45:36 -0700
Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA18864
(5.65c/IDA-1.4.4-910725); Mon, 15 Aug 1994 23:45:33 -0700
Message-Id: <199408160645.AA18864 at remmel.NSD.3Com.COM>
To: Joachim Martillo <martillo at pluto.dss.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of "Mon, 15 Aug 94 15:45:00 EDT."
<9408151945.AA02548 at pluto.dss.com>
Date: Mon, 15 Aug 94 23:45:25 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: tracym at nsd.3com.com
Joachim,
> >First of all, comments would have been preferred during the debate.
> >Certainly before the IPng choice. Comments now are roughly akin to
> >locking the barn door after the horse has run off, though since there
> >is still IPNG development work to be done, I am sure that the IPng
> >developers will carefully consider your points.
>
> For some reason, people who regularly take part in developing IETF
> standards have a major misconception about standards development in
> the context of manufacturing regimes. I recently made this point as
> follows on the SNMP mailing list.
No. It is you who aren't willing to accept, or participate in, the
IETF process. Your message has a valid statement of the goal of a
manufacturing standard, but the "regime" stuff, while perhaps correct
in some pedagogical sense, is presented to justify your own, less than
cooperative, approach to participation.
> The raison d'etre of such a manufacturing regime is products not
> standards. Developers of IETF standards must understand that product
> developers and product customers pass ultimate judgment on IETF
> standards. The real criticism begins once the IETF produces an
> official RFC (which in fact does stand fo Request for Comments).
There is no RFC yet. So why are you choosing now to simply
resurrect arguments discussed any number of times over the past year?
You are well aware of the IETF process, and know that Frank's
complaint with the timing of your message is appropriate.
The SIPP-16 framework within which the new IPng protocol is now being
defined was derived from discussions which have been going on for over
a year. NOT EVEN ONE of your technical complaints is new within the
context of those discussions. Only your personal harangues concerning
the technical competency of the IETF itself are new to the IPng
discussion (though a common theme in your complaints about IETF work).
The IETF's process includes both implementation and criticism before a
standard gets beyond experimental stage. If it is the case that the
majority of implementors cannot produce implementations that run
(almost) as fast as their ipv4 counterparts, or those implementations
fail to interoperate, or are unreliable, or difficult to use, then
ipv6 will may need to be redesigned, and you (and others with similar
concerns) will be proven correct.
However, many people with much experience have been debating the pros
and cons for a long time, and we've reached the put-up or (please)
shut-up stage of the process, where bits get nailed down and code gets
written and tested. Your complaints will be duly stored in the
mailing list archives, but answering them only serves to steal time
from the actual development process of BOTH code and RFC's (upon which
comments, especially those concerned with implementation and
usability, would be appropriate).
Please, won't you participate up front in the future, rather than
waiting until most of the rest of us have, for the time being,
finished arguing?
Tracy Mallory
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25162;
16 Aug 94 2:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25158;
16 Aug 94 2:52 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa26795;
16 Aug 94 2:52 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id IAA24804; Tue, 16 Aug 1994 08:19:44 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id IAA24776; Tue, 16 Aug 1994 08:05:50 +1000
Precedence: list
Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA19800; Tue, 16 Aug 1994 06:17:54 +1000 (from craig at aland.bbn.com)
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA06782 for big-internet at munnari.oz.au; Mon, 15 Aug 94 16:17:39 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id NAA02462; Mon, 15 Aug 1994 13:16:56 -0700
Message-Id: <199408152016.NAA02462 at aland.bbn.com>
To: Joachim Martillo <martillo at pluto.dss.com>
Cc: kasten at ftp.com, big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
Subject: Re: IPng recommendation
In-Reply-To: Your message of Mon, 15 Aug 94 15:45:00 -0400.
<9408151945.AA02548 at pluto.dss.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Mon, 15 Aug 94 13:16:55 -0700
X-Orig-Sender: craig at aland.bbn.com
Joachim:
OK -- I'll do one last round here.
Then IPng requirements should have required that this difficulty be
addressed.
We could have also specified that it would be nice to have hardware that
delivered 1 Gbps bandwidth and cost $100 per adapter. Cray, SGI, and some
other vendors could clearly use this capability now and it would make the
Mosaic load on the network lower. But specifying it doesn't make it happen.
One specs what appears feasible.
>> This comment suggests that the new address structure should enable th
e
>> quickest possible route look-up. The quickest possible route look-up
>> means that a network number should conveniently correspond to a
>> natural register size on common communications computers and that
>> accesses to slower processor external memory should be minimized.
>> Such needs and 16 byte addresses are hard to reconcile with current
>> router technology.
>Um, no, I'm afraid I don't agree with this analysis. I think a better
>answer is to say that the header size should be a small number of cache
>lines in size (the unit of access is no longer a register size). With
>128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two
>cache lines. Furthermore, most RISC systems have so many registers that
>putting the entire header into registers isn't hard -- and the address
>lookup in 90% of the cases is just a hash followed by a couple of compares
.
Caches can help with the route table, and a lot of registers can help
with address comparisons. But caches do not help in groveling through
the header of a received packet, and header information must still be
exchanged between registers and slow processor external memory. The
longer the header is, the more time will be expended in this transfer
for a given hardware implementation.
You're changing the argument here. The original statement said there was
a need to optimize route lookup and I said that the statement was ill-formed
and now you're making a pure header sizes mean slow argument (and saying
well routing doesn't matter after all).
>Yep. But there are folks working on making very very fast implementations
>and they are getting burned by protocol design issues.
I would have to analyze the implementations. An argument that a
protocol must be designed in a specific way because some researcher in
some unique environment had some sort of problem is not is not an
argument but simply an unjustified assertion.
Go look at Van Jacobson's fast IP forwarding code (sent to the end2end-interest
list about 3 years ago as I recall).
You need to learn more about hardware. It is simply cheaper to design
packet switch memories and hardware I/O FIFOs without error detection
or without error detection and correction.
OK -- summarizing your argument, after the link CRC is computing there's
a chance the router will trash the 20 byte IP header while moving it over
data lines from the interface to the forwarding engine and that this risk
is so great we need a checksum in each packet. Right? Sounds silly to me.
I know of boxes that infrequently trash packets, but they usually sufficiently
trash them (and do so randomly enough) that the checksum isn't worthwhile.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25173;
16 Aug 94 2:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25169;
16 Aug 94 2:52 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa26800;
16 Aug 94 2:52 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id IAA24833; Tue, 16 Aug 1994 08:39:24 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id IAA24800; Tue, 16 Aug 1994 08:19:35 +1000
Precedence: list
Received: from pluto.dss.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA18926; Tue, 16 Aug 1994 05:49:23 +1000 (from martillo at pluto.dss.com)
Received: by pluto.dss.com (4.1/SMI-4.0)
id AA02548; Mon, 15 Aug 94 15:45:02 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joachim Martillo <martillo at pluto.dss.com>
Message-Id: <9408151945.AA02548 at pluto.dss.com>
Subject: Re: IPng recommendation
To: kasten at ftp.com
Date: Mon, 15 Aug 1994 15:45:00 -0400 (EDT)
Cc: martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
In-Reply-To: <9408031415.AA02333 at mailserv-D.ftp.com> from "Frank Kastenholz" at Aug 3, 94 10:15:56 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 32502
>Date: Wed, 3 Aug 94 10:15:56 EDT
>Subject: Re: IPng recommendation
>From: kasten at ftp.com (Frank Kastenholz)
>Cc: big-internet at munnari.oz.au, ietf at CNRI.Reston.VA.US
>Joachim,
>First of all, comments would have been preferred during the debate.
>Certainly before the IPng choice. Comments now are roughly akin to
>locking the barn door after the horse has run off, though since there
>is still IPNG development work to be done, I am sure that the IPng
>developers will carefully consider your points.
For some reason, people who regularly take part in developing IETF
standards have a major misconception about standards development in
the context of manufacturing regimes. I recently made this point as
follows on the SNMP mailing list.
International regimes, national regimes and manufacturing regimes
produce standards. The ISO is an international regime. The Deutsche
Bundespost is a national regime. IBM with respect to SNA or Microsoft
with respect to Windows are examples of manufacturing regimes.
Another example of a manufacturing regime is the voluntary regime
among screw manufacturers governing helicity, pitch and groove width of
screws.
The IETF is a manufacturing regime like the screw regime. The goal of
the IETF should be to produce a set of standards so that purchasers of
TCP/IP based products can feel assured that TCP/IP devices can
effectively operate and interoperate in the environment of a
multiprotocol internet.
The raison d'etre of such a manufacturing regime is products not
standards. Developers of IETF standards must understand that product
developers and product customers pass ultimate judgment on IETF
standards. The real criticism begins once the IETF produces an
official RFC (which in fact does stand fo Request for Comments).
Ultimately the market will judge some IETF standards stupid just as
the market and Ken Olson ultimately judged token bus stupid. If IETF
contributors are going to freak every time people outside the
standards process have problems with an IETF standard, ultimately the
IETF may prove to have no value.
>Second, one of the 'principles' which Craig and I started using in
>refining the criteria was what has been called 'In your face'
>requirements. If the criteria were set at a relatively 'safe' or
>'low' level, then that is all we might get. You mention, for example,
>10**15 end nodes. If we had set, for example, 10**10 end nodes, then
>that is possibly all we would get. By setting a higher level, we may
>still get only 10**10, but we might also get more. Furthermore, by
>saying 10**15, the developers (and the rest of the community) may
>think more about what a truly ubiquious global internetwork might
>need and what it could do.
The use of a so-called "in your face argument" implies an inability to
present a rational argument in favor of some position to a reasonable
target audience persuasively. Certainly, using an "in your face
argument" is unprofessional and suggests some major deficiencies in
either the presenter or the position presented.
In this case, the real problem seems to be the end-address allocation.
Rather than making a requirement of order(250,000) addresses per human
a better requirement might have been that IPng provide a reasonable
end-address allocation scheme.
> > After noticing some of the discussion of IPng criteria, I ftp'd over
> > the criteria. Exactly how to interpret this document is unclear.
>This document, in its final form, was considered as a framework (not
>the only one) about which discussions of the various IPNG candidates
>could be held by the IPng directorate. You might, in effect, consider
>the section headings to be an 'agenda' of items to be evaluated in
>the various proposals.
Perhaps, if Kastenholz would learn how to write a serious technical
document, treating this document as an agenda would have been
possible. Unfortunately, as one can see from the table of contents
following, not only do the section headers contribute to a major lack
of seriousness and professionalism, but there is also little clue in
the section headers of the document in question to hint at the nature
of the document.
Table of Contents
Status of this Memo .................................... 1
1 Introduction .......................................... 2
2 Goals ................................................. 3
3 Note on Terminology ................................... 5
4 General Principles .................................... 6
4.1 Architectural Simplicity ............................ 6
4.2 One Protocol to Bind Them All ....................... 6
4.3 Live Long ........................................... 6
4.4 Live Long AND Prosper ............................... 7
4.5 Co-operative Anarchy ................................ 7
5 Criteria .............................................. 9
5.1 Scale ............................................... 9
5.2 Topological Flexibility ............................. 11
5.3 Performance ......................................... 12
5.4 Robust Service ...................................... 14
5.5 Transition .......................................... 15
5.6 Media Independence .................................. 17
5.7 Unreliable Datagram Service ......................... 19
5.8 Configuration, Administration, and Operation ........ 20
5.9 Secure Operation .................................... 22
5.10 Unique Naming ...................................... 24
5.11 Access ............................................. 25
5.12 Multicast .......................................... 26
5.13 Extensibility ...................................... 27
5.14 Network Service .................................... 29
5.15 Support for Mobility ............................... 30
5.16 Control Protocol ................................... 31
5.17 Private Networks ................................... 32
5.18 Things We Chose Not to Require ..................... 33
6 Routing ............................................... 35
6.1 Scale ............................................... 35
6.2 Policy .............................................. 35
6.3 QOS ................................................. 36
6.4 Feedback ............................................ 36
6.5 Stability ........................................... 36
6.6 Multicast ........................................... 36
7 Security Considerations ............................... 38
8 Acknowledgments ....................................... 39
9 References ............................................ 40
10 Change Log ........................................... 42
10.1 25 May 1994 ........................................ 42
10.2 10 May 1994 ........................................ 42
10.3 25 April 1994 ...................................... 42
10.4 23 March 1994 ...................................... 43
10.5 21 March 1994 ...................................... 43
10.6 10 March 1994 ...................................... 45
10.7 9 March 1994 ....................................... 45
10.8 15 February 1994 ................................... 46
10.9 9 November 1993 .................................... 47
10.10 9 September 1993 .................................. 48
10.11 14 December 1992 .................................. 48
By way of contrast, the following are section headers from a document
I wrote to propose a reasonable architecture for hybrid bridge routers
(available via anonymous ftp from pluto.dss.com in the Constellation
directory). It may not be a great document, but the section headers
do hint that the subject of the document is the architecture of hybrid
bridge routers.
I. Introduction 1
II. IP Routers 5
III. P802.1d MAC Bridges 11
IV. Contrasting Bridges and Routers 21
V. Disjoint Functionality Hybrid Bridge Routers 31
VI. Parallel Router Filtering Bridge Architecture for Hybrid Bridge
Routers 31
VII. Logical Subbridge Architecture for Hybrid Bridge Routers 35
VIII. Conclusion 39
Terminology 41
> > >5.3. Performance
> > >Furthermore, at a minimum, a
> > >host must be able to achieve data transfer rates with
> > >IPng comparable to the rates achieved with IPv4, using
> > >similar levels of host resources.
> > Since poor router performance can affect a whole internet rather than
> > simply an individual host, the criterion should have concentrated
> > attention on router performance.
>It originally did. However, it was also pointed out that if IPng made
>host performance 'very bad' then, even if the routers were blindingly
>fast, IPng would be a loser. Furthermore, IPng really should not be
>perceived as a step backwards wrt IPv4. If IPng made hosts
>significantly slower then it would be just such a step.
>Now, this might all seem trivial, obvious, irrelevant, and
>motherhood. But, on the other hand, host performance was a major
>factor in the discussion about addressing on the big-i list. If host
>performance wasn't critical then that discussion may well have had a
>different outcome.
I remember having this argument at Prime (where people used to argue
that it was reasonable to get undefined or erroneous results when,
because or even though the arguments to a function and its formal
parameter definitions were consistent and within range).
In IP-type internetworking, N-interface hosts and N-interface routers
are distinguishable in that N-interface end hosts do not forward
packets. (The single interface host is of course a degenerate case of
an N-interface host.)
One would think it would be really hard to design an IP-like
internetworking system wherein routers were blindingly fast while end
hosts performed very badly even though hosts differed from routers
only by not doing something that routers did.
> > >We limit this requirement to commercially available
> > >routers and media. If some network site can obtain a
> > >particular media technology "off the shelf", then it
> > >should also be able to obtain the needed routing
> > >technology "off the shelf." One can always go into some
> > >laboratory or research center and find newer, faster,
> > >technologies for network media and for routing. We do
> > >believe, however, that IPng should be routable at a speed
> > >sufficient to fully utilize the fastest available media,
> > >though that might require specially built, custom,
> > >devices.
> > This comment suggests that the new address structure should enable the
> > quickest possible route look-up. The quickest possible route look-up
> > means that a network number should conveniently correspond to a
> > natural register size on common communications computers and that
> > accesses to slower processor external memory should be minimized.
> > Such needs and 16 byte addresses are hard to reconcile with current
> > router technology.
>First, we attempted to stay as far away from dictating implementation
>as we could.
This assertion is an IETF situational justification. Suddenly, there
is an IETF principle which rejects dictating implementation. Then how
is the OSPF protocol "specification" justified? That novel of a
document cannot be considered in any way, shape or form a reasonable
protocol specification. It is nothing but one possible (but certainly
not obviously the best) implementation specification,
> Your comment implies that we should have said, for
>example, that addresses must have a 4-byte (or whatever number)
>network number field. This would be dangerously close to specifying
>the implementation, and not pointing out the problems that were to be
>solved. (By pointing out the problem, we in theory allowed for a wide
>variety of solutions.)
Claiming that somehow specifying a 4-byte network number field
specifies the implementation is a complete non-sequitur. Such a
specification of the network number field would say nothing about how
the network number was structured. In fact, such a network number
field could be split into an area and a non-area portion or some other
hierarchical scheme.
A similar specification of the host ID field would also say nothing
about how the host ID field was structured. In fact, such a host ID
field could be split into some sort of subnet field and subnet host ID
field or some other structured scheme.
>Second, some people are envisioning that a majority of traffic in the
>future internet will be forwarded not based on topological
>information carried around in the packet, but rather on a smaller,
>more easily handled, 'flow-id' which would have the properties you
>talk about. I note that SIPP has such a flowid.
This comment sounds like an admission that SIPP addressing is
completely broken with respect to performance and as a consequence
another level of complexity and possible errors must be added to
compensate for the damage which SIPP addressing does. Thus there may
be no way to tell from the address how a given packet might be routed
because the "flow id" will determine the routing. In any case, such a
field makes the non-data header portion even larger (a major concern
on low bandwidth channels), and provides even more bits in the header
not protected against errors by checksum.
> > >We also observe that many researchers believe that a
> > >proper IPng router should be capable of routing IPng
> > >traffic over links at speeds that are capable of fully
> > >utilizing an ATM switch on the link.
This requirement is uncorrellated. Maybe some sort of
price-performance is being required.
> > ATM is yet another fad technology whose fad may be approaching its
> > end...A better targer might be wire-speed routing in the context of a LAN
> > switch using fast Ethernet or CDDI.
>The base criterion does not mention any specific technology. We felt
>that we could not accurately predict what technology would be the
>'right' technology in 5 or 10 years.
There was no reason to care. The whole point of the internetwork
layer is the creation of a virtual network which hides the details of
specific technologies.
> > >Some predictions have been made that, as the Internet
> > >grows and as more and more technically less-sophisticated
> > >sites get connected, there will be more failures in the
> > >network. These failures may be a combination of simple
> > >size; if the size of the network goes up by a factor of n
> > >then the total number of failures in the network can be
> > >expected to increase by some function of n. Also, as the
> > >network's users become less sophisticated, it can be
> > >assumed that they will make more, innocent and well
> > >meaning, mistakes, either in configuration or use of
> > >their systems.
This failure estimate model is not reasonable.
>Also, we are envisioning a future where the entities who connect to
>the Internet will not be like they are today. They will be sites that
>are non-technical (in the networking sense) and probably will not
>have the system operations staff that current sites have. Imagine a
>dentist's office connecting to the network. This is also the reason
>why we are stressing a 'plug-and-play' configuration ability. The
>less that has to be configured, the less chance of making such errors.
Such sites will probably deal with their internetworking service needs
the same way they deal with their telephone service needs. Just as
they have a small PBX, they might have an internet interconnection
device. When the PBX doesn't work, they call the supplier. If the
internet interconnection device doesn't work, they would call the
supplier.
In any case, the section of the requirements document which dealt with
"plug-and-play" was completely confused. My Appletalk and IPX hosts
are plug-and-play, but they do not boot over the network. Network
boot and plug-and-play are completely orthogonal.
> > >5.12. Multicast
> > The above comment is idiotic. Exactly how a network layer multicast
> > is resolved to a MAC layer address for some arbitrary medium is not
> > obviously part of the network layer design.
>It says 'When mac-layer multicasting is available, use it in preference
>to broadcasts.'
This requirement is not relevant to the specification of IPng. How an
IPng packet is to be transported across a given medium is part of a
medium specific IPng encapsulation specification and not part of the
IPng protocol specification.
A sensible encapsulation specification would specify network layer
multicasts be transported with whatever MAC addresses make the most
sense. It is not to hard to envision a medium where mac-layer
multicasting might be present but where mac-layer broadcast might make
more sense as an encapsulation (e.g. a switched medium where
multicasts were limited to some small number of hosts -- perhaps 16 --
while broadcasts would reach all hosts within the communcations subnet
on a dedicated out of band channel).
> > Furthermore, as Appletalk
> > has abundantly shown a protocol that uses multicast exclusively can
> > certainly be antisocial in the sense of burning up a lot of bandwidth.
>This criterion does not say that one should use multicasts instead of
>unicasts. There are certain types of applications (eg multi-person
>conferencing, finding servers) where using unicasts is not the best
>way to go. If the existance of these applications is a given, then we
>have a choice of using MAC-level multicasts or broadcasts (where
>mcasts are available). We believe that multicasts are preferred in
>these situations.
You misunderstood my comment. Appletalk uses multicasts exclusively
in situations where IP would use broadcasts.
> > >6. Routing
> > >Routing is a very critical part of the Internet. In fact, the
> > >Internet Engineering Task Force has a separate Area which is
> > >chartered to deal only with routing issues. This Area is
> > >separate from the more general Internet Area.
> > >We see that routing is also a critical component of IPng.
> > >There are several criteria, such as Scaling, Addressing, and
> > >Network Services, which are intimately entwined with routing.
> > Shouldn't routing performance be included among these critical
> > components?
>What exactly is routing performance?
I have lead teams working on compilers, word processors, spreadsheets
and switches. Every once in a while I would review an engineer's work
and point out that a given approach would lead to unacceptably low
performance.
If the engineer then tried to suggest that there were conceptual
problems with defining performance for the target application, I had a
serious problem because the engineer was trying to rationalize away a
complete lack of understanding with respect to the technology,
performance issues or software engineering in general.
Someone who had a modicum of understanding might have consulted one of
the standard textbooks like Computer Architecture: A Quantitative
Approach or Computer Organization & Design: The Hardware/Sortware
Interface (both by Patterson & Hennessy) and tried to determine how
some of the general principles outlined there might apply to the
problem at hand.
> There are at least three
>separate functions that are commonly subsumed under the term
>'routing' and the performance could apply to any of the three.
In this case we might ask what activity is most critical to the vast
majority of users of the network.
Does he care about the distribution of routing information? In a well
functioning network, the network converges to a stable topology and
nothing should change very often.
Does he care about the calculation of routes by routers which really
should in a well functioning network come to the same result iteration
after iteration?
No, but after the speed with which packets are received or transmitted
at the local interface, he would care about how quickly packets are
switched in the routers from the incoming to the outgoing interfaces
(unless he is exceptionally patient). The ratio of data to control
information would probably concern him (especially on low bandwidth
channels).
> We
>believe that we have performance of Forwarding packets well covered.
There is no basis for this belief. With the size of addresses and
cruft like the flow ID, IPng will be a disaster on low to moderate
speed channels.
In environments where successive packets transmitted between two end
hosts are likely to follow different equal cost routes described by
possibly very different values of parameters like MTU. MTU might
continuously have to be rediscovered and many packet transmissions
will fail because MTU on an intermediate network was exceeded.
In such a network, best network performance might have been achieved
with a packet size somewhat less than the MTU on most possible paths
but which might lead to fragmentation on other paths (were
fragmentation supported).
Single frame acknowledged protocols (of which I believe Sun NFS is an
example) may suffer major performance losses because of choices made
with respect to IPng. On ethernet and other LAN networks, the
performance of a single frame acknowledged protocol could be enhanced
(with IPv4) by purposefully setting packet size larger than the medium
specific MTU. In this way several full size IP packets can be
transmitted before an acknowledgement is required.
The IPng requirements for no legitimate reason discarded this useful
capability which might in some cases provide significant performance
enhancements. Such a decision is not only bad engineering, but is
pure obnoxiousness and verges on a rape of customers who over the
years have come to depend on the existence of a feature discarded by
unjustified fiat.
>The other functions, information distribution (i.e. the routing
>protocols) and route calculation are harder to specify. Should we say
>that the 'Routing Protocols should be efficient' and 'Route
>calculation should be fast'? This seems too nebulous.
>Frank Kastenholz
>To: Joachim Martillo <martillo at dss.com>
>Cc: big-internet at munnari.oz.au, ietf at cnri.reston.va.us
>Subject: Re: IPng recommendation
>From: Craig Partridge <craig at aland.bbn.com>
>Date: Thu, 04 Aug 94 10:17:06 -0700
>Hi:
> Let me see if I can reply to some of your concerns about the IPng
>criteria document. (I'll skip spots where you agreed with it and some spots
>where I wasn't sure of what the key point was).
> First off, the concern on 10**15 end-hosts. We're quite clear
>about why we said that. We derived it straight from other work which we
>felt wasn't quite demanding enough in terms of the number of devices in the
>home. The fact that it comes out to 250,000 addresses per human only reflects
>some of the Internet's difficulties with efficient address allocation.
Then IPng requirements should have required that this difficulty be
addressed.
>> This comment suggests that the new address structure should enable the
>> quickest possible route look-up. The quickest possible route look-up
>> means that a network number should conveniently correspond to a
>> natural register size on common communications computers and that
>> accesses to slower processor external memory should be minimized.
>> Such needs and 16 byte addresses are hard to reconcile with current
>> router technology.
>Um, no, I'm afraid I don't agree with this analysis. I think a better
>answer is to say that the header size should be a small number of cache
>lines in size (the unit of access is no longer a register size). With
>128-bit cache lines, SIPP16 is 3 cache lines and with 256 it is two
>cache lines. Furthermore, most RISC systems have so many registers that
>putting the entire header into registers isn't hard -- and the address
>lookup in 90% of the cases is just a hash followed by a couple of compares.
Caches can help with the route table, and a lot of registers can help
with address comparisons. But caches do not help in groveling through
the header of a received packet, and header information must still be
exchanged between registers and slow processor external memory. The
longer the header is, the more time will be expended in this transfer
for a given hardware implementation.
At Prime the networking stars always wanted to argue that future
hardware would compensate for the lousy performance of networking
software, but in the IP internet context we have to worry about a
massive performance loss on the massive installed base of hardware
because of design decisions made in (somewhat misguided) anticipation
of the performance capabilites of future hardware.
>> BTW, after groveling through numerous packet switching implementations
>> and network drivers, almost invariably I have found that bottlenecks
>> and low performance have been due not to protocol design but poor
>> software implementations or (often even more importantly) due to the
>> host OS architecture. The protocol design has generally been an
>> extremely minor component of network/packet-switching performance.
>Yep. But there are folks working on making very very fast implementations
>and they are getting burned by protocol design issues.
I would have to analyze the implementations. An argument that a
protocol must be designed in a specific way because some researcher in
some unique environment had some sort of problem is not is not an
argument but simply an unjustified assertion.
Tony Bono, Director of Bridge Router Development at Penril Datability
Networks, came across such bogus justification with respect to task
exchange time for the OS of a packet switch. Supposedly the task
exchange had to meet some requirements which he did not have security
clearance to read. Once he got clearance, he found that there was no
such requirements and that the other engineer simply had been unable
to justify his position rationally.
>> >5.5. Transition
>> >The transition plan should address the issue of cost
>> >distribution. That is, it should identify what tasks are
>> >required of the service providers, of the end users, of
>> >the backbones and so on.
>> This comment is rather scary. The IETF collectively has no obvious
>> expertise in public finance, accounting or political economics.
>>
>> The one area where the IETF has tried to distribute costs is network
>> management, and in this case the IETF has managed to make small
>> installations subsidize the development of SNMP on behalf of a few
>> large network providers even though the small installations have no
>> real need of such a thing.
>I dunno. We've got a lot of folks who've led successful startups etc.
>Or putting this another way, if the idea is that folks who are in the IETF
>cannot at least try to address issues of finance, accounting or economics,
>why should we believe they are qualified to run businesses?
Scoring in the high tech industry often has little to do with business
qualifications. In any case, costing is a bean-counter issue. Rarely
do bean-counters become successful entrepreneurs, and few successful
entrepreneurs have started out as bean-counters. In any case, hi-tech
engineers seem particularly bad at costing, and are probably the last
ones who should be addressing such an issue.
>At some level, one just has to look at some of these problems -- so we will.
But mention of these problems is really irrelevant to the IPng
requirements specification.
>> >IP Header Checksum
>> >There has been discussion indicating that the IP Checksum
>> >does not provide enough error protection to warrant its
>> >performance impact. The argument states that there is
>> >almost always a stronger datalink level CRC, and that
>> >end-to-end protection is provided by the TCP checksum.
>> >Therefore we believe that an IPng checksum is not
>> >required per-se.
>> The IP header checksum is not intended to provide end-to-end data
>> integrity but rather provides local address integrity. Few routers
>> provide EDAC. Stuck bits in the wrong place after receive datalink
>> CRC is calculated could easily cause some poor neighboring router to
>> be inundated with misdirected packets whose lack of data integrity
>> might not be detected until much later or even never (if the new
>> address corresponds to no actual address). This problem could be
>> particularly serious in the cases of applications which rarely or
>> infrequently require acknowledgement of transmitted data packets.
>Read the paragraph again. It says that local address integrity is sufficiently
>protected by the link CRC and that end-to-end integrity of the IP datagram
>is ensured by the end-to-end TCP checksums. Simple engineering.
You need to learn more about hardware. It is simply cheaper to design
packet switch memories and hardware I/O FIFOs without error detection
or without error detection and correction.
I have grovelled through the hardware designs of 5 different
internetwork packet switches. None would guarantee local address
integrity as you seem to expect.
If anyone reading this note knows of a packet switch with the sort of
error detection circuitry which Partridge seems to assume, I would be
interested to learn about it.
>Craig
>From: Dave Katz <dkatz at cisco.com>
>Subject: IPng recommendation
>Sorry, I thought you were caught by the "can't forward to another box
>on the wire without a router" red herring.
>Address autoconfiguration has been defined at the ISO level only as a
>server-based process. However, there is nothing to explicitly bar
>other approaches. At least one ES vendor has implemented a scheme that
>falls back to being completely serverless on isolated LANs (trivial,
>since there's a "local scope" address format defined). This obviously
>can be done without being in violation of any spec (since from the outside
>you can't tell that it wasn't just statically defined).
This scheme makes a lot of sense if once the isolated LAN is connected
to an internet, the local scope addresses are supplanted by global
scope addresses.
>There is also an internet draft (draft-ietf-tuba-addr-assign-00.txt) that
>attempts to formalize the spectrum of possibilities into a single mechanism.
>So, yes, I think you've been burned by bad info again, in that there
>is no requirement per se to have a router present.
> From: Craig Partridge <craig at aland.bbn.com>
> Date: Thu, 04 Aug 94 10:56:12 -0700
> Sender: craig at aland.bbn.com
> Dave:
> You mean I've been burned by bad info again?
> My understanding was that if one wanted to do certain types of dynamic
> address assignment under OSI one had to have a router present because dynamic
> assignment required ES-IS and ES-IS required a router to be present. Is this
> incorrect?
> Craig
An important part of developing requirements for IPng should have been
learning how other protocol suites dealt with relevant issues.
Analysis and comparison could have provided insights and helped avoid
pitfalls.
IPX and Appletalk are in many ways superior to classic IP. DECNET has
been transitioned several times to newer versions that offered more
capabilities. SNA has generally provided particularly high
performance communications between end hosts.
IPng would look a lot less problematic if the WG had approached the
task of developing requirements for IPng far more systematically.
IPng would look far less parochial and far less prone to recapitulate
errors already made and fixed in other contexts, had the WG made more
extensive use of internetworking knowledge developed outside the arena
of TCP/IP.
Joachim Martillo
Manager of Internetworking Research
Penril Datability Networks
Penril Datability Advanced Communications Research Center
190 N. Main St.
Natick, MA 01760
VOICE 508-653-5313
FAX 508-653-6415
EMAIL martillo at dss.com
martillo at penril.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25364;
16 Aug 94 3:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25354;
16 Aug 94 3:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27165;
16 Aug 94 3:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25345;
16 Aug 94 3:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25321;
16 Aug 94 3:20 EDT
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa27150;
16 Aug 94 3:20 EDT
Received: (from ole at localhost) by Csli.Stanford.EDU (8.6.9/8.6.9) id PAA29805; Mon, 15 Aug 1994 15:53:25 -0700
Date: Mon, 15 Aug 94 15:53:24 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: ietf at CNRI.Reston.VA.US, tcp-ip at nic.ddn.mil, iso at nic.ddn.mil
Phone: +1 415 578-6900 (ZD Expos)
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager)
FAX: +1 415 525-0194 (ZD Expos) +1 415 826-2008 (Home)
Address: 303 Vintage Park Drive, Foster City, CA 94404-1138
Subject: 2nd Call: BOFs for NetWorld+Interop
Message-ID: <CMM.0.90.4.776991204.ole at Csli.Stanford.EDU>
NetWorld+Interop 94 Atlanta is less than a month a way. There are still a
few BOF slots open. Contact me via e-mail with your proposals.
Following a long tradition, we will once again offer the opportunity
for interested parties to meet and discuss topics of mutual interest
in Birds of a Feather (BOF) sessions. The venue is NetWorld+Interop 94
Atlanta. This time, BOFs will be held Monday and Tuesday nights,
September 12th an 13th, from 7:30pm until 9:30pm. All BOFs will take
place at the Georgia World Congress Center in Atlanta.
BOFs provide attendees with an opportunity to discuss networking
issues in an informal, after hours, atmosphere. BOFs have become a
forum for users to meet with other users and with implementation
experts. These sessions are not intended for formal presentations, and
certainly NOT for vendor product presentations, but rather as a forum
for discussions of "unsolved problems." BOFs are open to all
Networld+Interop attendees, including Exhibition attendees, and no
special registration is necessary. Examples of some BOF topics from
previous Interop events include:
o Network Device Performance Testing
o Internet information tools (WWW, Gopher, WAIS, Archie....)
o Internet Firewalls and Hackers
o SNMP Testing
o Fast Ethernet Standards
o Networked multimedia systems
o Resource Reservations Protocols
o Using Facsimile Devices around the World as Remote Printers
o The Internet and K-12 schools
To suggest a topic for a BOF at NetWorld+Interop 94 Atlanta
please send a 50 word abstract to Ole Jacobsen (ole at interop.com)
as soon as possible. Space is limited, first come, first served.
For your information, the following is a sample BOF description:
Internet Firewalls and Hackers
------------------------------
In the wake of recent well-publicized hacking attacks, interest has
grown in the hacker's methods and the tools used to exclude them. The
use of firewalls and one-time password schemes can foil most common
hacking schemes. This BOF will be an informal interactive discussion
of hacking techniques, and the various tools and approaches commonly
used to implement a denial-of-hacker service. It will undoubtedly
include war stories and firewall designs and philosophy.
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report,
Interop Company, a division of ZD Expos, 303 Vintage Park Drive, Foster City,
CA 94404-1138, USA. Phone: +1 (415) 578-6988 Fax: +1 (415) 525-0194.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00517;
16 Aug 94 4:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00513;
16 Aug 94 4:20 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa01214;
16 Aug 94 4:20 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
id SAA25317; Tue, 16 Aug 1994 18:02:44 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
id RAA25288; Tue, 16 Aug 1994 17:43:41 +1000
Precedence: list
Received: from [36.53.0.155] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA11732; Tue, 16 Aug 1994 16:33:37 +1000 (from dcrocker at mordor.stanford.edu)
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id OAA00620; Mon, 15 Aug 1994 14:18:09 -0700
Message-Id: <aa758a930d02102406ad at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 15 Aug 1994 14:18:13 -0700
To: Joachim Martillo <martillo at pluto.dss.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: IPng recommendation
Cc: kasten at ftp.com, martillo at pluto.dss.com, big-internet at munnari.oz.au,
ietf at CNRI.Reston.VA.US
Joachim,
As always, your contributions assisting the IETF to understand its
continued pattern of failure, as well as your subtle touch with personal
exchanges, is I am sure appreciated by the breadth and depth of the
Internet community. We shall, of course, endeavor to learn from the errors
you so consistently point out.
Can't imagine how we've managed to fail so completely, all these years.
d/
P.S. No need to thank me. I'm sure I can intuit your own appreciation of
my response.
-----
Dave Crocker <dcrocker at mordor.stanford.edu>
675 Spruce Dr. +1 408 246 8253; fax: +1 408 249 6205
Sunnyvale, CA 94086 (USA)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04651;
16 Aug 94 10:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04641;
16 Aug 94 10:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07490;
16 Aug 94 10:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04632;
16 Aug 94 10:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04541;
16 Aug 94 10:13 EDT
Received: from mac-50.cnri.reston.va.us by CNRI.Reston.VA.US id aa07382;
16 Aug 94 10:13 EDT
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Aug 1994 10:18:54 -0500
To: ietf at CNRI.Reston.VA.US, e2e-interest at isi.edu, ip-atm at hpl.hp.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Bonnie K. Brown" <bbrown at CNRI.Reston.VA.US>
Subject: GIGABIT TESTBED JAMBOREE
Message-ID: <9408161013.aa07382 at CNRI.Reston.VA.US>
The fifth Gigabit Testbed Workshop (aka Gigabit Testbed Jamboree)
will be held November 2-4, 1994 at the Hyatt Regency Hotel in Reston,
Virginia. This workshop will present results from the gigabit
testbeds being sponsored under CNRI's Cooperative Agreement with
the government, and in addition will provide a forum for technical
interaction among attendees. The National Science Foundation and
the Advanced Research Projects Agency are providing funding for the
gigabit testbeds in conjunction with major support from industry.
Attendance at this year's Jamboree has been expanded to accommodate
a larger segment of the technical community than has been the case
in past years. Space is limited, however, and registration will be
on a first-come-first-served basis. You will receive notification
within 2 to 3 weeks of sending in a registration form on whether
you can be accommodated.
The program will consist of a single track of presentations and
panel sessions over the three days, with a focus on testbed work
in the areas of network technology and the networking of applications
at gigabit speeds. Topics will include testbed experiences in
wide area transmission and switching using ATM and variable-length
PTM approaches, gigabit-rate network I/O for supercomputer and
workstation class computers, high speed protocols and distributed
shared memory techniques, the interworking of gigabit technologies,
and the investigation of distributed supercomputing and multimedia
workstation applications over wide area gigabit networks.
There will be a reception and buffet on Tuesday evening,
November 1, starting at approximately 6:30pm. The workshop will
include a continental breakfast and lunch each day. A reception
and dinner is also planned for Wednesday evening, with Thursday
evening free. The workshop will end at approximately 4:00pm on
Friday.
The registration fee is $325.00, which includes all workshop meals,
receptions, and a copy of the proceedings. Each attendee is
responsible for making his or her hotel reservations. A block of
rooms is being held at the Hyatt Regency in Reston Town Center at
the special rate of $110.00 plus tax per night single and $130.00
double occupancy. Reservations must be made by October 12 to obtain
these rates. The Hyatt's reservation number is 703-709-1234; be sure
and state that you are attending the CNRI Gigabit Testbed Workshop.
If you would like to attend, please return the attached registration
form to CNRI as soon as possible to ensure that space is reserved for
you (a separate form is required for each person registering). Note
that a higher registration fee of $360.00 will be charged for
registration forms received after October 1.
REGISTRATION FORM
Fifth Gigabit Testbed Workshop
November 2-4, 1994
Reston, VA
(Please print or type)
NAME (Mr/Dr/Ms/):
ORGANIZATION:
ADDRESS:
CITY: STATE: ZIP CODE:
TELEPHONE: FAX:
EMAIL:
Do you plan to attend the evening reception on Tuesday, November 1st? YES__NO__
$325.00 Registration Fee if registration form is received by October 1;
$360.00 after that date.
Method of payment: ___AMEX ___VISA ___MC ___DINERS ___Check enclosed
If Check: U.S. dollars, drawn on a U.S. Bank payable to:
Corporation for National Research Initiatives
If Credit Card: ACCOUNT #: EXP DATE:
CARDHOLDER NAME:
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: bbrown at cnri.reston.va.us
Facsimile: 703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - Gigabit Workshop
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
IMPORTANT:
- Register one person per form.
- Purchase orders cannot be accepted.
- (If your registration can be accommodated):
Requests for refunds must be received by October 15, 1994,
and are subject to a $50.00 service charge.
- If space no longer exists at the time your registration is
received, your credit card will not be charged or your check
will be returned.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05450;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08243;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05395;
16 Aug 94 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05277;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sipp at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sipp-ap-04.txt
Date: Tue, 16 Aug 94 10:47:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161047.aa05277 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Internet Protocol Plus
Working Group of the IETF.
Title : IPv6 Authentication Header
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-ap-04.txt
Pages : 9
Date : 08/15/1994
This draft specifies the Authentication Header to be used to provide
authentication and integrity without confidentiality to IPv6 datagrams.
It is one of two security mechanisms proposed for IPv6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-sipp-ap-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-sipp-ap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-sipp-ap-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-ap-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05450;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08243;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05395;
16 Aug 94 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05277;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sipp at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sipp-ap-04.txt
Date: Tue, 16 Aug 94 10:47:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161047.aa05277 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Internet Protocol Plus
Working Group of the IETF.
Title : IPv6 Authentication Header
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-ap-04.txt
Pages : 9
Date : 08/15/1994
This draft specifies the Authentication Header to be used to provide
authentication and integrity without confidentiality to IPv6 datagrams.
It is one of two security mechanisms proposed for IPv6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-sipp-ap-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-sipp-ap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-sipp-ap-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-ap-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05456;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08242;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05394;
16 Aug 94 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05234;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-bitmap-00.txt
Date: Tue, 16 Aug 94 10:47:07 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161047.aa05234 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Bitmap, Cursor and Icon Image Formats
Author(s) : P. Robinson
Filename : draft-robinson-bitmap-00.txt
Pages : 16
Date : 08/15/1994
This document defines the format and content of bitmap, cursor and icon
images as are commonly used under the Graphical User Interface used on
Personal Computers which is sold under the trade name of "Microsoft
Windows". They are defined here in order to add three new MIME
specifications for bitmaps and for icon files when these documents are
transported by E-mail, because the format used by those files as described
by this document is device independent, and thus should be usable by other
Graphical User Interfaces.
There is an RFC (0797) defining bitmaps, but it is deficient for
covering bitmaps containing color, or for Icons or Cursors,
which can be transparent or inverse colored to the background
they are placed against.
Suggestions on topics this document could cover if it becomes issued
as an Internet RFC, in addition to corrections or oversights,
are invited, as well as points that need to be covered for
RFCs which are pending at the time this document is issued.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-bitmap-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-bitmap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815112816.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-bitmap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-bitmap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815112816.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05456;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08242;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05394;
16 Aug 94 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05234;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-bitmap-00.txt
Date: Tue, 16 Aug 94 10:47:07 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161047.aa05234 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Bitmap, Cursor and Icon Image Formats
Author(s) : P. Robinson
Filename : draft-robinson-bitmap-00.txt
Pages : 16
Date : 08/15/1994
This document defines the format and content of bitmap, cursor and icon
images as are commonly used under the Graphical User Interface used on
Personal Computers which is sold under the trade name of "Microsoft
Windows". They are defined here in order to add three new MIME
specifications for bitmaps and for icon files when these documents are
transported by E-mail, because the format used by those files as described
by this document is device independent, and thus should be usable by other
Graphical User Interfaces.
There is an RFC (0797) defining bitmaps, but it is deficient for
covering bitmaps containing color, or for Icons or Cursors,
which can be transparent or inverse colored to the background
they are placed against.
Suggestions on topics this document could cover if it becomes issued
as an Internet RFC, in addition to corrections or oversights,
are invited, as well as points that need to be covered for
RFCs which are pending at the time this document is issued.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-bitmap-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-bitmap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815112816.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-bitmap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-bitmap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815112816.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05465;
16 Aug 94 10:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05450;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08243;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05395;
16 Aug 94 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05277;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sipp at sunroof.eng.sun.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sipp-ap-04.txt
Date: Tue, 16 Aug 94 10:47:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161047.aa05277 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Internet Protocol Plus
Working Group of the IETF.
Title : IPv6 Authentication Header
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-ap-04.txt
Pages : 9
Date : 08/15/1994
This draft specifies the Authentication Header to be used to provide
authentication and integrity without confidentiality to IPv6 datagrams.
It is one of two security mechanisms proposed for IPv6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-sipp-ap-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-sipp-ap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-sipp-ap-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-ap-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05479;
16 Aug 94 10:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05456;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08242;
16 Aug 94 10:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05394;
16 Aug 94 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05234;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-bitmap-00.txt
Date: Tue, 16 Aug 94 10:47:07 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161047.aa05234 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Bitmap, Cursor and Icon Image Formats
Author(s) : P. Robinson
Filename : draft-robinson-bitmap-00.txt
Pages : 16
Date : 08/15/1994
This document defines the format and content of bitmap, cursor and icon
images as are commonly used under the Graphical User Interface used on
Personal Computers which is sold under the trade name of "Microsoft
Windows". They are defined here in order to add three new MIME
specifications for bitmaps and for icon files when these documents are
transported by E-mail, because the format used by those files as described
by this document is device independent, and thus should be usable by other
Graphical User Interfaces.
There is an RFC (0797) defining bitmaps, but it is deficient for
covering bitmaps containing color, or for Icons or Cursors,
which can be transparent or inverse colored to the background
they are placed against.
Suggestions on topics this document could cover if it becomes issued
as an Internet RFC, in addition to corrections or oversights,
are invited, as well as points that need to be covered for
RFCs which are pending at the time this document is issued.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-robinson-bitmap-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-robinson-bitmap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815112816.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-bitmap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-bitmap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815112816.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05629;
16 Aug 94 10:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05625;
16 Aug 94 10:59 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa08389; 16 Aug 94 10:59 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA13851; Tue, 16 Aug 94 07:58:17 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA05067; Tue, 16 Aug 94 07:58:30 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA07282; Tue, 16 Aug 94 08:00:45 PDT
Received: from Eng.Sun.COM (engnews1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA07276; Tue, 16 Aug 94 08:00:38 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1)
id AA10719; Tue, 16 Aug 94 07:57:57 PDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM)
id AB13773; Tue, 16 Aug 94 07:57:44 PDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05277;
16 Aug 94 10:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;,
"CNRI.Reston.VA.US" <@sun.com:CNRI.Reston.VA.US at eng.sun.com>
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: sipp at sunroof.eng.sun.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Subject: (sipp) I-D ACTION:draft-ietf-sipp-ap-04.txt
Date: Tue, 16 Aug 94 10:47:35 -0400
Message-Id: <9408161047.aa05277 at IETF.CNRI.Reston.VA.US>
X-Orig-Sender: owner-sipp at sunroof.eng.sun.com
Precedence: bulk
Reply-To: sipp at sunroof.eng.sun.com
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Internet Protocol Plus
Working Group of the IETF.
Title : IPv6 Authentication Header
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-ap-04.txt
Pages : 9
Date : 08/15/1994
This draft specifies the Authentication Header to be used to provide
authentication and integrity without confidentiality to IPv6 datagrams.
It is one of two security mechanisms proposed for IPv6.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-sipp-ap-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-sipp-ap-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-sipp-ap-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-ap-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815131545.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
------------------------------------------------------------------------------
IETF SIPP Working Group - Archives: parcftp.xerox.com:/pub/sipp
Unsubscribe: unsubscribe sipp (as message body, not subject)
Direct all administrative requests to majordomo at sunroof.eng.sun.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06232;
16 Aug 94 11:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06228;
16 Aug 94 11:53 EDT
Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09414;
16 Aug 94 11:53 EDT
Received: by matmos.hpl.hp.com
(1.37.109.10G/HPL42.42) id AA193906855; Tue, 16 Aug 1994 07:20:55 -0700
Errors-To: atmpost at matmos.hpl.hp.com
X-Orig-Sender: atmpost at matmos.hpl.hp.com
X-Info: Submissions to ip-atm at matmos.hpl.hp.com
X-Info: [Un]Subscribe requests to majordomo at matmos.hpl.hp.com
X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm
X-Loop: ATM CLP.bit ON
Precedence: bulk
Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP
(1.37.109.10G/HPL42.42) id AA193576853; Tue, 16 Aug 1994 07:20:53 -0700
Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP
(1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA16053; Tue, 16 Aug 1994 07:20:52 -0700
Received: from CNRI.Reston.VA.US by hplms26.hpl.hp.com with SMTP
(1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA15745; Tue, 16 Aug 1994 07:20:52 -0700
Received: from mac-50.cnri.reston.va.us by CNRI.Reston.VA.US id aa07382;
16 Aug 94 10:13 EDT
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Aug 1994 10:18:54 -0500
To: ietf at CNRI.Reston.VA.US, e2e-interest at isi.edu, ip-atm at hplms2.hpl.hp.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Bonnie K. Brown" <bbrown at CNRI.Reston.VA.US>
Subject: GIGABIT TESTBED JAMBOREE
Message-Id: <9408161013.aa07382 at CNRI.Reston.VA.US>
The fifth Gigabit Testbed Workshop (aka Gigabit Testbed Jamboree)
will be held November 2-4, 1994 at the Hyatt Regency Hotel in Reston,
Virginia. This workshop will present results from the gigabit
testbeds being sponsored under CNRI's Cooperative Agreement with
the government, and in addition will provide a forum for technical
interaction among attendees. The National Science Foundation and
the Advanced Research Projects Agency are providing funding for the
gigabit testbeds in conjunction with major support from industry.
Attendance at this year's Jamboree has been expanded to accommodate
a larger segment of the technical community than has been the case
in past years. Space is limited, however, and registration will be
on a first-come-first-served basis. You will receive notification
within 2 to 3 weeks of sending in a registration form on whether
you can be accommodated.
The program will consist of a single track of presentations and
panel sessions over the three days, with a focus on testbed work
in the areas of network technology and the networking of applications
at gigabit speeds. Topics will include testbed experiences in
wide area transmission and switching using ATM and variable-length
PTM approaches, gigabit-rate network I/O for supercomputer and
workstation class computers, high speed protocols and distributed
shared memory techniques, the interworking of gigabit technologies,
and the investigation of distributed supercomputing and multimedia
workstation applications over wide area gigabit networks.
There will be a reception and buffet on Tuesday evening,
November 1, starting at approximately 6:30pm. The workshop will
include a continental breakfast and lunch each day. A reception
and dinner is also planned for Wednesday evening, with Thursday
evening free. The workshop will end at approximately 4:00pm on
Friday.
The registration fee is $325.00, which includes all workshop meals,
receptions, and a copy of the proceedings. Each attendee is
responsible for making his or her hotel reservations. A block of
rooms is being held at the Hyatt Regency in Reston Town Center at
the special rate of $110.00 plus tax per night single and $130.00
double occupancy. Reservations must be made by October 12 to obtain
these rates. The Hyatt's reservation number is 703-709-1234; be sure
and state that you are attending the CNRI Gigabit Testbed Workshop.
If you would like to attend, please return the attached registration
form to CNRI as soon as possible to ensure that space is reserved for
you (a separate form is required for each person registering). Note
that a higher registration fee of $360.00 will be charged for
registration forms received after October 1.
REGISTRATION FORM
Fifth Gigabit Testbed Workshop
November 2-4, 1994
Reston, VA
(Please print or type)
NAME (Mr/Dr/Ms/):
ORGANIZATION:
ADDRESS:
CITY: STATE: ZIP CODE:
TELEPHONE: FAX:
EMAIL:
Do you plan to attend the evening reception on Tuesday, November 1st? YES__NO__
$325.00 Registration Fee if registration form is received by October 1;
$360.00 after that date.
Method of payment: ___AMEX ___VISA ___MC ___DINERS ___Check enclosed
If Check: U.S. dollars, drawn on a U.S. Bank payable to:
Corporation for National Research Initiatives
If Credit Card: ACCOUNT #: EXP DATE:
CARDHOLDER NAME:
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: bbrown at cnri.reston.va.us
Facsimile: 703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - Gigabit Workshop
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
IMPORTANT:
- Register one person per form.
- Purchase orders cannot be accepted.
- (If your registration can be accommodated):
Requests for refunds must be received by October 15, 1994,
and are subject to a $50.00 service charge.
- If space no longer exists at the time your registration is
received, your credit card will not be charged or your check
will be returned.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07859;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11721;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07802;
16 Aug 94 13:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07699;
16 Aug 94 13:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-06.txt
Date: Tue, 16 Aug 94 13:26:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161327.aa07699 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-06.txt
Pages : 19
Date : 08/15/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07859;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11721;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07802;
16 Aug 94 13:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07699;
16 Aug 94 13:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-06.txt
Date: Tue, 16 Aug 94 13:26:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161327.aa07699 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-06.txt
Pages : 19
Date : 08/15/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07871;
16 Aug 94 13:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07859;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11721;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07802;
16 Aug 94 13:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07699;
16 Aug 94 13:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-06.txt
Date: Tue, 16 Aug 94 13:26:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161327.aa07699 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-06.txt
Pages : 19
Date : 08/15/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07874;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11730;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07803;
16 Aug 94 13:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07670;
16 Aug 94 13:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-06.txt
Date: Tue, 16 Aug 94 13:26:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161326.aa07670 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-06.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07874;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11730;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07803;
16 Aug 94 13:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07670;
16 Aug 94 13:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-06.txt
Date: Tue, 16 Aug 94 13:26:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161326.aa07670 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-06.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07889;
16 Aug 94 13:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07874;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11730;
16 Aug 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07803;
16 Aug 94 13:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07670;
16 Aug 94 13:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-06.txt
Date: Tue, 16 Aug 94 13:26:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161326.aa07670 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-06.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08091;
16 Aug 94 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08087;
16 Aug 94 13:47 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa12021;
16 Aug 94 13:47 EDT
Received: by interlock.ans.net id AA16913
(InterLock SMTP Gateway 1.1 for iwg-out at ans.net);
Tue, 16 Aug 1994 13:33:41 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Tue, 16 Aug 1994 13:33:41 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Tue, 16 Aug 1994 13:33:41 -0400
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: bgp at ans.net
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4ospf-interact-06.txt
Date: Tue, 16 Aug 94 13:26:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408161327.aa07699 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-bgp-bgp4ospf-interact-06.txt
Pages : 19
Date : 08/15/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4ospf-interact-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-bgp4ospf-interact-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-bgp4ospf-interact-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4ospf-interact-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815114051.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08315;
16 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12222;
16 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08289;
16 Aug 94 13:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08207;
16 Aug 94 13:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-autosys-guide-00.txt
Date: Tue, 16 Aug 94 13:52:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161352.aa08207 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Guidelines for creation, selection, and
registration of an Autonomous System (AS)
Author(s) : J. Hawkinson, T. Bates
Filename : draft-ietf-bgp-autosys-guide-00.txt
Pages : 10
Date : 08/15/1994
This draft discusses when it is appropriate to register and utilize an
Autonomous System (AS), and lists criteria for such. ASes are the unit of
routing policy in the modern world of exterior routing, and are
specifically applicable to protocols like EGP (Exterior Gateway Protocol,
now at historical status; see [EGP]), BGP (Border Gateway Protocol, the
current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The
OSI Inter-Domain Routing Protocol, which the Internet will eventual move to
when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP
equivalent of an AS is the RDI, or Routing Domain Identifier.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-autosys-guide-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-autosys-guide-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-autosys-guide-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-autosys-guide-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08315;
16 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12222;
16 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08289;
16 Aug 94 13:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08207;
16 Aug 94 13:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-autosys-guide-00.txt
Date: Tue, 16 Aug 94 13:52:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161352.aa08207 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Guidelines for creation, selection, and
registration of an Autonomous System (AS)
Author(s) : J. Hawkinson, T. Bates
Filename : draft-ietf-bgp-autosys-guide-00.txt
Pages : 10
Date : 08/15/1994
This draft discusses when it is appropriate to register and utilize an
Autonomous System (AS), and lists criteria for such. ASes are the unit of
routing policy in the modern world of exterior routing, and are
specifically applicable to protocols like EGP (Exterior Gateway Protocol,
now at historical status; see [EGP]), BGP (Border Gateway Protocol, the
current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The
OSI Inter-Domain Routing Protocol, which the Internet will eventual move to
when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP
equivalent of an AS is the RDI, or Routing Domain Identifier.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-autosys-guide-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-autosys-guide-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-autosys-guide-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-autosys-guide-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08327;
16 Aug 94 13:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08315;
16 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12222;
16 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08289;
16 Aug 94 13:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08207;
16 Aug 94 13:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-autosys-guide-00.txt
Date: Tue, 16 Aug 94 13:52:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408161352.aa08207 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Guidelines for creation, selection, and
registration of an Autonomous System (AS)
Author(s) : J. Hawkinson, T. Bates
Filename : draft-ietf-bgp-autosys-guide-00.txt
Pages : 10
Date : 08/15/1994
This draft discusses when it is appropriate to register and utilize an
Autonomous System (AS), and lists criteria for such. ASes are the unit of
routing policy in the modern world of exterior routing, and are
specifically applicable to protocols like EGP (Exterior Gateway Protocol,
now at historical status; see [EGP]), BGP (Border Gateway Protocol, the
current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The
OSI Inter-Domain Routing Protocol, which the Internet will eventual move to
when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP
equivalent of an AS is the RDI, or Routing Domain Identifier.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-autosys-guide-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-autosys-guide-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-autosys-guide-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-autosys-guide-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09174;
16 Aug 94 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09170;
16 Aug 94 14:43 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa13111;
16 Aug 94 14:43 EDT
Received: by interlock.ans.net id AA16954
(InterLock SMTP Gateway 1.1 for iwg-out at ans.net);
Tue, 16 Aug 1994 14:29:52 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Tue, 16 Aug 1994 14:29:52 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Tue, 16 Aug 1994 14:29:52 -0400
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: bgp at ans.net
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-autosys-guide-00.txt
Date: Tue, 16 Aug 94 13:52:24 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408161352.aa08207 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Guidelines for creation, selection, and
registration of an Autonomous System (AS)
Author(s) : J. Hawkinson, T. Bates
Filename : draft-ietf-bgp-autosys-guide-00.txt
Pages : 10
Date : 08/15/1994
This draft discusses when it is appropriate to register and utilize an
Autonomous System (AS), and lists criteria for such. ASes are the unit of
routing policy in the modern world of exterior routing, and are
specifically applicable to protocols like EGP (Exterior Gateway Protocol,
now at historical status; see [EGP]), BGP (Border Gateway Protocol, the
current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The
OSI Inter-Domain Routing Protocol, which the Internet will eventual move to
when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP
equivalent of an AS is the RDI, or Routing Domain Identifier.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-autosys-guide-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-bgp-autosys-guide-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-bgp-autosys-guide-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-autosys-guide-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815134806.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10194;
16 Aug 94 15:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10190;
16 Aug 94 15:28 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa13976;
16 Aug 94 15:28 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA24720 on Tue, 16 Aug 94 13:33:34 -0400
Received: from ietf.cnri.reston.va.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA24716 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Tue, 16 Aug 94 13:33:31 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07670;
16 Aug 94 13:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: uri at bunyip.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-06.txt
Date: Tue, 16 Aug 94 13:26:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408161326.aa07670 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Uniform Resource Locators (URL)
Author(s) : T. Berners-Lee, L. Masinter, M. McCahill
Filename : draft-ietf-uri-url-06.txt
Pages : 15
Date : 08/05/1994
This document specifies a Uniform Resource Locator (URL), the syntax and
semantics of formalized information for location and access of resources
on the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-uri-url-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940815113540.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10561;
16 Aug 94 15:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10553;
16 Aug 94 15:48 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14492;
16 Aug 94 15:48 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA26874 at pad-thai.aktis.com>; Tue, 16 Aug 1994 15:11:06 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA21498; Tue, 16 Aug 94 15:09:36 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <11369-0 at relay1.pipex.net>; Tue, 16 Aug 1994 20:09:18 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA27793; Tue, 16 Aug 94 20:11:13 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA28027;
Tue, 16 Aug 94 20:08:26 BST
Message-Id: <9408161910.AA22151 at getafix.oasis.icl.co.uk>
Date: Tue, 16 Aug 94 20:10:36 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: draft GSS-API MS Windows DLL interface spec
To: cat-ietf at mit.edu
CAT WG,
A draft MS Windows GSS-API DLL interface spec is attached.
Comments?
If there are no objections, I will produce it (or a revision to
reflect any comments) as an I-D.
I would prefer to leave the annexes in, as they're clearly
illustrative, but are directly useful (to cut and paste from) with
respect to RFC 1509.
Piers
---
GSS-API MS Windows Dynamic Link Library Interface
16AUG94
pvm
Contents List
1. Purpose
2. Relationship with the Standards Track GSS-API C Bindings
3. Background and Motivation
4. Scope
5. DLL Interface
5.1 Calling convention
5.2 Pointers
5.3 Structure Alignment
5.4 Implementation-defined Types
5.5 Entry-point Ordinals
5.6 Dynamic Link Library Name
6. Extensions
Informative Annex 1 - Module Definition File
Informative Annex 2 - Prototypes
Informative Annex 3 - Type Declarations
1. Purpose
This note specifies the C interface to GSS-API when implemented in
a MS Windows Dynamic Link Library (DLL).
2. Relationship with the Standards Track GSS-API C Bindings
To minimise the need for further updates of this note, any
differences between the MS Windows GSS-API interface described
here, and the Standards Track GSS-API C Bindings are specified as
deltas rather than by reproducing the C definitions (RFC 1509 at
time of writing).
For illustrative purposes only, informative annexes are provided
to show the interface definition as applied to RFC 1509.
3. Background and Motivation
It is not possible to use the Standards Track GSS-API C Bindings
unchanged in a MS Windows 3.1 environment.
This is because the underlying segmented addressing mechanism is
exposed to the application programmer on 16-bit targets, and valid
assumptions about pointers (in an ANSI C environment) break down.
Specifically, pointers to DLL inputs must be declared "FAR" so
that they point to stack data, otherwise they are incorrectly
assumed to point to data on the data segment of the DLL.
Hence changes are needed to ensure that GSS-API interface pointers
explicitly refer to the data intended by the caller. These are
specified in the following sections.
4. Scope
The interface is defined to be suitable for MS Windows 3.1 and
beyond (i.e.: a Win32 environment isn't assumed)
This interface specification is, in conjunction with the C
Bindings, sufficiently detailed such that binary user applications
can link, unchanged, with different providers' GSS-API Dynamic
Link Libraries.
[Note: This level of portability is in addition to the source-
level compatibility defined by the Standards Track GSS-API C
Bindings for ANSI C environments.]
5. DLL Interface
5.1 Calling convention
The Pascal calling convention is used for all the entry points of
the GSS-API DLL.
This requires the keyword PASCAL to prefix each entry point to
override the default (cdecl).
5.2 Pointers
As the GSS-API library is provided in a DLL, all references passed
to it from calling applications must be declared FAR.
This applies to all parts of the interfaces - both entry points
and data structures.
5.3 Structure Alignment
A structure alignment value of 4 is used to enable the API to be
used for both 16-bit and 32-bit targets.
[Note: This can be implemented by a pragma (#pragma pack(4)), or a
compiler option /Zp4.]
5.4 Implementation-defined Types
For a GSS-API DLL interface to be complete, the types representing
32-bit integers, credentials, contexts, and names need to be
specified.
The implementation-dependent types are therefore fixed for the MS
Windows environment as follows.
typedef DWORD OM_uint32;
typedef VOID FAR *gss_ctx_id_t;
typedef VOID FAR *gss_cred_id_t;
typedef VOID FAR *gss_name_t;
5.5 Entry-point Ordinals
Consumers of GSS-API can import DLL entry points by name or by
ordinal number, but the latter is recommended by Microsoft for
efficiency.
Ordinals for the GSS-API are therefore defined starting from 1,
and are assigned to entry points in the order they are given in
the Standards Track C Bindings.
5.6 Dynamic Link Library Name
The GSS-API is provided in a dynamic library which is called
GSSAPI.DLL.
The associated link-time import library is called GSSAPI.LIB.
6. Extensions
Extensions to GSS-API may be defined in future revisions of the
Standards Track GSS-API C Bindings.
GSS-API extensions from other sources should be provided in
separate DLLs.
Informative Annex 1 - Module Definition File
For RFC 1509, the following is the template module definition file
for the GSS-API DLL.
GSSAPI.DLL Module-Definition File
LIBRARY GSSAPI
DESCRIPTION 'Base Generic Security Service API'
EXETYPE WINDOWS
CODE /* implementation specific */
DATA /* implementation specific */
HEAPSIZE /* implementation specific */
EXPORTS
gss_acquire_cred @1
gss_release_cred @2
gss_init_sec_context @3
gss_accept_sec_context @4
gss_process_context_token @5
gss_delete_sec_context @6
gss_context_time @7
gss_sign @8
gss_verify @9
gss_seal @10
gss_unseal @11
gss_display_status @12
gss_indicate_mechs @13
gss_compare_name @14
gss_display_name @15
gss_import_name @16
gss_release_name @17
gss_release_buffer @18
gss_release_oid_set @19
gss_inquire_cred @20
Informative Annex 2 - Prototypes
For RFC 1509, the following are the entry points for the GSS-API
DLL, as would be declared in <gssapi.h>.
OM_uint32 FAR PASCAL gss_acquire_cred
(OM_uint32 FAR *, /* minor_status */
gss_name_t, /* desired_name */
OM_uint32, /* time_req */
gss_OID_set, /* desired_mechs */
int, /* cred_usage */
gss_cred_id_t FAR *, /* output_cred_handle */
gss_OID_set FAR *, /* actual_mechs */
OM_uint32 FAR * /* time_rec */
);
OM_uint32 FAR PASCAL gss_release_cred
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t FAR * /* cred_handle */
);
OM_uint32 FAR PASCAL gss_init_sec_context
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t, /* claimant_cred_handle */
gss_ctx_id_t FAR *, /* context_handle */
gss_name_t, /* target_name */
gss_OID, /* mech_type */
int, /* req_flags */
int, /* time_req */
gss_channel_bindings_t,/* input_chan_bindings */
gss_buffer_t, /* input_token */
gss_OID FAR *, /* actual_mech_type */
gss_buffer_t, /* output_token */
int FAR *, /* ret_flags */
OM_uint32 FAR * /* time_rec */
);
OM_uint32 FAR PASCAL gss_process_context_token
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t /* token_buffer */
);
OM_uint32 FAR PASCAL gss_delete_sec_context
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t /* output_token */
);
OM_uint32 FAR PASCAL gss_sign
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context handle */
int, /* qop_req */
gss_buffer_t, /* message_buffer */
gss_buffer_t /* message_token */
);
OM_uint32 FAR PASCAL gss_verify
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t, /* message_buffer */
gss_buffer_t, /* token_buffer */
int FAR * /* qop_state */
);
OM_uint32 FAR PASCAL gss_seal
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
int, /* conf_req_flag */
int, /* qop_req */
gss_buffer_t, /* input_message_buffer */
int FAR *, /* conf_state */
gss_buffer_t /* output_message_buffer */
);
OM_uint32 FAR PASCAL gss_unseal
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
gss_buffer_t, /* input_message_buffer */
gss_buffer_t, /* output_message_buffer */
int FAR *, /* conf_state */
int FAR * /* qop_state */
);
OM_uint32 FAR PASCAL gss_indicate_mechs
(OM_uint32 FAR *, /* minor_status */
gss_OID_set FAR * /* mech_set */
);
OM_uint32 FAR PASCAL gss_compare_name
(OM_uint32 FAR *, /* minor_status */
gss_name_t, /* name 1 */
gss_name_t, /* name 2 */
int FAR * /* name equal */
);
OM_uint32 FAR PASCAL gss_display_name
(OM_uint32 FAR *, /* minor_status */
gss_name_t, /* input_name */
gss_buffer_t, /* output_name_buffer */
gss_OID FAR * /* output_name_type */
);
OM_uint32 FAR PASCAL gss_import_name
(OM_uint32 FAR *, /* minor_status */
gss_buffer_t, /* input_name_buffer */
gss_OID, /* input_name_type */
gss_name_t FAR * /* output_name */
);
OM_uint32 FAR PASCAL gss_release_name
(OM_uint32 FAR *, /* minor_status */
gss_name_t FAR * /* name */
);
OM_uint32 FAR PASCAL gss_display_status
(OM_uint32 FAR *, /* minor_status */
int, /* status_value */
int, /* status_type */
gss_OID, /* mech_type */
int FAR *, /* message_context */
gss_buffer_t /* status_string */
);
OM_uint32 FAR PASCAL gss_context_time
(OM_uint32 FAR *, /* minor_status */
gss_ctx_id_t, /* context_handle */
OM_uint32 FAR * /* time_rec */
);
OM_uint32 FAR PASCAL gss_release_buffer
(OM_uint32 FAR *, /* minor_status */
gss_buffer_t /* buffer */
);
OM_uint32 FAR PASCAL gss_release_oid_set
(OM_uint32 FAR *, /* minor_status */
gss_OID_set FAR * /* set */
);
OM_uint32 FAR PASCAL gss_inquire_cred
(OM_uint32 FAR *, /* minor_status */
gss_cred_id_t, /* cred_handle */
gss_name_t FAR *, /* name */
OM_uint32 FAR *, /* lifetime */
int FAR *, /* cred_usage */
gss_OID_set FAR * /* mechanisms */
);
Informative Annex 3 - Type Declarations
For RFC 1509, the following are the types for the GSS-API DLL as
would be declared in <gssapi.h>.
typedef struct gss_OID_desc_struct {
OM_uint32 length;
VOID FAR *elements;
} gss_OID_desc, FAR *gss_OID;
typedef struct gss_OID_set_desc_struct {
int count;
gss_OID elements;
} gss_OID_set_desc, FAR *gss_OID_set;
typedef struct gss_buffer_desc_struct {
size_t length;
VOID FAR *value;
} gss_buffer_desc, FAR *gss_buffer_t;
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} gss_channel_bindings_desc, FAR *gss_channel_bindings_t;
-------------------------------------------------------
P V McMahon 16AUG94
ICL Enterprises
post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: p.v.mcmahon at rea0803.wins.icl.co.uk
OR p.mcmahon at xopen.co.uk
phone: +44 734 634882
fax: +44 734 855106
-------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13456;
16 Aug 94 20:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13448;
16 Aug 94 20:35 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa19777;
16 Aug 94 20:35 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <UAA02760 at pad-thai.aktis.com>; Tue, 16 Aug 1994 20:19:38 -0400
Received: from netmail2.microsoft.com by MIT.EDU with SMTP
id AA08845; Tue, 16 Aug 94 20:18:08 EDT
Received: by netmail2.microsoft.com (5.65/25-eef)
id AA14206; Tue, 16 Aug 94 17:18:54 -0700
Message-Id: <9408170018.AA14206 at netmail2.microsoft.com>
Received: by netmail2 using fxenixd 1.0 Tue, 16 Aug 94 17:18:53 PDT
X-Msmail-Message-Id: 4F2F42A0
X-Msmail-Conversation-Id: 4F2F42A0
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Ludeman <johnl at microsoft.com>
To: cat-ietf at mit.edu
Date: Tue, 16 Aug 94 17:13:49 TZ
Subject: RE: draft GSS-API MS Windows DLL interface spec
----------
| From: <p.v.mcmahon.rea0803 at oasis.icl.co.uk>
| To: <cat-ietf at mit.edu>
| Subject: draft GSS-API MS Windows DLL interface spec
| Date: Tuesday, August 16, 1994 8:10PM
|
[...]
|
| 4. Scope
|
| The interface is defined to be suitable for MS Windows 3.1 and
| beyond (i.e.: a Win32 environment isn't assumed)
|
| This interface specification is, in conjunction with the C
| Bindings, sufficiently detailed such that binary user applications
| can link, unchanged, with different providers' GSS-API Dynamic
| Link Libraries.
Later on in the document, you stipulate the dll name should be
GSSAPI.DLL. I would suggest avoiding a hard coded dll name as that
will present interop problems with other vendors. Specifically, a
single application (like a Web viewer say...) may want to use one
security provider for authentication and another for signing and
perhaps a third for encryption. The application would simultaneously
have entry points from all three dlls loaded. I assume you are not
proposing a routing mechanism among security providers.
[...]
|
| 5.2 Pointers
|
| As the GSS-API library is provided in a DLL, all references passed
| to it from calling applications must be declared FAR.
|
| This applies to all parts of the interfaces - both entry points
| and data structures.
I think it would be appropriate to mention on a Win32 system, FAR is
#defined away and all pointers are 32 bit flat model.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14245;
16 Aug 94 22:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14237;
16 Aug 94 22:23 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa21649;
16 Aug 94 22:23 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <VAA04236 at pad-thai.aktis.com>; Tue, 16 Aug 1994 21:55:54 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA12560; Tue, 16 Aug 94 21:54:28 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <21758-0 at relay1.pipex.net>; Wed, 17 Aug 1994 02:54:17 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA00599; Wed, 17 Aug 94 02:56:16 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA01308;
Wed, 17 Aug 94 02:53:30 BST
Message-Id: <9408170155.AA11682 at getafix.oasis.icl.co.uk>
Date: Wed, 17 Aug 94 02:55:39 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: draft GSS-API MS Windows DLL interface spec
To: johnl at microsoft.com
Cc: cat-ietf at mit.edu
Priority: URGENT
Thanks for the comments.
> Later on in the document, you stipulate the dll name should be
> GSSAPI.DLL. I would suggest avoiding a hard coded dll name as that
> will present interop problems with other vendors. Specifically, a
The intent of specifying a DLL interface is to enable application writers
to develop *shrink-wrapped binaries* which depend on a set of services
to be delivered by a separately-provided security mechanism (in the
same way as such applications can be made to be dependent on a WINSOCK
DLL and different WINSOCKs can be used with the same application
binary).
Leaving the choice of library name undefined seems (to me) to defeat
*that* purpose - so can you show me how an application can
be linked without specifying the import library, or explicit IMPORTS
statements?
> single application (like a Web viewer say...) may want to use one
> security provider for authentication and another for signing and
> perhaps a third for encryption. The application would simultaneously
> have entry points from all three dlls loaded. I assume you are not
> proposing a routing mechanism among security providers.
The requirement you mention with multiple instantiations of the GSS-API
providing different different services is:
(a) apparently inconsistent with defining a standard for development
of binary applications dependent on a GSSAPI DLL facility - although
I am willing to be corrected on that (see above),
(b) not one which I guess will be the norm as it requires what are
currently undefined interfaces to enable such multi-vendor
interworking, [if they're that closely linked, why not have one
DLL?]
(c) non-inconsistent with a single library which makes routing calls
out to different libraries.
If you can show me how we can meet (a) AND have multiple libraries,
then fine - else I would suggest that we just add some text to say that
applications can elect to consume GSS-API services in an implementation
specific manner from as many different libraries as they choose at link
time, but here is a standard which portable applications can
adhere to ...
> I think it would be appropriate to mention on a Win32 system, FAR is
> #defined away and all pointers are 32 bit flat model.
Ok.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17615;
16 Aug 94 23:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17605;
16 Aug 94 23:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22301;
16 Aug 94 23:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17594;
16 Aug 94 23:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17553;
16 Aug 94 23:02 EDT
Received: from tipper.oit.unc.edu by CNRI.Reston.VA.US id aa22239;
16 Aug 94 23:02 EDT
Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA22649; Tue, 16 Aug 94 23:02:42 EDT
Message-Id: <9408170302.AA22649 at tipper.oit.unc.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Session layer/Middle ware
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 16 Aug 94 23:02:42 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Does anybody have any notes on the IMA bof at the Toronto IETF? There don't
seem to be any minutes in the online archives.
The reason I ask is that I've been working on a nano-weight session layer (SCP)
for use with Fast HTTP, and the stuff I've come up with seems like it would be
useful for more than just one application. The services the protocol provides
are basically just multiplexing a single transport connection and being able
to mark data boundaries. SCP is less feature rich than OSI session but does
have the advantage of fitting on a single side of A4.
When people design protocols, they tend to use the tools available to them;
when the only tool available above the datagram level is TCP, TCP gets coerced
into doing things it's not designed for. For an example of how this effect
applies to existing protocols see <http://elanor.oit.unc.edu/http-prob.html>
(Analysis of HTTP/1.0 performance problems).
There are several obvious protocols that would benefit from the ability to have
multiple concurrent dialogues occuring over the same connection, as well as
the ability to serially reuse a connection; FTP, HTTP, and GOPHER would each
have been much more efficient if they reused existing connections instead of
using TCP to indicate end-of-file. IMAP would be less confusing if the results
from different operations were cleanly separated. SMTP would benefit from being
able to tell where a message ends, instead of using the kids-in-the-backseat
model of scanning every byte looking for an end-of-message sequence
("Are we there yet?" "Are we there yet?").
With IPNG poised for deployment over the next few years there's a golden
opportunity to piggyback that deployment to make it easier to write efficient
protocols.
Is it time to take another look at an applications architecture in the lands
beyond transport? If not us, who? If not now, when?
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22083;
17 Aug 94 1:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22073;
17 Aug 94 1:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24097;
17 Aug 94 1:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22063;
17 Aug 94 1:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22035;
17 Aug 94 1:11 EDT
Received: from Valinor.Stanford.EDU by CNRI.Reston.VA.US id aa24073;
17 Aug 94 1:11 EDT
Received: (from vaf at localhost) by Valinor.Stanford.EDU (8.6.8/8.6.6) id WAA16459; Tue, 16 Aug 1994 22:14:38 -0700
Date: Tue, 16 Aug 94 22:14:38 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.stanford.edu>
To: Simon E Spero <ses at tipper.oit.unc.edu>
Cc: ietf at CNRI.Reston.VA.US
Office: Spruce Hall F15, (415) 723-6860
USMail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: Session layer/Middle ware
In-Reply-To: Your message of Tue, 16 Aug 94 23:02:42 -0400
Message-ID: <CMM.0.90.2.777100478.vaf at Valinor.Stanford.EDU>
With IPNG poised for deployment over the next few years there's a golden
opportunity to piggyback that deployment to make it easier to write
efficient protocols.
Given a world where endpoint IDs and addresses continue to be confused (i.e.
IPv6 as currentl specified), it also might be possible to use the session
layer to hide underlying address changes. With the right functionality, the
session layer could automatically re-establish TCP connections when addresses
change, without applications needing to know that a connection was broken.
Something to consider?
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22332;
17 Aug 94 1:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22322;
17 Aug 94 1:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24632;
17 Aug 94 1:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22313;
17 Aug 94 1:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22287;
17 Aug 94 1:55 EDT
Received: from tipper.oit.unc.edu by CNRI.Reston.VA.US id aa24608;
17 Aug 94 1:55 EDT
Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA22937; Wed, 17 Aug 94 01:56:07 EDT
Message-Id: <9408170556.AA22937 at tipper.oit.unc.edu>
To: Vince Fuller <vaf at valinor.stanford.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Session layer/Middle ware
In-Reply-To: Your message of "Tue, 16 Aug 94 22:14:38 PDT."
<CMM.0.90.2.777100478.vaf at Valinor.Stanford.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 17 Aug 94 01:56:07 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Vince Fuller <vaf at valinor.stanford.edu> writes:
>
>Given a world where endpoint IDs and addresses continue to be confused (i.e.
>IPv6 as currentl specified), it also might be possible to use the session
>layer to hide underlying address changes. With the right functionality, the
>session layer could automatically re-establish TCP connections when addresses
>change, without applications needing to know that a connection was broken.
>
>Something to consider?
[I'm sticking a draft copy of the SCP header format at the end of the
message. comments/flames/mox emeralds gratefully received]
This functionality can be wrapped around SCP without too much difficulty-
I'm not sure if this is really the right place to solve this problem, but the
end result is only slightly ugly :-)
SCP reserves the first 1024 session ids for use as virtual well known ports.
This will allow things like simple presentation negotiation to be added later
to transparently support things like encrypted or gzipped data streams.
Endpoint lossage avoidance can be supported by allocating one of these
reserved sessions as a channel to exchange long-life UHT_ids. If the
connection dies, client can re-resolve the hostname and create a new
transport connection, re-authenticate itself, then send its UHT_id and ask
to be reconnected to its established sessions.
Implementation is quite trivial on the client side, and not too hard for
multi-threaded servers; however it takes a bit more work to make this fly for
servers which create a separate heavyweight process for each connection. The
real problem is deciding when to discard the state for the disconnected
sessions.
Simon
--------------------
Session Control Protocol (SCP)
------------------------------
SCP is a simple protocol which lets a server and client have multiple
conversations over a single TCP connection. The protocol is designed to be
simple to implement, and is modelled after TCP.
Services.
---------
SCP's main service is dialogue control. This service allows either end of the
connection to establish a virtual session over a single transport connection.
SCP also allows a sender to indicate message boundaries, and allows a reciever
to reject an incoming session.
Design goals.
-------------
o Unconfirmed service without negotiation.
SCP allows data to be sent with the session establishment; the
recepient does not confirm successful connection establishment, but
may reject unsuccessful attempts. This simplifies the design of the
protocol, and removes the latency required for a confirmed operation.
o Low overhead
SCP has a fixed overhead of 8 bytes per segment. This overhead is
half the size of an IPNG address, and is only incurred once per
segment, instead of once per packet.
o Simple design
The session protocol should be simple enough to implement for a
single application.
Protocol Description
Header Format:
--------------
32 24 16 8 0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|S|F|R|P| SESSION ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEGMENT LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DATA .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S = SYN F = FIN R = RST P = PUSH
Protocol Operation:
-------------------
Session ID allocation.
Each session is allocated a session identifier. Session Identifiers below
1024 are reserved. Session IDs allocated by clients are even; those allocated
by servers, odd. Unexpected connections to a reserved port MUST be rejected.
Session establishment.
A session is established by setting the SYN bit in the first message sent on
that channel.
Graceful release.
A session is ended by sending a message with the FIN bit set. Each end of a
connection may be closed independently.
Disgraceful release.
A session may be terminated by sending a message with the RST bit set. All
pending data for that session should be discarded
Message boundaries.
A message boundary is marked by sending a message with the PUSH bit set. The
boundary is set at the final octet in this message, including that octet.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01663;
17 Aug 94 7:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01653;
17 Aug 94 7:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03124;
17 Aug 94 7:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01631;
17 Aug 94 7:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01522;
17 Aug 94 6:47 EDT
Received: from sun2.mhs-relay.ac.uk by CNRI.Reston.VA.US id aa02950;
17 Aug 94 6:47 EDT
Via: uk.ac.ulcc.pluto; Wed, 17 Aug 1994 11:48:04 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Peter Furniss <cziwprf at pluto.ulcc.ac.uk>
Message-Id: <15188.199408171047 at pluto.ulcc.ac.uk>
Subject: Re: Session layer/Middle ware
To: Simon E Spero <ses at tipper.oit.unc.edu>
Date: Wed, 17 Aug 1994 11:47:30 +0100 (BST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9408170302.AA22649 at tipper.oit.unc.edu> from "Simon E Spero" at Aug 16, 94 11:02:42 pm
Reply-to: P.Furniss at ulcc.ac.uk
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1667
Simon,
Your proposals look *extremely* interesting in the light of two bits
of work (which have some relation) that are currently active in OSI
(and were a major topic at the SC21 meeting in Southampton last
month). There may be a real opportunity for cooperation here.
As you say, what you are proposing is a lightweight protocol to
achieve some of the functions that are offered by the OSI "supporting
upper-layers" (Session, Presentation, ACSE). One of the projects is
investigating ways of making these upper-layer protocols more
efficient (especially in bandwidth) - several ideas are around. At
least some of the proposals would make sense as "middle protocol" over
TCP, without incurring the overheads that OSI now implies. We could
end up removing the distinction between the "OSI environment" and the
"TCP/IP environment" that an application protocol inventor perceives,
without imposing costs.
The other project is extensions to ACSE to allow it to do something
very similar to the multiplexing you are proposing. (This is all
wrapped up in architectural terminology, but it amounts to the same
thing)
There is considerable desire to move both these aspects on very
rapidly (more rapidly than the ISO procedures can really handle
probably). An email list is being set up for the efficiency work -
lots of people really like the ietf approach :-)
Peter Furniss
PS curiously, the features you propose are not those provided by the
OSI session layer. They are mostly in Presentation protocol, which
also allows the identification and negotiation (but not the
transformation to/from) of the message formats - which is something
you might want to add.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03021;
17 Aug 94 8:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03011;
17 Aug 94 8:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04973;
17 Aug 94 8:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02992;
17 Aug 94 8:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02837;
17 Aug 94 8:47 EDT
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa04797;
17 Aug 94 8:47 EDT
Received: by ginger.lcs.mit.edu
id AA05930; Wed, 17 Aug 94 08:47:35 -0400
Date: Wed, 17 Aug 94 08:47:35 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9408171247.AA05930 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Session layer/Middle ware
Cc: jnc at ginger.lcs.mit.edu
From: Vince Fuller <vaf at valinor.stanford.edu>
Given a world where endpoint IDs and addresses continue to be confused
... it also might be possible to use the session layer to hide underlying
address changes. With the right functionality, the session layer could
automatically re-establish TCP connections when addresses change, without
applications needing to know that a connection was broken.
This isn't the optimal place to hide this binding, since you'd have to redo
this functionality for each transport layer; for applications which don't use
a transport layer you'd have to redo it for each one. It also means redoing
current TCP based applications if this kind of mobility is to be supported in
them. So, I don't know if this is better than nothing...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03178;
17 Aug 94 8:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03170;
17 Aug 94 8:54 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05059;
17 Aug 94 8:54 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA14065 at pad-thai.aktis.com>; Wed, 17 Aug 1994 08:33:22 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA27918; Wed, 17 Aug 94 08:31:51 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <15819-0 at relay1.pipex.net>; Wed, 17 Aug 1994 13:31:06 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA07717; Wed, 17 Aug 94 13:32:43 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA08230;
Wed, 17 Aug 94 13:29:58 BST
Message-Id: <9408171232.AA15387 at getafix.oasis.icl.co.uk>
Date: Wed, 17 Aug 94 13:32:05 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: draft GSS-API MS Windows DLL interface spec
To: cat-ietf at mit.edu
It has been suggested to me by private email that the Winsockets convention
for ordinals be used - such that standard APIs are defined within a certain
range, and implementation-specific APIs are allowed above that range for use
by non-portable applications.
If accepted, this would mean the following changes:
> 5.5 Entry-point Ordinals
> Ordinals for the GSS-API are therefore defined starting from 1,
> and are assigned to entry points in the order they are given in
> the Standards Track C Bindings.
Add:
Ordinals between 1 and 1000 are reserved for Standards Track GSS-API
interfaces.
> 6. Extensions
>
> Extensions to GSS-API may be defined in future revisions of the
> Standards Track GSS-API C Bindings.
>
Change:
> GSS-API extensions from other sources should be provided in
> separate DLLs.
to
GSS-API extensions from other sources may be provided in
separate DLLs, or as entry points in GSSAPI.DLL with ordinal
values greater than 1000.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04958;
17 Aug 94 10:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04948;
17 Aug 94 10:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07136;
17 Aug 94 10:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04939;
17 Aug 94 10:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04815;
17 Aug 94 10:25 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa07072;
17 Aug 94 10:25 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA28049 (mail destined for ietf at CNRI.Reston.VA.US) on Wed, 17 Aug 94 10:25:17 -0400
Date: Wed, 17 Aug 94 10:25:17 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chris Weider <clw at mocha.bunyip.com>
Message-Id: <9408171425.AA28049 at mocha.bunyip.com>
To: ietf at CNRI.Reston.VA.US, ses at tipper.oit.unc.edu
Subject: Re: Session layer/Middle ware
Simon:
You've brought up a number of really good points here. I think it is
time to start looking at this, especially since we're trying to develop
a common architecture for a general integrated information framework.
If we can beef up transport to make facets of this architecture easier to\
implement (particularly retrieval) I think that that would be a Good Thing
Chris
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07000;
17 Aug 94 11:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09152;
17 Aug 94 11:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06982;
17 Aug 94 11:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06826;
17 Aug 94 11:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sundroof.eng.sun.com, ospf at gated.cornell.edu, snmp at psi.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-mcdonald-readable-keys-00.txt
Date: Wed, 17 Aug 94 11:36:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408171136.aa06826 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Convention for Human-Readable 128-bit Keys
Author(s) : D. McDonald
Filename : draft-mcdonald-readable-keys-00.txt
Pages : 15
Date : 08/16/1994
With the emergence of keyed MD5 as a common Internet authentication
mechanism, 128-bit keys are becoming common. This draft proposes a
convention for representing 128-bit keys in a string of 12 small English
words.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-mcdonald-readable-keys-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mcdonald-readable-keys-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940816151252.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-mcdonald-readable-keys-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mcdonald-readable-keys-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940816151252.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07000;
17 Aug 94 11:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09152;
17 Aug 94 11:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06982;
17 Aug 94 11:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06826;
17 Aug 94 11:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sundroof.eng.sun.com, ospf at gated.cornell.edu, snmp at psi.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-mcdonald-readable-keys-00.txt
Date: Wed, 17 Aug 94 11:36:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408171136.aa06826 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Convention for Human-Readable 128-bit Keys
Author(s) : D. McDonald
Filename : draft-mcdonald-readable-keys-00.txt
Pages : 15
Date : 08/16/1994
With the emergence of keyed MD5 as a common Internet authentication
mechanism, 128-bit keys are becoming common. This draft proposes a
convention for representing 128-bit keys in a string of 12 small English
words.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-mcdonald-readable-keys-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mcdonald-readable-keys-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940816151252.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-mcdonald-readable-keys-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mcdonald-readable-keys-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940816151252.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07015;
17 Aug 94 11:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07000;
17 Aug 94 11:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09152;
17 Aug 94 11:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06982;
17 Aug 94 11:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06826;
17 Aug 94 11:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sundroof.eng.sun.com, ospf at gated.cornell.edu, snmp at psi.com
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-mcdonald-readable-keys-00.txt
Date: Wed, 17 Aug 94 11:36:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408171136.aa06826 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Convention for Human-Readable 128-bit Keys
Author(s) : D. McDonald
Filename : draft-mcdonald-readable-keys-00.txt
Pages : 15
Date : 08/16/1994
With the emergence of keyed MD5 as a common Internet authentication
mechanism, 128-bit keys are becoming common. This draft proposes a
convention for representing 128-bit keys in a string of 12 small English
words.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-mcdonald-readable-keys-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-mcdonald-readable-keys-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940816151252.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-mcdonald-readable-keys-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-mcdonald-readable-keys-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940816151252.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09546;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11718;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09500;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09271;
17 Aug 94 13:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11431;
17 Aug 94 13:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22489>; Wed, 17 Aug 1994 10:32:57 -0700
Message-Id: <199408171732.AA22489 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1690 on The Internet Engineering and Planning Group
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:33:27 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1690:
Title: Introducing the Internet Engineering
and Planning Group (IEPG)
Author: G. Huston
Mailbox: Geoff.Huston at aarnet.edu.au
Pages: 2
Characters: 3,013
Updates/Obsoletes: none
This memo introduces the IEPG to the Internet Community. The IEPG is
an Internet Service Operators' forum, intended to assist Service
Operators to coordinate in operational aspects of managing Internet
services.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103136.RFC at ISI.EDU>
SEND /rfc/rfc1690.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1690.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103136.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09546;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11718;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09500;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09271;
17 Aug 94 13:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11431;
17 Aug 94 13:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22489>; Wed, 17 Aug 1994 10:32:57 -0700
Message-Id: <199408171732.AA22489 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1690 on The Internet Engineering and Planning Group
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:33:27 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1690:
Title: Introducing the Internet Engineering
and Planning Group (IEPG)
Author: G. Huston
Mailbox: Geoff.Huston at aarnet.edu.au
Pages: 2
Characters: 3,013
Updates/Obsoletes: none
This memo introduces the IEPG to the Internet Community. The IEPG is
an Internet Service Operators' forum, intended to assist Service
Operators to coordinate in operational aspects of managing Internet
services.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103136.RFC at ISI.EDU>
SEND /rfc/rfc1690.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1690.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103136.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09547;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11717;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09497;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09407;
17 Aug 94 13:41 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11611;
17 Aug 94 13:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22723>; Wed, 17 Aug 1994 10:41:18 -0700
Message-Id: <199408171741.AA22723 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1692 on TMux
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:41:47 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1692:
Title: Transport Multiplexing Protocol (TMux)
Author: P. Cameron, D. Crocker, D. Cohen & J. Postel
Mailbox: cameron at xylint.co.uk, dcrocker at sgi.com,
Cohen at myricom.com, Postel at ISI.EDU
Pages: 12
Characters: 26,163
Updates/Obsoletes: none
One of the problems with the use of terminal servers is the large
number of small packets they can generate. Frequently, most of these
packets are destined for only one or two hosts. TMux is a protocol
which allows multiple short transport segments, independent of
application type, to be combined between a server and host pair. This
RFC is not a product of an IETF Working Group, but has been reviewed
in the Transport Area of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103846.RFC at ISI.EDU>
SEND /rfc/rfc1692.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1692.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103846.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09547;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11717;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09497;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09407;
17 Aug 94 13:41 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11611;
17 Aug 94 13:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22723>; Wed, 17 Aug 1994 10:41:18 -0700
Message-Id: <199408171741.AA22723 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1692 on TMux
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:41:47 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1692:
Title: Transport Multiplexing Protocol (TMux)
Author: P. Cameron, D. Crocker, D. Cohen & J. Postel
Mailbox: cameron at xylint.co.uk, dcrocker at sgi.com,
Cohen at myricom.com, Postel at ISI.EDU
Pages: 12
Characters: 26,163
Updates/Obsoletes: none
One of the problems with the use of terminal servers is the large
number of small packets they can generate. Frequently, most of these
packets are destined for only one or two hosts. TMux is a protocol
which allows multiple short transport segments, independent of
application type, to be combined between a server and host pair. This
RFC is not a product of an IETF Working Group, but has been reviewed
in the Transport Area of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103846.RFC at ISI.EDU>
SEND /rfc/rfc1692.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1692.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103846.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09550;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11720;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09502;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09301;
17 Aug 94 13:36 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11507;
17 Aug 94 13:36 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22644>; Wed, 17 Aug 1994 10:36:47 -0700
Message-Id: <199408171736.AA22644 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1691 on CDL Document Architecture
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:37:16 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1691:
Title: The Document Architecture for the Cornell Digital
Library (CDL)
Author: W. Turner
Mailbox: wrt1 at cornell.edu
Pages: 10
Characters: 20,438
Updates/Obsoletes: none
This memo describes an architecture for the storage and retrieval of
the digital representations for books, journals, photographic images,
etc., which are collected in a large organized digital library. Two
unique features of this architecture are the ability to generate
reference documents and the ability to create multiple views of a
document.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103455.RFC at ISI.EDU>
SEND /rfc/rfc1691.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1691.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103455.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09550;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11720;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09502;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09301;
17 Aug 94 13:36 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11507;
17 Aug 94 13:36 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22644>; Wed, 17 Aug 1994 10:36:47 -0700
Message-Id: <199408171736.AA22644 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1691 on CDL Document Architecture
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:37:16 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1691:
Title: The Document Architecture for the Cornell Digital
Library (CDL)
Author: W. Turner
Mailbox: wrt1 at cornell.edu
Pages: 10
Characters: 20,438
Updates/Obsoletes: none
This memo describes an architecture for the storage and retrieval of
the digital representations for books, journals, photographic images,
etc., which are collected in a large organized digital library. Two
unique features of this architecture are the ability to generate
reference documents and the ability to create multiple views of a
document.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103455.RFC at ISI.EDU>
SEND /rfc/rfc1691.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1691.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103455.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09551;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11721;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09498;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09172;
17 Aug 94 13:28 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11350;
17 Aug 94 13:28 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22358>; Wed, 17 Aug 1994 10:29:10 -0700
Message-Id: <199408171729.AA22358 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1689, RTR13, FYI25 on Networked Information Retrieval:
Tools and Groups
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:29:39 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1689:
RTR 13:
FYI 25:
Title: A Status Report on Networked Information
Retrieval: Tools and Groups
Author: J. Foster, Editor
Mailbox: Jill.Foster at newcastle.ac.uk
Pages: 226
Characters: 375,469
Updates/Obsoletes: none
The purpose of this report is to increase the awareness of Networked
Information Retrieval by bringing together in one place information
about the various networked information retrieval tools, their
developers, interested organisations, and other activities that relate
to the production, dissemination, and support of NIR tools. NIR Tools
covered include Archie, WAIS, gopher and World Wide Web. This RFC is
a collaborative effort by the Joint IETF/RARE/CNI Networked
Information Retrieval Working Group (NIR-WG).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817102553.RFC at ISI.EDU>
SEND /rfc/rfc1689.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1689.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817102553.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09551;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11721;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09498;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09172;
17 Aug 94 13:28 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11350;
17 Aug 94 13:28 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22358>; Wed, 17 Aug 1994 10:29:10 -0700
Message-Id: <199408171729.AA22358 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1689, RTR13, FYI25 on Networked Information Retrieval:
Tools and Groups
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:29:39 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1689:
RTR 13:
FYI 25:
Title: A Status Report on Networked Information
Retrieval: Tools and Groups
Author: J. Foster, Editor
Mailbox: Jill.Foster at newcastle.ac.uk
Pages: 226
Characters: 375,469
Updates/Obsoletes: none
The purpose of this report is to increase the awareness of Networked
Information Retrieval by bringing together in one place information
about the various networked information retrieval tools, their
developers, interested organisations, and other activities that relate
to the production, dissemination, and support of NIR tools. NIR Tools
covered include Archie, WAIS, gopher and World Wide Web. This RFC is
a collaborative effort by the Joint IETF/RARE/CNI Networked
Information Retrieval Working Group (NIR-WG).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817102553.RFC at ISI.EDU>
SEND /rfc/rfc1689.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1689.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817102553.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09580;
17 Aug 94 13:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09546;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11718;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09500;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09271;
17 Aug 94 13:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11431;
17 Aug 94 13:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22489>; Wed, 17 Aug 1994 10:32:57 -0700
Message-Id: <199408171732.AA22489 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1690 on The Internet Engineering and Planning Group
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:33:27 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1690:
Title: Introducing the Internet Engineering
and Planning Group (IEPG)
Author: G. Huston
Mailbox: Geoff.Huston at aarnet.edu.au
Pages: 2
Characters: 3,013
Updates/Obsoletes: none
This memo introduces the IEPG to the Internet Community. The IEPG is
an Internet Service Operators' forum, intended to assist Service
Operators to coordinate in operational aspects of managing Internet
services.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103136.RFC at ISI.EDU>
SEND /rfc/rfc1690.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1690.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103136.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09584;
17 Aug 94 13:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09547;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11717;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09497;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09407;
17 Aug 94 13:41 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11611;
17 Aug 94 13:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22723>; Wed, 17 Aug 1994 10:41:18 -0700
Message-Id: <199408171741.AA22723 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1692 on TMux
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:41:47 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1692:
Title: Transport Multiplexing Protocol (TMux)
Author: P. Cameron, D. Crocker, D. Cohen & J. Postel
Mailbox: cameron at xylint.co.uk, dcrocker at sgi.com,
Cohen at myricom.com, Postel at ISI.EDU
Pages: 12
Characters: 26,163
Updates/Obsoletes: none
One of the problems with the use of terminal servers is the large
number of small packets they can generate. Frequently, most of these
packets are destined for only one or two hosts. TMux is a protocol
which allows multiple short transport segments, independent of
application type, to be combined between a server and host pair. This
RFC is not a product of an IETF Working Group, but has been reviewed
in the Transport Area of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103846.RFC at ISI.EDU>
SEND /rfc/rfc1692.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1692.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103846.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09596;
17 Aug 94 13:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09551;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11721;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09498;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09172;
17 Aug 94 13:28 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11350;
17 Aug 94 13:28 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22358>; Wed, 17 Aug 1994 10:29:10 -0700
Message-Id: <199408171729.AA22358 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1689, RTR13, FYI25 on Networked Information Retrieval:
Tools and Groups
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:29:39 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1689:
RTR 13:
FYI 25:
Title: A Status Report on Networked Information
Retrieval: Tools and Groups
Author: J. Foster, Editor
Mailbox: Jill.Foster at newcastle.ac.uk
Pages: 226
Characters: 375,469
Updates/Obsoletes: none
The purpose of this report is to increase the awareness of Networked
Information Retrieval by bringing together in one place information
about the various networked information retrieval tools, their
developers, interested organisations, and other activities that relate
to the production, dissemination, and support of NIR tools. NIR Tools
covered include Archie, WAIS, gopher and World Wide Web. This RFC is
a collaborative effort by the Joint IETF/RARE/CNI Networked
Information Retrieval Working Group (NIR-WG).
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817102553.RFC at ISI.EDU>
SEND /rfc/rfc1689.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1689.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817102553.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09597;
17 Aug 94 13:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09550;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11720;
17 Aug 94 13:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09502;
17 Aug 94 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09301;
17 Aug 94 13:36 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11507;
17 Aug 94 13:36 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA22644>; Wed, 17 Aug 1994 10:36:47 -0700
Message-Id: <199408171736.AA22644 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1691 on CDL Document Architecture
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 17 Aug 94 10:37:16 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1691:
Title: The Document Architecture for the Cornell Digital
Library (CDL)
Author: W. Turner
Mailbox: wrt1 at cornell.edu
Pages: 10
Characters: 20,438
Updates/Obsoletes: none
This memo describes an architecture for the storage and retrieval of
the digital representations for books, journals, photographic images,
etc., which are collected in a large organized digital library. Two
unique features of this architecture are the ability to generate
reference documents and the ability to create multiple views of a
document.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940817103455.RFC at ISI.EDU>
SEND /rfc/rfc1691.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1691.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940817103455.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09872;
17 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12035;
17 Aug 94 13:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09854;
17 Aug 94 13:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09765;
17 Aug 94 13:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11981;
17 Aug 94 13:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09760;
17 Aug 94 13:52 EDT
To: IETF-Anounce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: Networked Information Retrieval (nir) to Conclude
Date: Wed, 17 Aug 94 13:52:44 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408171352.aa09760 at IETF.CNRI.Reston.VA.US>
With the publication of "A Status Report on Networked Information
Retrieval: Tools and Groups" (RFC 1689/RTR 13/FYI 25), the
Networked Information Retrieval Working Group of the User Services
Area of the IETF has concluded. The mailing list will remain
active. The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10375;
17 Aug 94 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10367;
17 Aug 94 14:18 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa12462;
17 Aug 94 14:18 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <NAA20488 at pad-thai.aktis.com>; Wed, 17 Aug 1994 13:57:48 -0400
Received: from netmail2.microsoft.com by MIT.EDU with SMTP
id AA20394; Wed, 17 Aug 94 13:56:13 EDT
Received: by netmail2.microsoft.com (5.65/25-eef)
id AA03320; Wed, 17 Aug 94 10:56:59 -0700
Message-Id: <9408171756.AA03320 at netmail2.microsoft.com>
Received: by netmail2 using fxenixd 1.0 Wed, 17 Aug 94 10:56:59 PDT
X-Msmail-Message-Id: 39A66E74
X-Msmail-Conversation-Id: 39A66E74
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Ludeman <johnl at microsoft.com>
To: cat-ietf at mit.edu
Date: Wed, 17 Aug 94 10:51:31 TZ
Subject: RE: draft GSS-API MS Windows DLL interface spec
Even though the topic is based on Windows, I feel the underlying issues
apply to all platforms. Having a portable shared library or dynamic
library approach can help establish the GSS-API in the mainstream and
ease the burden on the developers trying to keep up with the new
authentication/encryption/signing schemes that are coming down the pipe.
Comments within...
----------
| From: <p.v.mcmahon.rea0803 at oasis.icl.co.uk>
| To: John Ludeman
| Cc: <cat-ietf at mit.edu>
| Subject: RE: draft GSS-API MS Windows DLL interface spec
| Date: Wednesday, August 17, 1994 2:55AM
|
| Thanks for the comments.
|
| > Later on in the document, you stipulate the dll name should be
| > GSSAPI.DLL. I would suggest avoiding a hard coded dll name as that
| > will present interop problems with other vendors. Specifically, a
|
| The intent of specifying a DLL interface is to enable application writers
| to develop *shrink-wrapped binaries* which depend on a set of services
| to be delivered by a separately-provided security mechanism (in the
| same way as such applications can be made to be dependent on a WINSOCK
| DLL and different WINSOCKs can be used with the same application
| binary).
Yes. Absolutely. Definately.
|
| Leaving the choice of library name undefined seems (to me) to defeat
| *that* purpose - so can you show me how an application can
| be linked without specifying the import library, or explicit IMPORTS
| statements?
There are three ways to go here:
1) Allow only a single vendor's non-routing GSSAPI.DLL on the system.
The problems with this approach is the user may deal with multiple
packages or external resources that require different security schemes.
A common case might be a user that has one gss dll for their local
network and another gss dll for their favorite Internet resource (or
pluggable payment systems for various network services).
2) Allow multiple gss dlls (GSSRSA.DLL, GSSMD5.DLL, GSSVISA.DLL). The
drawbacks here is that an application has to be told which GSS modules
are available to it (user or setup program tells app use these three
DLLs). The application also has to route to the appropriate dll based
on what action is being performed (authentication, encryption etc.) in
addition to having to choose the particular mechtype. There are some
tricks to help the user select newly installed dlls (dll names must
begin with gss, define an entry point like "gss_get_api_info" etc. or
put registration information in a well known location (under windows
add a gssapi.ini file or a [GSSAPI] section to win.ini)).
3) Have a single GSSAPI.DLL that routes (ala Winsock). This is the
Nirvana of security APIs. If this is what you are proposing than I
apologize as I didn't see the related infrastructure detail that goes
along with this option (mechtype coalescing, vendor registration etc.).
I see some problems wrt the API spec that would cause problems for
routing (mostly "who to route to" problems).
What you have defined is good and appropriate. I do believe it is a
requirement that multiple vendor's GSS dlls can be used simultaneously
(either through option 2 or option 3).
|
| > single application (like a Web viewer say...) may want to use one
| > security provider for authentication and another for signing and
| > perhaps a third for encryption. The application would simultaneously
| > have entry points from all three dlls loaded. I assume you are not
| > proposing a routing mechanism among security providers.
|
| The requirement you mention with multiple instantiations of the GSS-API
| providing different different services is:
|
| (a) apparently inconsistent with defining a standard for development
| of binary applications dependent on a GSSAPI DLL facility - although
| I am willing to be corrected on that (see above),
The standard can be maintained if the registration problem is solved
(in option 2) or a good routing mechanism is found (in option 3). I
agree with you that a binary standard for development is needed
(preferably on more then just the Windows platform).
|
| If you can show me how we can meet (a) AND have multiple libraries,
| then fine - else I would suggest that we just add some text to say that
| applications can elect to consume GSS-API services in an implementation
| specific manner from as many different libraries as they choose at link
| time, but here is a standard which portable applications can
| adhere to ...
The easy answer that is somewhat windows specific, though it should be
easily generalized to other platforms, would be to add a new .ini file
called gssapi.ini (on Chicago this would be in the registry). Have a
[gssapi] section with "GSSProviderX=gssprov.dll,Other information". An
application on startup would look here and load the appropriate dlls.
The best answer is to support a routing mechanism but I'm not sure this
can be done without modifications to the API plus some other work.
My interest in this alias is coming from the www-security alias where I
am suggesting standardizing on the GSS api as a pluggable shared
library in Web servers and clients for the various internet security standards.
We can iron out the details off the alias if you like...
Thanx,
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10800;
17 Aug 94 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10792;
17 Aug 94 14:35 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa12839;
17 Aug 94 14:35 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA21101 at pad-thai.aktis.com>; Wed, 17 Aug 1994 14:17:34 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA22098; Wed, 17 Aug 94 14:16:11 EDT
Received: from dun-dun-noodles.cam.ov.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA21097 at pad-thai.aktis.com>; Wed, 17 Aug 1994 14:17:29 -0400
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA07429; Wed, 17 Aug 94 14:17:22 EDT
Message-Id: <9408171817.AA07429 at dun-dun-noodles.cam.ov.com>
To: John Ludeman <johnl at microsoft.com>
Cc: cat-ietf at mit.edu
Subject: Re: draft GSS-API MS Windows DLL interface spec
In-Reply-To: Your message of "Wed, 17 Aug 1994 10:51:31 +0700."
<9408171756.AA03320 at netmail2.microsoft.com>
Date: Wed, 17 Aug 1994 14:17:21 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> Having a portable shared library or dynamic library approach can help
>> establish the GSS-API in the mainstream and ease the burden on the
>> developers trying to keep up with the new
>> authentication/encryption/signing schemes that are coming down the
>> pipe.
I agree with John here. In fact, I have brought up the issue of
binary compatibility several times, but it never seemed to get
anywhere. I'm glad to see that it's getting some time, and hopefully,
the concepts we develop working on the windows version of the problem
will be at least somewhat transportable to unix, even though the
implementations certainly won't be.
>> The best answer is to support a routing mechanism but I'm not sure
>> this can be done without modifications to the API plus some other
>> work.
The API is powerful enough to support routing, but I don't know of an
implementation which does it right now.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11756;
17 Aug 94 15:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11746;
17 Aug 94 15:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14074;
17 Aug 94 15:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11737;
17 Aug 94 15:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11705;
17 Aug 94 15:32 EDT
Received: from pax.cavebear.com by CNRI.Reston.VA.US id aa14006;
17 Aug 94 15:32 EDT
Received: from karl.pax by cavebear.com (4.1/SMI-4.1)
id AA23745; Wed, 17 Aug 94 12:31:31 PDT
Date: Wed, 17 Aug 94 12:31:31 PDT
Message-Id: <9408171931.AA23745 at cavebear.com>
To: vaf at valinor.stanford.edu
Cc: ses at tipper.oit.unc.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: Vince Fuller's message of Tue, 16 Aug 94 22:14:38 PDT <CMM.0.90.2.777100478.vaf at Valinor.Stanford.EDU>
Subject: Re: Session layer/Middle ware
Reply-To: karl at cavebear.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Karl Auerbach <karl at cavebear.com>
X-Orig-Sender: karl at cavebear.com
Repository: cavebear
Originating-Client: pax
> With IPNG poised for deployment over the next few years there's a golden
> opportunity to piggyback that deployment to make it easier to write
> efficient protocols.
>
>Given a world where endpoint IDs and addresses continue to be confused (i.e.
>IPv6 as currentl specified), it also might be possible to use the session
>layer to hide underlying address changes. With the right functionality, the
>session layer could automatically re-establish TCP connections when addresses
>change, without applications needing to know that a connection was broken.
>
>Something to consider?
Very much so. I've been working (slowly, too slowly) on a protocol to
carry network managment traffic that is transport agile... a thin
session layer allows it to span sucessive TCP connections (or even
jump to alternative transports, like, dare I say it, something IPX
based, or dial-up.) There seems to be a trade off in doing this.
Either the session can make this totally transparent, in which case it
isn't a small protocol, or the applications can learn to expect
certain forms of discontinuities, the set of which is bounded and
known and which can be handled by the application.
I've found the "pcmail" model of application interaction to be rather
interesting in this context because that protocol always begins with a
short conversation of the form "where were we when we last talked?
Let's reconcile or create state." That little sequence buys an
enormous amount of flexibility, address independence, and mobile-user
(*not* mobile-computer) ability.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14673;
17 Aug 94 19:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14665;
17 Aug 94 19:17 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa18895;
17 Aug 94 19:17 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA26953 at pad-thai.aktis.com>; Wed, 17 Aug 1994 19:00:02 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA11588; Wed, 17 Aug 94 18:58:39 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA02597; Wed, 17 Aug 94 18:58:28 EDT
Date: Wed, 17 Aug 94 18:58:28 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408172258.AA02597 at tsx-11.MIT.EDU>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk's message of Tue, 16 Aug 94 20:10:36 BST,
<9408161910.AA22151 at getafix.oasis.icl.co.uk>
Subject: Re: draft GSS-API MS Windows DLL interface spec
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Date: Tue, 16 Aug 94 20:10:36 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Ordinals for the GSS-API are therefore defined starting from 1,
and are assigned to entry points in the order they are given in
the Standards Track C Bindings.
It isn't necessarily a problem that you're not explicitly defining the
Ordinals --- in fact it's nice that we can extend the GSS-API C bindings
without needing to modify the MS Windows DLL spec.
However, it does mean that the order of the functions in the C bindings
document is now significant, and any additions to the document have to
be at the end. This might unduly restrict us when we write the 2.0
version of the GSSAPI document.
Comments?
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15007;
17 Aug 94 19:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14999;
17 Aug 94 19:31 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa19107;
17 Aug 94 19:31 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA27179 at pad-thai.aktis.com>; Wed, 17 Aug 1994 19:10:05 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA12140; Wed, 17 Aug 94 19:08:39 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA03967; Wed, 17 Aug 94 19:08:30 EDT
Date: Wed, 17 Aug 94 19:08:30 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408172308.AA03967 at tsx-11.MIT.EDU>
To: John Ludeman <johnl at microsoft.com>
Cc: cat-ietf at mit.edu
In-Reply-To: John Ludeman's message of Wed, 17 Aug 94 10:51:31 TZ,
<9408171756.AA03320 at netmail2.microsoft.com>
Subject: Re: draft GSS-API MS Windows DLL interface spec
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
How about a compromise? User applications that don't care which
authentication system they use, or in the absence of the appropriate
configuration information, will use the system default DLL, GSS.DLL.
Applications that need a specific mechanism (and I suspect most of your
special case applications will be using one specific mechanism) will use
a mechanism defined name, say GSSKRB5.DLL. This name can either
configured in a setup file, or using an .ini file, or can be hard-coded,
as appropriate.
In the future, we can develop the routing/negotiating mechanism, and
that can then go in GSS.DLL; but for now, GSS.DLL can simply be the
local system default mechanism.
One downside with this approach is that if Krb5 was your default
mechanism, you'd install GSSKRB5.DLL, and GSS.DLL would be a sym link to
GSSKRB5.DLL. But unfortunately DOS doesn't have symbolic links; so
you'd have to have two copies of the KRB5 mechanism, one in GSSKRB5.DLL
and one in GSS.DLL. This will waste a bit of disk space, but other than
that it shouldn't be too bad.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15242;
17 Aug 94 19:54 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15234;
17 Aug 94 19:54 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa19483;
17 Aug 94 19:54 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA27714 at pad-thai.aktis.com>; Wed, 17 Aug 1994 19:40:21 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from relay1.pipex.net by MIT.EDU with SMTP
id AA13669; Wed, 17 Aug 94 19:38:58 EDT
Received: from q.icl.co.uk by relay1.pipex.net with SMTP (PP)
id <13912-0 at relay1.pipex.net>; Thu, 18 Aug 1994 00:38:48 +0100
Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.12-server)
id AA15549; Thu, 18 Aug 94 00:40:50 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA15942;
Thu, 18 Aug 94 00:38:05 BST
Message-Id: <9408172340.AA07218 at getafix.oasis.icl.co.uk>
Date: Thu, 18 Aug 94 00:40:12 BST
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: Re: draft GSS-API MS Windows DLL interface spec
To: cat-ietf at mit.edu
> However, it does mean that the order of the functions in the C bindings
> document is now significant, and any additions to the document have to
> be at the end. This might unduly restrict us when we write the 2.0
> version of the GSSAPI document.
I would favour a pragmatic approach - if the order needs amending for some
reason in the C Bindings then just add an appendix listing the order for
the purposes of DLLs or any other environments / purposes (e.g. debugging)
where a standard assignment of number against function is useful. If no need
to alter order, then add no appendix and just add on additional functions at
the end of the C Bindings.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15814;
17 Aug 94 21:12 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15805;
17 Aug 94 21:12 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa20724;
17 Aug 94 21:12 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <UAA28911 at pad-thai.aktis.com>; Wed, 17 Aug 1994 20:52:03 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA16664; Wed, 17 Aug 94 20:50:32 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA13401; Wed, 17 Aug 94 20:50:15 EDT
Date: Wed, 17 Aug 94 20:50:15 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9408180050.AA13401 at tsx-11.MIT.EDU>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk's message of Thu, 18 Aug 94 00:40:12 BST,
<9408172340.AA07218 at getafix.oasis.icl.co.uk>
Subject: Re: draft GSS-API MS Windows DLL interface spec
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
I'd favor having the appendix from the start, simply for clarity's sake.
Otherwise, people might get confused about whether in the order the
document or the order in the appendix takes precedence. This way, each
document which needs to reference the order can unambiguously point at
"appendix X".
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01847;
18 Aug 94 7:28 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01837;
18 Aug 94 7:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03311;
18 Aug 94 7:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01808;
18 Aug 94 7:28 EDT
Received: from relay1.pipex.net by IETF.CNRI.Reston.VA.US id aa01627;
18 Aug 94 7:16 EDT
X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed;
Thu, 18 Aug 1994 12:14:38 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2));
Relayed; Thu, 18 Aug 1994 11:54:40 +0100
Date: Thu, 18 Aug 1994 11:54:40 +0100
X400-Originator: J.Houldsworth at ste0906.wins.icl.co.uk
X400-Recipients: ietf at IETF.CNRI.Reston.VA.US
X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;ste0906 0000004700003490]
Original-Encoded-Information-Types: undefined (0)
X400-Content-Type: P2-1984 (2)
Content-Identifier: 3490
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: J.Houldsworth at ste0906.wins.icl.co.uk
Message-ID: <"3490*/I=J/S=Houldsworth/OU=ste0906/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: IPng discussion lists
Just to make sure that everybody is aware that the address of
the main IPng (now IP6) discussion list was wrongly announced at
the IPng BOF in Toronto. It is ipng at sunroof.eng.sun.com (note,
the hyphen between ip and ng was removed! The joining address
is still majordomo at sunroof.eng.sun.com with the 'subscribe
ipng' in the message body part. Jack
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02161;
18 Aug 94 7:48 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02151;
18 Aug 94 7:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03585;
18 Aug 94 7:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02140;
18 Aug 94 7:48 EDT
Received: from hplb.hpl.hp.com by IETF.CNRI.Reston.VA.US id aa02105;
18 Aug 94 7:46 EDT
Received: from otter.hpl.hp.com by hplb.hpl.hp.com; Thu, 18 Aug 1994 12:40:12 +0100
Received: by otter.hpl.hp.com
(1.37.109.8/15.6+ISC) id AA24337; Thu, 18 Aug 1994 12:45:58 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chandra shekhar Tekwani <ct at hplb.hpl.hp.com>
Message-Id: <9408181145.AA24337 at otter.hpl.hp.com>
Subject: Unsubscribe
To: ietf at IETF.CNRI.Reston.VA.US
Date: Thu, 18 Aug 94 12:45:57 BST
Full-Name: Chandra shekhar Tekwani
Cc: ct at hplb.hpl.hp.com
Mailer: Elm [revision: 70.85]
unsubscribe
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02374;
18 Aug 94 8:17 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02366;
18 Aug 94 8:17 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa03958;
18 Aug 94 8:17 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <HAA08827 at pad-thai.aktis.com>; Thu, 18 Aug 1994 07:47:57 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA02153; Thu, 18 Aug 94 07:46:15 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <HAA08822 at pad-thai.aktis.com>; Thu, 18 Aug 1994 07:46:46 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA03149; Thu, 18 Aug 94 07:46:37 EDT
Message-Id: <9408181146.AA03149 at winkl.aktis.com>
To: Theodore Ts'o <tytso at mit.edu>
Cc: p.v.mcmahon.rea0803 at oasis.icl.co.uk, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: draft GSS-API MS Windows DLL interface spec
In-Reply-To: Your message of "Wed, 17 Aug 1994 20:50:15 EDT."
<9408180050.AA13401 at tsx-11.MIT.EDU>
Date: Thu, 18 Aug 1994 07:46:37 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Ted writes:
>I'd favor having the appendix from the start, simply for clarity's sake.
>Otherwise, people might get confused about whether in the order the
>document or the order in the appendix takes precedence. This way, each
>document which needs to reference the order can unambiguously point at
>"appendix X".
I agree, and certainly think that wiring in an unnecessary constraint
of dependence on the order in which routines appear in the RFC (or
revisions thereof) seems like a bad thing. I suggest that the way
to proceed should be to prepare an Internet-Draft, probably later to
be folded in as an appendix to RFC-1509, including all the necessary
discussion to profile the C bindings for Windows DLL usage as well
as the ordinal numbers themselves. Do I hear the sound of a volunteer
to prepare and drive this draft ?-)
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06335;
18 Aug 94 12:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06327;
18 Aug 94 12:01 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa09746;
18 Aug 94 12:01 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <LAA13335 at pad-thai.aktis.com>; Thu, 18 Aug 1994 11:37:49 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA15666; Thu, 18 Aug 94 11:36:21 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <LAA13330 at pad-thai.aktis.com>; Thu, 18 Aug 1994 11:37:40 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA03358; Thu, 18 Aug 94 11:37:37 EDT
Message-Id: <9408181537.AA03358 at winkl.aktis.com>
To: John Linn <linn at cam.ov.com>
Cc: Theodore Ts'o <tytso at mit.edu>, p.v.mcmahon.rea0803 at oasis.icl.co.uk,
cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: draft GSS-API MS Windows DLL interface spec
In-Reply-To: Your message of "Thu, 18 Aug 1994 07:46:37 EDT."
<9408181146.AA03149 at winkl.aktis.com>
Date: Thu, 18 Aug 1994 11:37:36 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
I wrote, earlier this AM:
>I suggest that the way
>to proceed should be to prepare an Internet-Draft, probably later to
>be folded in as an appendix to RFC-1509,
...
>Do I hear the sound of a volunteer
>to prepare and drive this draft ?-)
My apologies to Piers McMahon and the other members of this list
for failing to note Piers' already-outstanding offer to turn a
follow-up version of the working memo he'd circulated into
precisely such a draft.
[We now return to our regular, ongoing technical discussion.]
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06811;
18 Aug 94 12:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06801;
18 Aug 94 12:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10290;
18 Aug 94 12:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06780;
18 Aug 94 12:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06692;
18 Aug 94 12:24 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10170;
18 Aug 94 12:23 EDT
Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-18)
id <AA21852>; Thu, 18 Aug 1994 08:52:38 -0700
Received: (from mm94 at localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) id KAA17718; Thu, 18 Aug 1994 10:53:29 -0500
Date: Thu, 18 Aug 1994 10:53:29 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: ACM Multimedia 94 <mm94 at dworkin.wustl.edu>
Message-Id: <199408181553.KAA17718 at dworkin.wustl.edu>
To: announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cip at bbn.com, end2end-interest at isi.edu,
f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
icad-request at santafe.edu, ietf at isi.edu, iplpdn at CNRI.Reston.VA.US,
ir-l%uccvma.bitnet at cunyvm.cuny.edu, rem-conf-request at es.net,
s-comput%tcsvm.BITNET at wugate.wustl.edu, sig11 at roses.stanford.edu,
sigmedia at bellcore.com, sip-request at catarina.usc.edu,
smds at CNRI.Reston.VA.US, sound at acm.org, tccc at cs.umass.edu, tcplw at cray.com,
tf-mm at i4serv.informatik.rwth-aachen.de, uist.chi at xerox.com
Subject: ADVANCE PROGRAM -- ACM MULTIMEDIA 94
ANNOUNCEMENT
2nd ANNUAL ACM MULTIMEDIA CONFERENCE AND EXPOSITION
October 15-20, 1994
San Francisco, California
Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI,
SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS and in
cooperation with SIGAPP, SIGMOD, SIGOPS and the IEEE Communications
Society.
=================****=================****=================****============
MULTIMEDIA '94 WWW/MOSAIC AND FTP SITES
The Multimedia '94 WWW home page contains the advance program,
registration information, as well as other relevant details.
The URL is:
http://george.lbl.gov/MM94/MM94.html
The advance program and registration form can also be retrieved
by anonymous ftp:
ftp://dworkin.wustl.edu/pub/MM94/program
If you need more information about Multimedia'94 or the Advance
Program, contact Danieli and O'Keefe (DOK), our conference management
company.
Address
Danieli and O'Keefe
490 Boston Post Road
Sudbury, MA 01776-9898
Phone numbers
800-524-1851, or 508-443-3330, Ext. 1214
Email
multimedia.dok at notes.compuserve.com or ACMHELP at ACM.org
=================****=================****=================****============
CONFERENCE HIGHLIGHTS
* Why ACM Multimedia '94?
The second ACM Multimedia Conference will present an exciting mixture of
technology and art. Sessions will focus on what will be the standards of
the future; not what is happening today. The program of papers, panels,
courses, demonstrations, videos, and exhibits will explore the breadth
and diversity of this ever-changing technology.
* You should be there!
This conference will be vital for researchers, technical staff, software
engineers, educators and artists working in any and all aspects of
multimedia research and production. ACM Multimedia will draw attendees
and presenters from both academia and industry, including
telecommunications, fine arts, engineering, software development,
multimedia production, electronic publishing, digital libraries, computer
graphics, user interfaces, broadcast media, and networking.
* Opening and Closing Plenaries
The technical program kicks off with a debate by industry leaders from
LucasArts, Philips Electronics and the new Mosaic Communications,
moderated by Dr. R.W. Lucky, of Bellcore. They will debate their
differing views on the evolution of the Multimedia industry.
At the Closing Plenary, Tom Holman, the award-winning designer of the THX
sound system and Corporate Technical Director of LucasFilm, discusses
presentations standards for sound and graphics and Scott Marden, of
Philips Media will give his perspective on the emerging multimedia
industry. See page 14 for more details.
* The Ubiquitous Art Zone
The Ubiquitous Art Zone is that part of Multimedia '94 that presents the
creations of artists working in multimedia. The art work ranges from
"immersive environments" and "garage VR" to narrative works on
interactive CD ROM and hard drive. By their use of interactive interface
technologies, the artists invite the visitors to become participants in a
shared experience. Come celebrate the emergence of the art made possible
by the digital revolution.
* Ubiquitous Art Zone/Exhibit Reception
Please join us Tuesday evening for a reception that allows you to
experience the full range of the arts in multimedia, as well as to spend
some unhurried time in the exhibit hall.
* Exhibit Hall
This is the best opportunity to see and learn from companies who will
share their multimedia experiences with you. Digital Equipment Corp. and
IBM are just two of the companies who are eager to show their products
and services.
* Electronic Proceedings
The conference proceedings will be available on a CD-ROM and on
electronic network. Both media will include the text of the papers being
presented, video clips from the video program and other material.
* Conference Videotape
The ACM Multimedia '94 video will feature videotapes of multimedia
systems in action, and other topics relevant to the conference. The
videos have been selected based on their relevance, technical content,
originality, presentation quality, and clarity. The videotape will be
available for purchase at the conference.
* Demonstrations Program
The demonstration program will feature novel research prototypes that
demonstrate the latest advances in multimedia computing and
communications technologies. These juried and working prototypes will be
exhibited at regular intervals by their creators. Time will be provided
for personal interaction with the systems.
* Best Paper Awards
Both the best paper and the best student paper will be presented in a
special session on Thursday afternoon. Come hear the best of the best!
* Vendor Track
A special venue has been provided for exhibitor presentations on their
products and services. This is a unique opportunity to find out about the
tools and products that can help you be more productive.
=================****=================****=================****============
CONFERENCE COMMITTEE
CO-CHAIRS
M. Blattner, Lawrence Livermore National Laboratory and University
of California, Davis
J. O. Limb, Georgia Institute of Technology, Atlanta
ADVISORY COMMITTEE
E. Fox, Virginia Polytechnic Institute and SU
TREASURER
R. B. Allen, Bellcore
PROCEEDINGS
J. J. Garcia-Luna, University of California, Santa Cruz
WORKSHOPS
S. Wilbur, Queen Mary & Westfield College, UK
DEMONSTRATIONS
T. Little, Boston University
VIDEO
M. Brown, Digital Equipment Corporation
D. Redell, Digital Equipment Corporation
ELECTRONIC PUBLISHING
R. Rada, University of Liverpool, UK
PANELS
A. Kuchinsky, Hewlett-Packard
S. Bulick, US WEST Technologies
COURSES
E. P. Glinert, Rensselaer Polytechnic Institute
D. McIntyre, Morgan, Stanley & Co.
K. Wittenburg, Bell Communications Research,
LOCAL ARRANGEMENTS
J. D. Smith, Lawrence Livermore National Laboratory
PUBLICITY
G. Parulkar, Washington University in St. Louis
EXHIBITS
P. Mantey, University of California, Santa Cruz
AUDIO/VISUAL
N. Johnston, Lawrence Berkeley Laboratory
UBIQUITOUS ART ZONE
Beverly Reiser
PROGRAM COMMITTEE
Chair
D. Ferrari, University of California, Berkeley
CO-CHAIRS
S. Ahuja, AT&T Bell Laboratories
F. Kitson, Hewlett-Packard
T. Kunii, University of Aizu, Japan
R. Phillips, Los Alamos National Laboratory
R. Rada, University of Liverpool, UK
R. Sacks-Davis, the Royal Melbourne Institute of Technology.
=================****=================****=================****============
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09250;
18 Aug 94 14:37 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09239;
18 Aug 94 14:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12994;
18 Aug 94 14:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09227;
18 Aug 94 14:37 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09177;
18 Aug 94 14:34 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12865;
18 Aug 94 14:34 EDT
Received: from potlatch.esd112.wednet.edu by venera.isi.edu (5.65c/5.61+local-18)
id <AA28058>; Thu, 18 Aug 1994 11:35:08 -0700
Received: by potlatch.esd112.wednet.edu (5.0/SMI-SVR4)
id AA08335; Thu, 18 Aug 1994 10:44:01 +0800
Date: Thu, 18 Aug 1994 10:44:00 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: james johansen <jjohanse at potlatch.esd112.wednet.edu>
Subject: unsubscribe
To: ietf at isi.edu
Message-Id: <Pine.3.89.9408181025.A8273-0100000 at potlatch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 0
unsubscribe
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10285;
18 Aug 94 15:40 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10277;
18 Aug 94 15:40 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14331;
18 Aug 94 15:40 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA17659 at pad-thai.aktis.com>; Thu, 18 Aug 1994 15:05:03 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA01621; Thu, 18 Aug 94 15:03:31 EDT
Received: from dun-dun-noodles.cam.ov.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA17655 at pad-thai.aktis.com>; Thu, 18 Aug 1994 15:04:46 -0400
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA08164; Thu, 18 Aug 94 15:04:39 EDT
Message-Id: <9408181904.AA08164 at dun-dun-noodles.cam.ov.com>
To: John Linn <linn at cam.ov.com>
Cc: Theodore Ts'o <tytso at mit.edu>, p.v.mcmahon.rea0803 at oasis.icl.co.uk,
cat-ietf at mit.edu
Subject: Re: draft GSS-API MS Windows DLL interface spec
In-Reply-To: Your message of "Thu, 18 Aug 1994 07:46:37 EDT."
<9408181146.AA03149 at winkl.aktis.com>
Date: Thu, 18 Aug 1994 15:04:38 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
Compromise: Specify the order as a function of the order of
declaration in the header file in the Appendix. Although I wouldn't
want to restrict the prose, restricting us to adding new functions
only at the end of of the prototypes in the header file doesn't seem
too bad.
Otherwise, specifying it as an appendix to rfc1509 seems like the
right thing.
I don't volunteer, because I don't know anything about Windows
programming :-)
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11060;
18 Aug 94 16:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11051;
18 Aug 94 16:14 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa14988;
18 Aug 94 16:14 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA18502 at pad-thai.aktis.com>; Thu, 18 Aug 1994 15:44:08 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA04590; Thu, 18 Aug 94 15:42:37 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA18413 at pad-thai.aktis.com>; Thu, 18 Aug 1994 15:43:57 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA03475; Thu, 18 Aug 94 15:43:56 EDT
Message-Id: <9408181943.AA03475 at winkl.aktis.com>
To: John Ludeman <johnl at microsoft.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: draft GSS-API MS Windows DLL interface spec
In-Reply-To: Your message of "Tue, 16 Aug 1994 17:13:49 +0700."
<9408170018.AA14206 at netmail2.microsoft.com>
Date: Thu, 18 Aug 1994 15:43:55 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
John Ludeman wrote, excerpting:
>Specifically, a
>single application (like a Web viewer say...) may want to use one
>security provider for authentication and another for signing and
>perhaps a third for encryption.
In the (possibly redundant) interest of clarification, note that
use of a particular mechanism's per-message protection facilities
doesn't work unless you've previously established a context using
that mechanism. Since context establishment performs (peer entity)
authentication, the services aren't wholly independent. It's
certainly possible to establish multiple contexts, one for each
of the mechanisms your side shares with its peer, and then toggle
among those different contexts so as to make use of the different
per-message protection functions they include; this still implies,
though, that multiple authentications are performed even if some
of their results are later ignored.
Is the functional requirement to use different providers for
different services, or rather is this one possible implementation
of a requirement to be able to choose different encryption and
integrity algorithms? If the latter, use of QOP specifiers within
a single mechanism (and context) might be an alternative approach.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12001;
18 Aug 94 16:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11992;
18 Aug 94 16:51 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa15879;
18 Aug 94 16:51 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA19093 at pad-thai.aktis.com>; Thu, 18 Aug 1994 16:14:58 -0400
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA07009; Thu, 18 Aug 94 16:13:29 EDT
Received: from krypton.mcc.com by turtle.mcc.com (4.1/isd-master_921116_15:19)
id AA14899; Thu, 18 Aug 94 15:13:24 CDT
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA28176; Thu, 18 Aug 94 15:13:24 CDT
Date: Thu, 18 Aug 94 15:13:24 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9408182013.AA28176 at krypton.mcc.com>
To: linn at cam.ov.com
Cc: cat-ietf at mit.edu
In-Reply-To: John Linn's message of Thu, 18 Aug 1994 15:43:55 -0400 <9408181943.AA03475 at winkl.aktis.com>
Subject: draft GSS-API MS Windows DLL interface spec
Is the functional requirement to use different providers for
different services, or rather is this one possible implementation
of a requirement to be able to choose different encryption and
integrity algorithms? If the latter, use of QOP specifiers within
a single mechanism (and context) might be an alternative approach.
Seems like the latter to me, since a given provider may provide
multiple services under a single GSSAPI implementation.
- Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00602;
19 Aug 94 4:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00592;
19 Aug 94 4:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01186;
19 Aug 94 4:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00581;
19 Aug 94 4:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00455;
19 Aug 94 4:06 EDT
Received: from ceres.fokus.gmd.de by CNRI.Reston.VA.US id aa01022;
19 Aug 94 4:06 EDT
Received: from fokus.gmd.de by ceres.fokus.gmd.de
id <16508-0 at ceres.fokus.gmd.de>; Fri, 19 Aug 1994 10:06:15 +0200
Subject: "IETF-like" facilities - pointers?
To: ietf at CNRI.Reston.VA.US
Date: Fri, 19 Aug 1994 10:06:15 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
X-Orig-Sender: schulzrinne at fokus.gmd.de
Message-ID: <9408190406.aa01022 at CNRI.Reston.VA.US>
For Infocom 1995, the IEEE is trying to provide "IETF-like" facilities,
that is, a terminal room and MBONE connectivity. I'm looking for any
notes, guidelines, hints, etc. from the operators/users of previous IETFs
on how to set up for such an event. I'll try to compile the individual
responses into a general document; given the amount of interest
expressed from the IEEE side, this is a growth area...
Thanks for any help and sorry for the wide distribution.
--
---
Henning Schulzrinne email: hgs at fokus.gmd.de
GMD-Fokus phone: +49 30 25499 219
Hardenbergplatz 2 fax: +49 30 25499 202
D-10623 Berlin
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06236;
19 Aug 94 11:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10144;
19 Aug 94 11:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06167;
19 Aug 94 11:28 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05978;
19 Aug 94 11:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09958;
19 Aug 94 11:21 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05969;
19 Aug 94 11:21 EDT
To: IETF-Annouce: ;
Subject: Final Agenda for Aug. 22 IPng Walkthrough
Date: Fri, 19 Aug 94 11:21:30 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Steve Coya <scoya at CNRI.Reston.VA.US>
Message-ID: <9408191121.aa05969 at IETF.CNRI.Reston.VA.US>
Final Agenda for Aug. 22 IPng Walkthrough
Introduction, Scott Bradner and Allison Mankin, 10 minutes
Protocol, Steve Deering, 45 minutes
Routing and Addressing, Steve Deering, 30 minutes
Autoconfiguration, Dave Katz, 30 minutes
Security, Ran Atkinson, 30 minutes
Transition, Bob Hinden, 30 minutes
General Questions and Discussion, about 1 hour
Reading List:
Note that the following sources are for the most part
not revised to fully reflect the Toronto meetings of the
IPng working groups and work since Toronto. They are the
Area Directors' view of the best written background materials.
The presentations will offer more complete and up-to-date
designs.
Protocol:
draft-ietf-sipp-spec-01.txt
Routing and Addressing:
draft-rekhter-ipng-arch-IPv6-addr-00.txt
RFC 1668 Estrin, Li, Rekhter, "Unified Routing Requirements for IPng"
draft-ford-sdrp-sipp16-format-00.txt
Autoconfiguration:
draft-ietf-tuba-addr-assign-00.txt
Security:
draft-ietf-sipp-sa-02.txt
draft-ietf-sipp-ap-04.txt
Transition:
draft-ietf-sipp-sst-overview-00.txt, Gilligan
As part of the last call process for the IP6 (nee IPng)
recommendation, the primary developers will be presenting a structured
walkthrough of the entire IP6 suite, including transition plans, on
Aug 22, from 1000-1300 (pacific time), with expanded material,
questions, etc from 1300-1400.
The presentation will be sent over the MBONE throughout the Internet.
Xerox PARC, MIT, and ISI (at least) will make conference room-style
access available to IESG and IAB members, the external review board,
and others as space and access constraints allow. Most of the
physical presentation will originate from PARC and MIT, but we
anticipate contributions and questions from other sites. We plan to
record the presentations and offer a replay at another date; given
enough interest expressed to the Area Directors (mankin at cmf.nrl.navy.mil,
sob at harvard.edu), we will arrange for a q&a period with some of
the presenters during a time more convenient for Europe and PacRim
timezones.
Here's the MBONE session info for Monday (it is advertised in
SD as IP:NG Review):
audio at 45430/50691 (fmt: idvi)
video at 36611/9270 (fmt: nv)
whiteboard at 35618/41278 (orient: landscape, recvonly)
For directions and reservations at these specific sites contact:
Xerox PARC Steve Deering (deering at parc.xerox.com)
ISI Jeanine Yamazaki (yamazaki at isi.edu)
MIT Lisa Taylor (ltaylor at lcs.mit.edu)
Please send reservation requests as soon as possible so that we can
determine the number of spaces to reserve, refreshments, etc. (Each
site is determining its own policy here.)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11355;
19 Aug 94 16:22 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11345;
19 Aug 94 16:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18589;
19 Aug 94 16:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11329;
19 Aug 94 16:22 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11256;
19 Aug 94 16:18 EDT
Received: from quern.epilogue.com by CNRI.Reston.VA.US id aa18502;
19 Aug 94 16:18 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Bridgham <dab at epilogue.com>
X-Orig-Sender: dab at epilogue.com
To: ses at tipper.oit.unc.edu
CC: vaf at valinor.stanford.edu, ietf at CNRI.Reston.VA.US
In-reply-to: Simon E Spero's message of Wed, 17 Aug 94 01:56:07 -0400 <9408170556.AA22937 at tipper.oit.unc.edu>
Subject: Session layer/Middle ware
Date: Fri, 19 Aug 94 16:18:24 -0400
Message-ID: <9408191618.aa20596 at quern.epilogue.com>
Date: Wed, 17 Aug 94 01:56:07 -0400
From: Simon E Spero <ses at tipper.oit.unc.edu>
SCP reserves the first 1024 session ids for use as virtual well
known ports. This will allow things like simple presentation
negotiation to be added later to transparently support things like
encrypted or gzipped data streams.
Oh noooo! Not again! Would it break SCP too badly to punt these well
known numbers and go back to contact names? Check out TCPMUX
(RFC1078) or better the ChaosNet specs for write ups on contact names.
Dave Bridgham
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11996;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19706;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11973;
19 Aug 94 16:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11809;
19 Aug 94 16:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-checkp-00.txt
Date: Fri, 19 Aug 94 16:53:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408191653.aa11809 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extension for Checkpoint/Restart
Author(s) : D. Crocker, N. Freed, A. Cargille
Filename : draft-ietf-mailext-checkp-00.txt
Pages : 8
Date : 08/18/1994
This memo defines an extension to the SMTP service whereby an interrupted
SMTP transaction can be restarted at a later time without having to repeat
all of the message content sent prior to the interruption.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-checkp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-checkp-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940818170914.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-checkp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-checkp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940818170914.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11996;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19706;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11973;
19 Aug 94 16:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11809;
19 Aug 94 16:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-checkp-00.txt
Date: Fri, 19 Aug 94 16:53:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408191653.aa11809 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extension for Checkpoint/Restart
Author(s) : D. Crocker, N. Freed, A. Cargille
Filename : draft-ietf-mailext-checkp-00.txt
Pages : 8
Date : 08/18/1994
This memo defines an extension to the SMTP service whereby an interrupted
SMTP transaction can be restarted at a later time without having to repeat
all of the message content sent prior to the interruption.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-checkp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-checkp-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940818170914.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-checkp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-checkp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940818170914.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12002;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19708;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11972;
19 Aug 94 16:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11788;
19 Aug 94 16:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-pipeline-00.txt
Date: Fri, 19 Aug 94 16:53:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408191653.aa11788 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extension for Command Pipelining
Author(s) : N. Freed, A. Cargille
Filename : draft-ietf-mailext-pipeline-00.txt
Pages : 8
Date : 08/18/1994
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-pipeline-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-pipeline-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940818155240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-pipeline-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-pipeline-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940818155240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12002;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19708;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11972;
19 Aug 94 16:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11788;
19 Aug 94 16:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-pipeline-00.txt
Date: Fri, 19 Aug 94 16:53:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408191653.aa11788 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extension for Command Pipelining
Author(s) : N. Freed, A. Cargille
Filename : draft-ietf-mailext-pipeline-00.txt
Pages : 8
Date : 08/18/1994
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-pipeline-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-pipeline-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940818155240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-pipeline-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-pipeline-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940818155240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12013;
19 Aug 94 16:56 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11996;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19706;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11973;
19 Aug 94 16:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11809;
19 Aug 94 16:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-checkp-00.txt
Date: Fri, 19 Aug 94 16:53:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408191653.aa11809 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extension for Checkpoint/Restart
Author(s) : D. Crocker, N. Freed, A. Cargille
Filename : draft-ietf-mailext-checkp-00.txt
Pages : 8
Date : 08/18/1994
This memo defines an extension to the SMTP service whereby an interrupted
SMTP transaction can be restarted at a later time without having to repeat
all of the message content sent prior to the interruption.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-checkp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-checkp-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940818170914.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-checkp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-checkp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940818170914.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12023;
19 Aug 94 16:56 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12002;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19708;
19 Aug 94 16:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11972;
19 Aug 94 16:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11788;
19 Aug 94 16:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-pipeline-00.txt
Date: Fri, 19 Aug 94 16:53:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408191653.aa11788 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extension for Command Pipelining
Author(s) : N. Freed, A. Cargille
Filename : draft-ietf-mailext-pipeline-00.txt
Pages : 8
Date : 08/18/1994
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-pipeline-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-pipeline-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940818155240.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-pipeline-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-pipeline-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940818155240.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24044;
20 Aug 94 1:28 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24034;
20 Aug 94 1:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28201;
20 Aug 94 1:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24019;
20 Aug 94 1:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23995;
20 Aug 94 1:25 EDT
Received: from gaia.internex.net by CNRI.Reston.VA.US id aa28175;
20 Aug 94 1:25 EDT
Received: from yoda.trancell.com by gaia.internex.net (5.0/SMI-SVR4)
id AA03421; Fri, 19 Aug 1994 22:27:03 +0800
Received: from merlin.trancell.com by yoda.trancell.com (4.1/SMI-4.1/Trancell)
id AA24912; Fri, 19 Aug 94 22:34:26 EDT
Date: Fri, 19 Aug 94 22:26:30 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: mahesh at trancell.com
Subject: Subscription request
To: ietf at CNRI.Reston.VA.US
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-Id: <Chameleon.4.00.940819222711.mahesh at merlin.trancell.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 36
Please add me to the mailing list.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04055;
20 Aug 94 16:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04045;
20 Aug 94 16:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09204;
20 Aug 94 16:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04020;
20 Aug 94 16:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03948;
20 Aug 94 16:03 EDT
Received: from uvaarpa.Virginia.EDU by CNRI.Reston.VA.US id aa09072;
20 Aug 94 16:03 EDT
Received: from cvgs.schools.virginia.edu by uvaarpa.virginia.edu id aa29016;
20 Aug 94 16:04 EDT
Received: by cvgs.schools.virginia.edu (5.65/1.34)
id AA26897; Sat, 20 Aug 94 20:10:18 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carolyn M Jones <cjones at cvgs.schools.virginia.edu>
Message-Id: <9408202010.AA26897 at cvgs.schools.virginia.edu>
Subject: unsubscribe
To: ietf at CNRI.Reston.VA.US
Date: Sat, 20 Aug 94 16:10:17 EDT
X-Mailer: PENELM [version 2.3.1 PL11]
unsubscribe me.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02283;
21 Aug 94 12:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02273;
21 Aug 94 12:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06591;
21 Aug 94 12:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02258;
21 Aug 94 12:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02161;
21 Aug 94 12:20 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06434;
21 Aug 94 12:20 EDT
Received: from cs.rpi.edu by venera.isi.edu (5.65c/5.61+local-18)
id <AA24930>; Sun, 21 Aug 1994 08:47:47 -0700
Received: from colossus.cs.rpi.edu by cs.rpi.edu (5.67a/1.4-RPI-CS-Dept)
id AA18178; Sun, 21 Aug 1994 11:35:34 -0400 (glinert from colossus.cs.rpi.edu)
Date: Sun, 21 Aug 94 11:35:33 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: glinert at cs.rpi.edu
Received: by colossus.cs.rpi.edu (4.1/2.2-RPI-CS-client)
id AA28091; Sun, 21 Aug 94 11:35:33 EDT
Message-Id: <9408211535.AA28091 at colossus.cs.rpi.edu>
To: end2end-interest at isi.edu, f-troup at aurora.cis.upenn.edu, ietf at isi.edu,
ir-l%uccvma.bitnet at cunyvm.cuny.edu, rem-conf-request at es.net,
rem-conf at es.net, sound at pascal.acm.org, tccc at cs.umass.edu
Subject: Come To ASSETS'94 In Los Angeles!
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
ADVANCE PROGRAM AND REGISTRATION FORMS
ASSETS '94
The First Annual International ACM/SIGCAPH
Conference on Assistive Technologies
October 31 - November 1, 1994
Doubletree Marina del Rey Hotel
Los Angeles, California
Sponsored by the ACM's Special Interest Group on Computers and the Physically
Handicapped, ASSETS '94 is the first of a new annual series of conferences
whose goal is to provide a forum where researchers and developers from academia
and industry can meet to exchange ideas and report on new developments relating
to computer-based systems to help people with impairments and disabilities of
all kinds.
This announcement includes 5 parts:
o ASSETS '94 Advance Program
o ASSETS '94 Registration Form
o Hotel and Travel Arrangement Information
o ACM / SIGCAPH Membership Application
o Who are the organizers of ASSETS '94?
If you have any questions or would Ephraim P. Glinert
like further information, please Dept. of Computer Science
contact the ASSETS '94 Program Chair: R. P. I.
Troy, NY 12180
E-mail: glinert at cs.rpi.edu
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
ASSETS '94 ADVANCE PROGRAM
==========================
SUN 10/30: 18:00-21:00 Registration
19:00-21:00 Reception
MON 10/31: 8:00-17:00 Registration
8:00- 9:00 Continental Breakfast
8:45- 9:00 Welcome to ASSETS '94!
9:00-10:00 Keynote I
10:00-10:30 Break
10:30-12:00 Papers I: Hearing Impairments
"Pattern Recognition and Synthesis for Sign Language
Translation System"
Masaru Ohki, Hirohiko Sagawa, Tomoko Sakiyama,
Eiji Oohira, Hisashi Ikeda and Hiromichi Fujisawa -
Hitachi (Japan)
"Multimedia Dictionary of American Sign Language"
Sherman Wilcox and Joanne Scheibman - University
New Mexico (USA)
Doug Wood - Brains Software (USA)
William C. Stokoe - Linstok Press (USA)
"A System for Teaching Speech to Profoundly Deaf
Children using Synthesized Acoustic and Articulatory
Patterns"
Elizabeth Keate, Hector Javkin, Norma
Antonanzas-Barroso and Ranjun Zou - Panasonic
Technologies (USA)
12:00-14:00 Lunch + SIGCAPH Business Meeting
14:00-15:00 Papers II: Augmentative Communication A
"Iconic Language Design for People with Significant
Speech and Multiple Impairments"
P. L. Albacete, S. K. Chang and G. Polese -
University of Pittsburgh (USA)
B. Baker - Semantic Compaction Systems (USA)
"The Application of Spatialization and Spatial
Metaphor to Augmentative and Alternative
Communication"
Patrick Demasco, U. Delaware (USA),
Alan F. Newell and John L. Arnott - University
of Dundee (UK)
15:00-15:30 Break
15:30-17:30 Papers III: Vision Impairments A
"Screen Reader/2: Access to OS/2 and the Graphical
User Interface"
Jim Thatcher - IBM Research (USA)
"Providing Access to Graphical User Interfaces - Not
Graphical Screens"
W. Keith Edwards, Elizabeth D. Mynatt and Kathryn
Stockton - Georgia Institute of Technology (USA)
"Increasing Access to Information for the Print
Disabled through Electronic Documents in SGML"
Bart Bauwens, Jan Engelen and Filip Evenepoel -
Katholieke Universiteit Leuven (Belgium)
Tom Wesley and Chris Tobin - U. Bradford (UK)
"Interactive Audio Documents"
T. V. Raman, Digital Equipment Corporation (USA)
David Gries, Cornell (USA)
18:00-21:00 Buffet Dinner + Keynote II
21:00-22:00 ASSETS '95 Organizational Meeting
TUE 11/1: 8:00-12:00 Registration
8:00- 9:00 Continental Breakfast
9:00-10:00 Papers IV: Motor Impairments
"An Overview of Programs and Projects at the
Rehabilitation Research and Development Center"
David L. Jaffe - Dept. of Veteran Affairs
Medical Center (USA)
"Using the Baby-Babble-Blanket for Infants with
Motor Problems: A Case Study"
Harriet J. Fell, Linda J. Ferrier, Hariklia Delta,
Regina Peterson, Zehra Mooraj and Megan Valleau -
Northeastern University (USA)
10:00-10:30 Break
10:30-12:00 Papers V: Vision Impairments B
"Personal Guidance System for the Visually Impaired"
Jack M. Loomis and Reginald G. Golledge -
University of California at Santa Barbara (USA)
Roberta L. Klatzky, Carnegie Mellon (USA)
Jon M. Speigle and Jerome Tietz - University of
California at Santa Barbara (USA)
"Hyperbraille: A Hypertext System for the Blind"
Thomas Kieninger and Norbert Kuhn - Deutsches
Forschungszentrum fuer Kuenstliche Intelligenz
(Germany)
"Automatic Impact Sound Generation for use in
Nonvisual Interfaces"
Helmut Schauer - University of Zurich (Switzerland)
A. Darvishi, V. Guggiana, E. Munteanu, M. Motavalli
and M. Rauterberg - Swiss Federal Institute of
Technology/ETH (Switzerland)
12:00-14:00 Lunch + Panel (Elizabeth Mynatt, moderator)
14:00-15:00 Papers VI: Augmentative Communication B
"A Writing Tool for Physically Disabled Individuals:
Lexical Semantics for Filling in the Pieces"
Kathleen F. McCoy, Patrick W. Demasco, Mark A.
Jones, Christopher A. Pennington, Peter B.
Vanderheyden and Wendy M. Zickus - University of
Delaware (USA)
"Validation of a Keystroke-Level Model for a Text
Entry System Used by People with Disabilities"
Heidi H. Koester and Simon P. Levine - University
of Michigan (USA)
15:00-15:30 Break
15:30-17:30 Papers VII: New Directions and Work-in-Progress
"An Experimental Sound-Based Hierarchical Menu
Navigation System for Visually Handicapped Use of
Graphical User Interfaces"
Arthur I. Karshmer, Pres Brawner and George
Reiswig - New Mexico State University (USA)
"A Rule-Based System that Suggests Computer
Adaptations for Users with Special Needs"
William W. McMillan, Michael Zeiger and Lech
Wisniewski - Eastern Michigan University (USA)
"LVRS: The Low Vision Research System"
Mitchell Krell, University of Southern
Mississippi (USA)
"EEG as a Means of Communication: Preliminary
Experiments in EEG Analysis using Neural Networks"
Charles W. Anderson, Saikumar V. Devulapalli and
Erik Stolz - Colorado State University (USA)
"Audio Formatting of a Graph"
Sophie H. Zhang and Mukkai Krishnamoorthy -
Rensselaer Polytechnic Institute (USA)
"Disabilities, Opportunities, Internetworking and
Technology (DO-IT) on the Electronic Highway"
Sheryl Bergstahler and Dan Comden - University of
Washington (USA)
17:30 Close
ASSETS '94 REGISTRATION FORM #############################################
============================
This form is 2 pages long. Please print it out, complete both pages and mail
it WITH FULL PAYMENT to:
Ephraim P. Glinert, ASSETS '94
Dept. of Computer Science
R. P. I.
Troy, NY 12180
We're sorry, but e-mail registration forms and/or forms not accompanied by
full payment (check or credit card information) CANNOT be accepted.
CONFERENCE REGISTRATION FEES
EARLY LATE / ON-SITE
--------------------------------------------------------
ACM member: $ 395 $ 475
Nonmember: $ 580 $ 660
Full time student: $ 220 $ 270
--------------------------------------------------------
1: CONFERENCE REGISTRATION (from the table): $ ___________
2: EXTRA RECEPTION TICKET (Monday, Oct. 31): $ 40 ___YES ___NO
3: EXTRA COPY OF THE CONFERENCE PROCEEDINGS: $ 30 ___YES ___NO
TOTAL AMOUNT DUE: $ ___________
NOTES:
o Registration fee includes: ADMISSION to all sessions, one copy of the
conference PROCEEDINGS, and MEALS as indicated in the program above.
o To qualify for the EARLY rate, your registration must be postmarked on
or before FRIDAY, SEPTEMBER 23, 1994. If you are an ACM MEMBER, please
supply your ID# __________________ (OR use the membership application
below to join ACM and SIGCAPH today!). STUDENTS, please attach a clear
photocopy of your valid student ID.
o CANCELLATIONS will be accepted up to FRIDAY, OCTOBER 14, 1994 subject
to a 20% handling fee.
ASSETS '94 REGISTRATION FORM (continued)
========================================
PERSONAL INFORMATION:
Name __________________________________________________________________________
Affiliation ___________________________________________________________________
Address _______________________________________________________________________
City _______________________________ State/Province __________________________
Country __________________________________ Zip/Postal Code ___________________
E-mail ___________________________________ Telephone _________________________
***I have a disability for which I require special accommodation ___YES ___NO
If YES, please attach a separate sheet with details. Thank you!
PAYMENT INFORMATION:
___CHECK in U.S. funds enclosed, made payable to "ACM ASSETS '94"
___Please charge $ ___________ to my CREDIT CARD:
Card type: ___AMEX ___VISA ___MasterCard
Card # _______________________________________ Expiration Date ___________
Name On Card ______________________________________________________________
Billing Address ___________________________________________________________
Cardholder Signature _______________________________________ (ASSETS '94)
###############################################################################
HOTEL AND TRAVEL ARRANGEMENT INFORMATION
========================================
All conference events will take place at the Doubletree hotel in Marina del Rey
(the precise address is 4100 Admiralty Way, Marina del Rey CA 90292). The hotel
is located just a few minutes from Los Angeles International Airport (LAX).
A block of rooms for attendees of ASSETS '94 has been set aside at a special
discounted rate of $86 per night (single or double), plus applicable taxes. To
reserve space at this price, please call the hotel directly BEFORE OCTOBER 9
at (800) 353 6664 toll free, or (310) 301 3000, and refer to "ACM ASSETS '94".
BIRKMAYER TRAVEL, the official travel agency for ASSETS '94, is offering
discounted airfares to attendees on United, Delta and USAir. The terms vary
for each airline, but in general discounts of up to 50% and more are
available, and no Saturday night stay is required. Please note that the
reduced fares apply only to travel within the continental United States or
originating in Canada, that all prices are subject to change without notice,
and fares are guaranteed only after tickets are actually purchased. Space is
limited, and some restrictions apply. Please call Birkmayer Travel directly
during normal East Coast business hours for further information/reservations:
Birkmayer Travel, Inc.
2 Third Street
Troy, NY 12180
Tel. (800) 338 5735 (continental U.S. and Canada)
(518) 272 2650 (New York State and international)
(518) 272 7257 (fax)
Special discounted rates have also been arranged with HERTZ for attendees who
wish to rent a car. For more information or to make reservations, just call
Hertz Conference Services at 1 (800) 654 2240 and mention CV# 13646
(international attendees please contact your local Hertz office with this
information).
ACM / SIGCAPH MEMBERSHIP APPLICATION
====================================
USE THIS 2-PAGE FORM TO JOIN ACM + SIGCAPH TODAY AND SAVE ON CONFERENCE FEES!
Please mark the appropriate box(es) and indicate total:
___ACM Associate Member Dues $82 (___Expedited Air Option: $32)
___ACM Student Member Dues $25 (___Expedited Air Option: $32)
___Add SIGCAPH to ACM Membership $15 (___Expedited Air Option: $3)
___Add SIGCAPH to ACM Student Membership $6 (___Expedited Air Option: $3)
___SIGCAPH Membership only (non-ACM) $42 (___Expedited Air Option: $3)
ACM Membership No. (if applicable) ____________________ Total due: $__________
Membership in SIGCAPH includes a subscription to Computers and the
Physically Handicapped newsletter (published three times a year) and
discounted registration fees for any ACM sponsored CAPH conferences
and publications.
ACM Membership includes a full year's subscription to Communications
of the ACM, substantial discounts on Publication Subscriptions, Conference
Proceedings, Conference Registration, Special Interest Group (SIG)
Memberships and the Member Value Plus program. You may join as an
Associate Member and convert to Voting Member status by requesting a
"Self Certification" form from ACM's Member Services Department.
Purposes: To advance the sciences and arts of information processing;
to promote the free interchange of information processing among computing
specialists and the public; and to develop and maintain the integrity and
competence of individuals engaged in the practice of information processing.
As an ACM member, I subscribe to the purposes of ACM:
Signature __________________________________________________ (___YES ___NO)
ACM / SIGCAPH MEMBERSHIP APPLICATION (continued)
================================================
Name __________________________________________________________________________
Address ____________________________________ Telephone _______________________
City _______________________________ State/Province __________________________
Country __________________________________ Zip/Postal Code ___________________
E-mail ___________________________________ Fax _______________________________
PAYMENT INFORMATION:
___Check enclosed payable to "ACM, Inc."
___Please charge my Credit Card:
Card type: ___AMEX ___VISA ___MasterCard
Card #__________________________________________Expiration Date____________
Signature_______________________________________________________ (CAPH94)
If you're completing this application online, please e-mail to: ACMHELP at ACM.org
If you're printing this application out, please remit to: ACM
P.O. Box 12115
Church St. Station
New York, NY 10257
USA
For inquiries regarding membership, contact the service center nearest you:
ACM Member Services Department ACM European Service Center
1515 Broadway, 17th Floor Avenue Marcel Thiry 204
New York, NY 10036, USA 1200 Brussels, BELGIUM
Phone: +1-212-626-0500 Phone: +32 2 774 9602
Fax: +1-212-944-1318 Fax: +32 2 774 9690
Email: ACMHELP at ACM.org Email: ACM_EUROPE at ACM.org
WHO ARE THE ORGANIZERS OF ASSETS '94?
====================================
General Chair: Theodor D. Sterling, Simon Fraser University
Program Committee: Norman Alm, University of Dundee
Julie Baca, Waterways Experiment Station
Meera M. Blattner, LLNL and U. California at Davis
James L. Caldwell, IBM RISC Adaptive Technologies
S.-K. Chang, University of Pittsburgh
Patrick Demasco, University of Delaware
Alistair D.N. Edwards, University of York
Gerald L. Engel, National Science Foundation
Carl Friedlander, ISX Corp.
Hiromichi Fujisawa, Hitachi (Japan)
Ephraim P. Glinert (Chair), RPI
Ralph Guertin, MITRE Corp.
Robert J.K. Jacob, Tufts University
David L. Jaffe, Palo Alto VA Medical Center
Earl Johnson, Sun Microsystems Labs
Karen Kukich, Bell Communications Research
Richard E. Ladner, University of Washington
Clayton Lewis, University of Colorado at Boulder
Elizabeth D. Mynatt, Georgia Inst. of Technology
Randy Pausch, University of Virginia
T.V. Raman, DEC Cambridge Research Laboratory
Gregg C. Vanderheiden, TRACE Center at U. Wisconsin
A. Rudy Vener, AT&T Bell Labs
Bryant W. York, Northeastern University
Treasurer: David H. Leserman, NOAA
If you have any questions or would Ephraim P. Glinert
like further information, please Dept. of Computer Science
contact the ASSETS' 94 Program Chair: R. P. I.
Troy, NY 12180
E-mail: glinert at cs.rpi.edu
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04254;
21 Aug 94 19:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04236;
21 Aug 94 19:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11822;
21 Aug 94 19:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04102;
21 Aug 94 19:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04021;
21 Aug 94 19:27 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa11768;
21 Aug 94 19:27 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14486(6)>; Sun, 21 Aug 1994 16:27:51 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 21 Aug 1994 16:27:40 -0700
To: ietf at CNRI.Reston.VA.US, rem-conf at es.net, mbone at isi.edu
Cc: deering at parc.xerox.com
Subject: IPng walkthrough -- change of 'sd' advertisements
Date: Sun, 21 Aug 1994 16:27:31 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <94Aug21.162740pdt.12171 at skylark.parc.xerox.com>
There are now separate 'sd' sessions for the Audio, Video, and Whiteboard
portions of the "IP:NG Design Review" presentations to be given at
10:00 am PDT (1700 GMT) on Monday, Aug 22. The Whiteboard session
currently being advertised is for testing only; we will create a
separate Whiteboard session before the meeting starts, to get a clean
slate.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09231;
22 Aug 94 17:14 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09227;
22 Aug 94 17:14 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa16367;
22 Aug 94 17:14 EDT
Received: by interlock.ans.net id AA11815
(InterLock SMTP Gateway 1.1 for iwg-out at ans.net);
Mon, 22 Aug 1994 16:48:45 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Mon, 22 Aug 1994 16:48:45 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Mon, 22 Aug 1994 16:48:45 -0400
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: bgp at ans.net
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idr-bgp4ospf-interact-07.txt
Date: Mon, 22 Aug 94 16:45:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408221645.aa08890 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Routing Working
Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-idr-bgp4ospf-interact-07.txt
Pages : 19
Date : 08/19/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-idr-bgp4ospf-interact-07.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idr-bgp4ospf-interact-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4ospf-interact-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-bgp4ospf-interact-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09607;
22 Aug 94 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17140;
22 Aug 94 17:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09592;
22 Aug 94 17:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08890;
22 Aug 94 16:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idr-bgp4ospf-interact-07.txt
Date: Mon, 22 Aug 94 16:45:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408221645.aa08890 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Routing Working
Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-idr-bgp4ospf-interact-07.txt
Pages : 19
Date : 08/19/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-idr-bgp4ospf-interact-07.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idr-bgp4ospf-interact-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4ospf-interact-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-bgp4ospf-interact-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09607;
22 Aug 94 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17140;
22 Aug 94 17:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09592;
22 Aug 94 17:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08890;
22 Aug 94 16:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idr-bgp4ospf-interact-07.txt
Date: Mon, 22 Aug 94 16:45:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408221645.aa08890 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Routing Working
Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-idr-bgp4ospf-interact-07.txt
Pages : 19
Date : 08/19/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-idr-bgp4ospf-interact-07.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idr-bgp4ospf-interact-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4ospf-interact-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-bgp4ospf-interact-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09618;
22 Aug 94 17:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09607;
22 Aug 94 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17140;
22 Aug 94 17:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09592;
22 Aug 94 17:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08890;
22 Aug 94 16:45 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idr-bgp4ospf-interact-07.txt
Date: Mon, 22 Aug 94 16:45:50 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408221645.aa08890 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Routing Working
Group of the IETF.
Title : BGP4/IDRP for IP---OSPF Interaction
Author(s) : K. Varadhan, S. Hares, Y. Rekhter
Filename : draft-ietf-idr-bgp4ospf-interact-07.txt
Pages : 19
Date : 08/19/1994
This memo defines the various criteria to be used when designing an
Autonomous System Border Routers (ASBR) that will run either BGP4 or IDRP
for IP with other ASBRs external to the AS and OSPF as its IGP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-idr-bgp4ospf-interact-07.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idr-bgp4ospf-interact-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4ospf-interact-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-bgp4ospf-interact-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940819101431.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03718;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08962;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03652;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03383;
23 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-renwick-hippiip-00.txt
Date: Tue, 23 Aug 94 11:07:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231107.aa03383 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP over HIPPI
Author(s) : J. Renwick
Filename : draft-renwick-hippiip-00.txt
Pages : 29
Date : 08/22/1994
ANSI Standard X3.218-1993 defines the encapsulation of IEEE 802.2 LLC PDUs
and, by implication, IP on HIPPI. ANSI X3.222-1993 describes the operation
of HIPPI physical switches. The ANSI committee responsible for these
standards chose to leave HIPPI networking issues largely outside the scope
of their standards; this document describes the use of HIPPI switches as IP
local area networks.
This draft is a revision of RFC 1374, "IP and ARP on HIPPI", and is
intended to replace it in the Standards Track. RFC 1374 has been
a Proposed Standard since November, 1992, with at least 10 implementations
of IP encapsulation and HIPPI switch discipline. No major changes to it
are required. However, the ARP part of RFC 1374 has not had sufficient
implementation experience to be advanced to Draft Standard. The present
document contains all of RFC1374 except for the description ARP,
which has been moved into a separate document.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-renwick-hippiip-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-renwick-hippiip-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822144711.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-renwick-hippiip-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-renwick-hippiip-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822144711.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03718;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08962;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03652;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03383;
23 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-renwick-hippiip-00.txt
Date: Tue, 23 Aug 94 11:07:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231107.aa03383 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP over HIPPI
Author(s) : J. Renwick
Filename : draft-renwick-hippiip-00.txt
Pages : 29
Date : 08/22/1994
ANSI Standard X3.218-1993 defines the encapsulation of IEEE 802.2 LLC PDUs
and, by implication, IP on HIPPI. ANSI X3.222-1993 describes the operation
of HIPPI physical switches. The ANSI committee responsible for these
standards chose to leave HIPPI networking issues largely outside the scope
of their standards; this document describes the use of HIPPI switches as IP
local area networks.
This draft is a revision of RFC 1374, "IP and ARP on HIPPI", and is
intended to replace it in the Standards Track. RFC 1374 has been
a Proposed Standard since November, 1992, with at least 10 implementations
of IP encapsulation and HIPPI switch discipline. No major changes to it
are required. However, the ARP part of RFC 1374 has not had sufficient
implementation experience to be advanced to Draft Standard. The present
document contains all of RFC1374 except for the description ARP,
which has been moved into a separate document.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-renwick-hippiip-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-renwick-hippiip-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822144711.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-renwick-hippiip-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-renwick-hippiip-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822144711.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03720;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08963;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03651;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03337;
23 Aug 94 11:06 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-renwick-hippiarp-00.txt
Date: Tue, 23 Aug 94 11:06:01 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231106.aa03337 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ARP over HIPPI
Author(s) : J. Renwick
Filename : draft-renwick-hippiarp-00.txt
Pages : 16
Date : 08/22/1994
ANSI Standard X3.218-1993 defines the encapsulation of IEEE 802.2 LLC PDUs
and, by implication, IP on HIPPI. ANSI X3.222-1993 describes the operation
of HIPPI physical switches. The ANSI committee responsible for these
standards chose to leave HIPPI networking issues largely outside the scope
of their standards; this document describes one aspect of the use of HIPPI
switches as IP local area networks.
This draft is part of a split of RFC 1374, "IP and ARP on HIPPI".
RFC 1374 has been a Proposed Standard since November, 1992, with
at least 10 implementations of IP encapsulation and HIPPI switch
discipline. No major changes to it are required. However, the ARP part
of RFC 1374 has not had sufficient implementation experience to be advanced
to Draft Standard. The present document contains the ARP material;
the rest is retained in a separate document that is intended to
remain on the standards track.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-renwick-hippiarp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-renwick-hippiarp-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822144118.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-renwick-hippiarp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-renwick-hippiarp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822144118.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03720;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08963;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03651;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03337;
23 Aug 94 11:06 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-renwick-hippiarp-00.txt
Date: Tue, 23 Aug 94 11:06:01 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231106.aa03337 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ARP over HIPPI
Author(s) : J. Renwick
Filename : draft-renwick-hippiarp-00.txt
Pages : 16
Date : 08/22/1994
ANSI Standard X3.218-1993 defines the encapsulation of IEEE 802.2 LLC PDUs
and, by implication, IP on HIPPI. ANSI X3.222-1993 describes the operation
of HIPPI physical switches. The ANSI committee responsible for these
standards chose to leave HIPPI networking issues largely outside the scope
of their standards; this document describes one aspect of the use of HIPPI
switches as IP local area networks.
This draft is part of a split of RFC 1374, "IP and ARP on HIPPI".
RFC 1374 has been a Proposed Standard since November, 1992, with
at least 10 implementations of IP encapsulation and HIPPI switch
discipline. No major changes to it are required. However, the ARP part
of RFC 1374 has not had sufficient implementation experience to be advanced
to Draft Standard. The present document contains the ARP material;
the rest is retained in a separate document that is intended to
remain on the standards track.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-renwick-hippiarp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-renwick-hippiarp-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822144118.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-renwick-hippiarp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-renwick-hippiarp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822144118.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03729;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08960;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03650;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03292;
23 Aug 94 11:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu, ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-05.txt
Date: Tue, 23 Aug 94 11:03:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231103.aa03292 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-05.txt
Pages : 8
Date : 08/22/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03729;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08960;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03650;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03292;
23 Aug 94 11:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu, ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-05.txt
Date: Tue, 23 Aug 94 11:03:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231103.aa03292 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-05.txt
Pages : 8
Date : 08/22/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03747;
23 Aug 94 11:24 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03718;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08962;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03652;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03383;
23 Aug 94 11:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-renwick-hippiip-00.txt
Date: Tue, 23 Aug 94 11:07:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231107.aa03383 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP over HIPPI
Author(s) : J. Renwick
Filename : draft-renwick-hippiip-00.txt
Pages : 29
Date : 08/22/1994
ANSI Standard X3.218-1993 defines the encapsulation of IEEE 802.2 LLC PDUs
and, by implication, IP on HIPPI. ANSI X3.222-1993 describes the operation
of HIPPI physical switches. The ANSI committee responsible for these
standards chose to leave HIPPI networking issues largely outside the scope
of their standards; this document describes the use of HIPPI switches as IP
local area networks.
This draft is a revision of RFC 1374, "IP and ARP on HIPPI", and is
intended to replace it in the Standards Track. RFC 1374 has been
a Proposed Standard since November, 1992, with at least 10 implementations
of IP encapsulation and HIPPI switch discipline. No major changes to it
are required. However, the ARP part of RFC 1374 has not had sufficient
implementation experience to be advanced to Draft Standard. The present
document contains all of RFC1374 except for the description ARP,
which has been moved into a separate document.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-renwick-hippiip-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-renwick-hippiip-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822144711.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-renwick-hippiip-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-renwick-hippiip-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822144711.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03746;
23 Aug 94 11:24 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03720;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08963;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03651;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03337;
23 Aug 94 11:06 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-renwick-hippiarp-00.txt
Date: Tue, 23 Aug 94 11:06:01 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231106.aa03337 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : ARP over HIPPI
Author(s) : J. Renwick
Filename : draft-renwick-hippiarp-00.txt
Pages : 16
Date : 08/22/1994
ANSI Standard X3.218-1993 defines the encapsulation of IEEE 802.2 LLC PDUs
and, by implication, IP on HIPPI. ANSI X3.222-1993 describes the operation
of HIPPI physical switches. The ANSI committee responsible for these
standards chose to leave HIPPI networking issues largely outside the scope
of their standards; this document describes one aspect of the use of HIPPI
switches as IP local area networks.
This draft is part of a split of RFC 1374, "IP and ARP on HIPPI".
RFC 1374 has been a Proposed Standard since November, 1992, with
at least 10 implementations of IP encapsulation and HIPPI switch
discipline. No major changes to it are required. However, the ARP part
of RFC 1374 has not had sufficient implementation experience to be advanced
to Draft Standard. The present document contains the ARP material;
the rest is retained in a separate document that is intended to
remain on the standards track.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-renwick-hippiarp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-renwick-hippiarp-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.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822144118.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-renwick-hippiarp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-renwick-hippiarp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822144118.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03762;
23 Aug 94 11:24 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03729;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08960;
23 Aug 94 11:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03650;
23 Aug 94 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03292;
23 Aug 94 11:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu, ietf-smtp at dimacs.rutgers.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-05.txt
Date: Tue, 23 Aug 94 11:03:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9408231103.aa03292 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-05.txt
Pages : 8
Date : 08/22/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04296;
23 Aug 94 12:16 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04292;
23 Aug 94 12:16 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa10148;
23 Aug 94 12:16 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA27611; Tue, 23 Aug 94 11:54:05 EDT
Received: from ietf.cnri.reston.va.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA27607; Tue, 23 Aug 94 11:54:04 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03292;
23 Aug 94 11:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce. at CNRI.Reston.VA.US, %cnri.reston.va.us at dimacs.rutgers.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: mailext at cs.wisc.edu, ietf-smtp at dimacs.rutgers.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtp-binary-05.txt
Date: Tue, 23 Aug 94 11:03:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9408231103.aa03292 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-mailext-smtp-binary-05.txt
Pages : 8
Date : 08/22/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mailext-smtp-binary-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtp-binary-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtp-binary-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtp-binary-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940822100739.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07346;
23 Aug 94 16:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16022;
23 Aug 94 16:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07329;
23 Aug 94 16:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07158;
23 Aug 94 15:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15885;
23 Aug 94 15:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29017>; Tue, 23 Aug 1994 12:57:19 -0700
Message-Id: <199408231957.AA29017 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1650 on Ethernet-Like MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 12:57:49 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1650:
Title: Definitions of Managed Objects for
the Ethernet-like Interface Types using SMIv2
Author: F. Kastenholz
Mailbox: kasten at ftp.com
Pages: 20
Characters: 40,484
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing ethernet-like objects.
This RFC is a product of the Interfaces MIB Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823125336.RFC at ISI.EDU>
SEND /rfc/rfc1650.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1650.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823125336.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07346;
23 Aug 94 16:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16022;
23 Aug 94 16:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07329;
23 Aug 94 16:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07158;
23 Aug 94 15:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15885;
23 Aug 94 15:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29017>; Tue, 23 Aug 1994 12:57:19 -0700
Message-Id: <199408231957.AA29017 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1650 on Ethernet-Like MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 12:57:49 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1650:
Title: Definitions of Managed Objects for
the Ethernet-like Interface Types using SMIv2
Author: F. Kastenholz
Mailbox: kasten at ftp.com
Pages: 20
Characters: 40,484
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing ethernet-like objects.
This RFC is a product of the Interfaces MIB Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823125336.RFC at ISI.EDU>
SEND /rfc/rfc1650.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1650.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823125336.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07358;
23 Aug 94 16:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07346;
23 Aug 94 16:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16022;
23 Aug 94 16:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07329;
23 Aug 94 16:01 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07158;
23 Aug 94 15:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa15885;
23 Aug 94 15:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29017>; Tue, 23 Aug 1994 12:57:19 -0700
Message-Id: <199408231957.AA29017 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1650 on Ethernet-Like MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 12:57:49 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1650:
Title: Definitions of Managed Objects for
the Ethernet-like Interface Types using SMIv2
Author: F. Kastenholz
Mailbox: kasten at ftp.com
Pages: 20
Characters: 40,484
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing ethernet-like objects.
This RFC is a product of the Interfaces MIB Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823125336.RFC at ISI.EDU>
SEND /rfc/rfc1650.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1650.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823125336.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07463;
23 Aug 94 16:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16101;
23 Aug 94 16:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07449;
23 Aug 94 16:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07375;
23 Aug 94 16:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16036;
23 Aug 94 16:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29137>; Tue, 23 Aug 1994 13:02:13 -0700
Message-Id: <199408232002.AA29137 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1694 on SMDS Interface Objects
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 13:02:42 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1694:
Title: Definitions of Managed Objects
for SMDS Interfaces using SMIv2
Author: T. Brown & K. Tesink, Editors
Mailbox: tacox at mail.bellcore.com, kaj at cc.bellcore.com
Pages: 35
Characters: 70,856
Obsoletes: 1304
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing objects for SMDS access
interfaces. This RFC is a product of the Interfaces MIB Working Group
of the IETF.
This is now a Draft Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823130014.RFC at ISI.EDU>
SEND /rfc/rfc1694.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1694.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823130014.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07463;
23 Aug 94 16:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16101;
23 Aug 94 16:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07449;
23 Aug 94 16:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07375;
23 Aug 94 16:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16036;
23 Aug 94 16:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29137>; Tue, 23 Aug 1994 13:02:13 -0700
Message-Id: <199408232002.AA29137 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1694 on SMDS Interface Objects
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 13:02:42 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1694:
Title: Definitions of Managed Objects
for SMDS Interfaces using SMIv2
Author: T. Brown & K. Tesink, Editors
Mailbox: tacox at mail.bellcore.com, kaj at cc.bellcore.com
Pages: 35
Characters: 70,856
Obsoletes: 1304
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing objects for SMDS access
interfaces. This RFC is a product of the Interfaces MIB Working Group
of the IETF.
This is now a Draft Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823130014.RFC at ISI.EDU>
SEND /rfc/rfc1694.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1694.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823130014.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07474;
23 Aug 94 16:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07463;
23 Aug 94 16:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16101;
23 Aug 94 16:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07449;
23 Aug 94 16:04 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07375;
23 Aug 94 16:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16036;
23 Aug 94 16:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29137>; Tue, 23 Aug 1994 13:02:13 -0700
Message-Id: <199408232002.AA29137 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1694 on SMDS Interface Objects
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 13:02:42 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1694:
Title: Definitions of Managed Objects
for SMDS Interfaces using SMIv2
Author: T. Brown & K. Tesink, Editors
Mailbox: tacox at mail.bellcore.com, kaj at cc.bellcore.com
Pages: 35
Characters: 70,856
Obsoletes: 1304
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing objects for SMDS access
interfaces. This RFC is a product of the Interfaces MIB Working Group
of the IETF.
This is now a Draft Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823130014.RFC at ISI.EDU>
SEND /rfc/rfc1694.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1694.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823130014.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07598;
23 Aug 94 16:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16189;
23 Aug 94 16:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07566;
23 Aug 94 16:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07491;
23 Aug 94 16:05 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16138;
23 Aug 94 16:05 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29183>; Tue, 23 Aug 1994 13:05:50 -0700
Message-Id: <199408232005.AA29183 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1697 on RDBMS-MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 13:06:20 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1697:
Title: Relational Database Management System (RDBMS)
Management Information Base (MIB) using SMIv2
Author: D. Brower, Editor, B. Purvy, RDBMSMIB Working
Group Chair, A. Daniel, M. Sinykin & J. Smith
Mailbox: daveb at ingres.com, bpurvy at us.oracle.com,
anthony at informix.com, msinykin at us.oracle.com,
jaysmith at us.oracle.com
Pages: 38
Characters: 76,202
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
relational database (RDBMS) implementations. This RFC is a product of
the Relational Database Management Systems MIB Working Group of the
IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823130403.RFC at ISI.EDU>
SEND /rfc/rfc1697.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1697.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823130403.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07598;
23 Aug 94 16:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16189;
23 Aug 94 16:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07566;
23 Aug 94 16:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07491;
23 Aug 94 16:05 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16138;
23 Aug 94 16:05 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29183>; Tue, 23 Aug 1994 13:05:50 -0700
Message-Id: <199408232005.AA29183 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1697 on RDBMS-MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 13:06:20 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1697:
Title: Relational Database Management System (RDBMS)
Management Information Base (MIB) using SMIv2
Author: D. Brower, Editor, B. Purvy, RDBMSMIB Working
Group Chair, A. Daniel, M. Sinykin & J. Smith
Mailbox: daveb at ingres.com, bpurvy at us.oracle.com,
anthony at informix.com, msinykin at us.oracle.com,
jaysmith at us.oracle.com
Pages: 38
Characters: 76,202
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
relational database (RDBMS) implementations. This RFC is a product of
the Relational Database Management Systems MIB Working Group of the
IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823130403.RFC at ISI.EDU>
SEND /rfc/rfc1697.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1697.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823130403.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07610;
23 Aug 94 16:08 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07598;
23 Aug 94 16:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16189;
23 Aug 94 16:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07566;
23 Aug 94 16:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07491;
23 Aug 94 16:05 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa16138;
23 Aug 94 16:05 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA29183>; Tue, 23 Aug 1994 13:05:50 -0700
Message-Id: <199408232005.AA29183 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1697 on RDBMS-MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 23 Aug 94 13:06:20 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1697:
Title: Relational Database Management System (RDBMS)
Management Information Base (MIB) using SMIv2
Author: D. Brower, Editor, B. Purvy, RDBMSMIB Working
Group Chair, A. Daniel, M. Sinykin & J. Smith
Mailbox: daveb at ingres.com, bpurvy at us.oracle.com,
anthony at informix.com, msinykin at us.oracle.com,
jaysmith at us.oracle.com
Pages: 38
Characters: 76,202
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
relational database (RDBMS) implementations. This RFC is a product of
the Relational Database Management Systems MIB Working Group of the
IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
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
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: <940823130403.RFC at ISI.EDU>
SEND /rfc/rfc1697.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1697.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940823130403.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11918;
23 Aug 94 22:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23688;
23 Aug 94 22:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11909;
23 Aug 94 22:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10810;
23 Aug 94 22:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23548;
23 Aug 94 22:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10804;
23 Aug 94 22:23 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: RDBMS MIB Working Group (rdbmsmib) to Conclude
Date: Tue, 23 Aug 94 22:23:28 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408232223.aa10804 at IETF.CNRI.Reston.VA.US>
With the publication of "Relational Database Management
System (RDBMS) Management Information Base (MIB) using SMIv2"
(RFC 1697), the Relational Database Management System MIB
Working Group of the Network Management Area of the IETF has
concluded. The mailing list will remain active. The IESG
contact person is Marshall T. Rose.
IESG Secretary
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11918;
23 Aug 94 22:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23688;
23 Aug 94 22:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11909;
23 Aug 94 22:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10810;
23 Aug 94 22:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23548;
23 Aug 94 22:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10804;
23 Aug 94 22:23 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: RDBMS MIB Working Group (rdbmsmib) to Conclude
Date: Tue, 23 Aug 94 22:23:28 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408232223.aa10804 at IETF.CNRI.Reston.VA.US>
With the publication of "Relational Database Management
System (RDBMS) Management Information Base (MIB) using SMIv2"
(RFC 1697), the Relational Database Management System MIB
Working Group of the Network Management Area of the IETF has
concluded. The mailing list will remain active. The IESG
contact person is Marshall T. Rose.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11929;
23 Aug 94 22:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11918;
23 Aug 94 22:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23688;
23 Aug 94 22:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11909;
23 Aug 94 22:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10810;
23 Aug 94 22:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23548;
23 Aug 94 22:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10804;
23 Aug 94 22:23 EDT
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: RDBMS MIB Working Group (rdbmsmib) to Conclude
Date: Tue, 23 Aug 94 22:23:28 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9408232223.aa10804 at IETF.CNRI.Reston.VA.US>
With the publication of "Relational Database Management
System (RDBMS) Management Information Base (MIB) using SMIv2"
(RFC 1697), the Relational Database Management System MIB
Working Group of the Network Management Area of the IETF has
concluded. The mailing list will remain active. The IESG
contact person is Marshall T. Rose.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18952;
24 Aug 94 2:19 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18942;
24 Aug 94 2:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26760;
24 Aug 94 2:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18930;
24 Aug 94 2:18 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18896;
24 Aug 94 2:16 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa26739;
24 Aug 94 2:16 EDT
Received: from fpsp.fapesp.br by venera.isi.edu (5.65c/5.61+local-18)
id <AA28106>; Tue, 23 Aug 1994 23:16:49 -0700
Received: from vn-gateway by fpsp.fapesp.br with PMDF#10108; Wed, 24 Aug 1994
03:11 BSC (-0300 C)
Received: by bra000.canal-vip.onsp.br (UUPC/extended UUPCV) Tue, 23 Aug 1994
18:20:12 C
Date: Tue, 23 Aug 1994 18:20:12 C
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: HIRACLIS NICOLAIDIS <hiraclis at bra000.canal-vip.onsp.br>
Subject: ietf
To: informacoes sobre ietf <ietf at isi.edu>
Reply-To: hiraclis at bra000.canal-vip.onsp.br
Message-Id: <00000DC3 at bra000.canal-vip.onsp.br>
X-Envelope-To: ietf at venera.isi.edu
Dear Sir,
I would like to receive information about IETF.
Sincerely yours,
Hiraclis Nicolaidis Junior
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00743;
24 Aug 94 5:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00733;
24 Aug 94 5:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02020;
24 Aug 94 5:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00719;
24 Aug 94 5:31 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00650;
24 Aug 94 5:17 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01867;
24 Aug 94 5:17 EDT
Received: from rcsun1.aaf.alcatel.at by venera.isi.edu (5.65c/5.61+local-18)
id <AA01666>; Wed, 24 Aug 1994 02:16:59 -0700
Received: from rcsw64 by rcsun1.aaf.alcatel.at (4.1/SMI-4.1/RC-%I%/main)
id AA00308; Wed, 24 Aug 94 11:14:43 +0200
Date: Wed, 24 Aug 94 11:14:43 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Helmut Leopold <lan_leop at aaf.alcatel.at>
Message-Id: <9408240914.AA00308 at rcsun1.aaf.alcatel.at>
To: ietf at isi.edu
Subject: Cost237 Workshop - Advance Program
Dear Colleague,
Please find enclosed the program of the COST237 workshop on
"Multimedia Transport and Teleservices"
to be held in Vienna, November 13-14, 1994.
Apologies for any inconvenience caused by multiple receipt of this
message, or if you are not interested on this subject. However, it
would be very helpful, if you could forward this announcement to
anyone who might be interested on this subject.
Thank you very much for your cooperation,
with best regards,
Helmut Leopold
(local organiser of the COST 237 Workshop)
==============================================================================
Helmut LEOPOLD
Alcatel Austria AG tel: +431 29 121 / 184
Ruthnergasse 1-7 fax: +431 29 21 452
A-1210 VIENNA, AUSTRIA e-mail: H.Leopold at aaf.alcatel.at
==============================================================================
International COST 237 Workshop on
MULTIMEDIA TRANSPORT AND TELESERVICES
ADVANCE PROGRAM
November 13th-15th, 1994
Vienna Marriott Hotel, Parkring 12 a,
A-1010 Vienna, Austria
=================================================================
Program Chairman
David Hutchison Lancaster University, UK (Chair)
Program Committee
Jon Crowcroft UCL, UK
Andre Danthine U. of Liege, Belgium
Michel Diaz LAAS/CNRS, France
Christophe Diot INRIA, France
Domenico Ferrari U. of California, USA
Serge Fdida U. of Paris, France
Gary Herman Bellcore, USA
Andrew Lister Queensland U., Australia
Craig Partridge BBN, USA
Joe Pasquale UCSD, USA
Steve Pink SICS, Sweden
Bernhard Plattner ETH Zurich, Switzerland
R. Popescu-Zeletin GMD-Fokus, Germany
Otto Spaniol Aachen U., Germany
Jean-Bernard Stefani CNET, Paris, France
Ralf Steinmetz IBM ENC, Germany
Harmen van As IBM Zurich Research, Switzerland
Giorgio Ventre U. of Napoli, Italy
STEERING COMMITTEE
Andre Danthine U. of Liege, Belgium (Chair)
Christophe Diot INRIA, France
David Hutchison Lancaster University, UK
Svend Jager JYDSK, Denmark
Helmut Leopold Alcatel, Austria
Vassili Loumos NTUA, Greece
Andonis Galetsas CEC, Brussels
R. Popescu-Zeletin GMD-Fokus, Germany
Melanie Pralong Swiss Telecom, Switzerland
Sandor Stefler PKI, Hungary
Giorgio Ventre U. of Napoli, Italy
ORGANISING COMMITTEE
Helmut Leopold Alcatel, Austria (Chair)
Geoff Coulson Lancaster U., UK
Gabriela Wuerth Alcatel, Austria
Franz Edler Alcatel, Austria
Eike Wolf Alcatel, Austria
Gerhard Weiss Comms. Services, Austria
=================================================================
Foreword
Although many distributed multimedia applications now exist as pilot
projects on local networks, these prototypes have yet to be translated
into realistic applications running over large scale heterogeneous high-speed
networks. To help bring about this important transition, a number of
initiatives such as the COST 237 Multimedia Telecommunications Services
project in Europe and the Multimedia Communications Forum in the US
have recently been established. These groups identify a lack of generic
system support as the primary technological factor holding back the
deployment of realistic, large scale, distributed multimedia applications.
There are two basic technologies required to make feasible such support: an
appropriate transport service for communications needs, and a suitable set
of generic multimedia teleservices to provide a framework for application
development.
It is now accepted that significant enhancements to existing transport
services are needed to adequately support large scale distributed
multimedia applications. In particular, the transport service must be
extended to support quality of service configurability and multicast/
multipeer connectivity, and must be supported by a variety of high-speed
network architectures. The area of multimedia teleservices is equally
crucial. Generic high level services, such as multimedia enhanced email,
conferencing frameworks and shared application frameworks, are necessary
to ease the evolution from present day pilot applications to commercial,
inter-operable, products. The workshop will address both of these
technological areas with particular attention paid to the integration of
the two. The emphasis of the workshop will be on service and
architectural aspects of distributed multimedia application support from
the transport layer upwards.
In total, 46 papers were received from 14 countries. Following the
review procedure, the program committee selected 18 papers to be presented at
the workshop, and 6 papers to be presented at a poster/demo session to
be held at the workshop.
Two well known invited speakers will complete the workshop program.
This workshop is organised by the CEC COST 237 Multimedia Telecommunications
Services Project and hosted by Alcatel Austria AG.
It is particularly pleasing to be able to hold this first COST 237 Workshop
in Vienna, a communications and cultural centre in Europe for so many
centuries and the capital of the most recent country to agree to join the
European Union. Vienna was the residence of the Habsburg Dynasty and is still
a modern metropolis at the heart of Europe. It is one of the three centres
of the United Nations and one of the most sought-after conference venues
anywhere in the world.
Looking forward to meeting you at the COST237 workshop'94 in Vienna.
David Hutchison, Lancaster University, Conference Chairman
====================================================================
Workshop Preliminary Program
========================
Sunday November 13, 1994
========================
20:00-22:00 Get-together party
========================
Monday November 14, 1994
========================
8:00-18:00 Welcome Desk, Registration
9:00 - 10:15 Opening Session
Chairperson: David Hutchison, University of Lancaster (UK)
Welcome
Keynote Address: Dir. Roland Hueber, Commission of the European
Union, DG XIII/B: Advanced Communication Technologies and Services,
Brussels (B)
10:15 - 10:45 Break
10:45 - 12:15 Session A: Teleservices: Multimedia Mail, Archiving and Retrieving
Chairperson: Radu Popescu-Zeletin, GMD-Fokus, (D)
Towards a Complete Multimedia Mail: Use of MHEG in Standard Messaging Systems,
B. Kervella, Universite Paris, Laboratoire MASI (F)
A Mail-Based Teleservice Architecture for Archiving and Retrieving
Dynamically Composable Multimedia Documents,
H. Thimm, K. Rohr, GMD-IPSI and GMD-Fokus (D)
The Global Store Server - A Multimedia Teleservice Component,
C. Blum, L. Neumann, Fraunhofer Institut (D)
12:15 - 13:45 Lunch
13:45 - 14:45 Invited speaker
Chairperson: Andre Danthine, Universite de Liege (B)
14:45 - 15:45 Session B - Part 1: Teleservice Support
Chairperson: Geoff Coulson, University of Lancaster (UK)
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
