[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
- Ftp.netcom.com: pub/lynn.
I've just in the process of generating a HTML-formated report of
various pieces of information in the knowledge base (as well as adding
some more rule checking ... check reference in latest
file://ftp.netcom.com/pub/lynn/rfctest2.html as to differences between
what I've generated and the same information in rfc1600.
A simple example is the term index now in rfctest2.html. When loading
various glossories, I distinquish between term/phrases and acronyms.
The term/phrases have "relationships" built between them and their
corresponding definition(s). In addition there is a
Expands/Abbreviates semantic relationship between acronyms and their
corresponding term/phrases. In generating the term index, anytime
there is an "acronym" associated with a RFC title ... the
corresponding term/phrase is substituted (for the report).
Unfortunately, at this time, when an acronym maps to multiple terms
(i.e. BER maps to both bit-error-rate and basic-encoding-rules) there
is insufficient information to choose.
Of course it would be possible to write a rule that creates a new type
of semantic relationship between an RFC and a term ... and insert it
appropriately into the database (whenever a title "Contains" the
term/phrase/acronym). Another example would be to define non-term
phrases (somewhat in the class of acronyms) that map to an official
IETF term. One example would be the equivalence between the RFC title
series with "Privacy Enhancement for Internet Electronic Mail" and the
term "Privacy Enhanced Mail".
In any case, I've also been thinking about doing something similar
with the internet drafts ... fixing up a demon periodic check
ds.internic.net for new drafts and snarf them off as they appear,
suitably parse the drafts, and then do various rule checking and
report generation.
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25564;
24 Apr 94 19:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25547;
24 Apr 94 19:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02329;
24 Apr 94 19:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25527;
24 Apr 94 19:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25494;
24 Apr 94 19:21 EDT
Received: from uucp5.netcom.com by CNRI.Reston.VA.US id aa02269;
24 Apr 94 19:21 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id QAA28646; Sun, 24 Apr 1994 16:17:32 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA22169; Sun, 24 Apr 1994 16:14:09 -0700
Date: Sun, 24 Apr 1994 16:14:09 -0700
Message-Id: <9404242314.AA22169 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: updated experimental RFC HTML
Reply-To: Lynn Wheeler <lynn at bli.com>
I've now updated rfctest2 with "standards" index and a "term" index
(in addition to the RFC index and the author index).
the standards index is effectively the rfc1600 information with
some modification (read prefix to the standards section)
the "term" index is a combination of acronyms and glossory terms found
in the titles of RFCs (for the output the acronyms were mapped to
their respective terms and RFC lists combined). this could
use some amount of work cleaning it up.
the file has grown by about 50kbytes to slightly over 500kbytes.
ftp://ftp.netcom.com/pub/lynn/rfctest2.html
note that ftp.netcom.com has a ftp/anon load limit. if actually
ftp'ing in, one would see a message about exceeding the limit and
possibly trying netcom1.netcom.com, netcom2.netcom.com,
netcom3.netcom.com, ..., &/or netcom13.netcom.com.
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26364;
24 Apr 94 21:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26354;
24 Apr 94 21:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03868;
24 Apr 94 21:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26343;
24 Apr 94 21:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26319;
24 Apr 94 21:22 EDT
Received: from uucp5.netcom.com by CNRI.Reston.VA.US id aa03852;
24 Apr 94 21:22 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id SAA14417; Sun, 24 Apr 1994 18:20:06 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA28170; Sun, 24 Apr 1994 17:42:50 -0700
Date: Sun, 24 Apr 1994 17:42:50 -0700
Message-Id: <9404250042.AA28170 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: experimental RFC HTML index
Reply-To: Lynn Wheeler <lynn at bli.com>
.... if anybody wants to send me references as to "faces" gif
files that correspond with rfc author names .... i can add that
to my database associated with each author ... and generate
the appropriate magic in future version of the html file?????
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07125;
25 Apr 94 6:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07115;
25 Apr 94 6:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10723;
25 Apr 94 6:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07099;
25 Apr 94 6:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07014;
25 Apr 94 6:43 EDT
Received: from daiduk.kaist.ac.kr by CNRI.Reston.VA.US id aa10674;
25 Apr 94 6:43 EDT
Received: from maruchi.chungnam.ac.kr ([192.132.251.36]) by daiduk.kaist.ac.kr (4.1/KAISTNet-Relay-3.2)
id AA25059; Mon, 25 Apr 94 19:36:08 KST
Received: from comsun.chungnam.ac.kr by maruchi.chungnam.ac.kr (4.1/SMI-4.1)
id AA18896; Mon, 25 Apr 94 19:40:12 KST
Received: from ghil ([192.132.248.160]) by comsun.chungnam.ac.kr (4.1/SMI-4.1)
id AA24453; Mon, 25 Apr 94 19:43:17 KST
Date: Mon, 25 Apr 94 19:43:16 KST
Message-Id: <9404251043.AA24453 at comsun.chungnam.ac.kr>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dae Young KIM <dykim at comsun.chungnam.ac.kr>
To: ietf at CNRI.Reston.VA.US
Subject: Unsubscribe
Please drop my name from the ietf mailing list. Thanks.
Kim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11408;
25 Apr 94 11:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11398;
25 Apr 94 11:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16582;
25 Apr 94 11:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11386;
25 Apr 94 11:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11272;
25 Apr 94 11:06 EDT
Received: from relay.surfnet.nl by CNRI.Reston.VA.US id aa16517;
25 Apr 94 11:05 EDT
Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP)
id <29543-0 at relay.surfnet.nl>; Mon, 25 Apr 1994 16:03:54 +0200
Received: from [192.87.30.20] (macewan.rare.nl) by erasmus.rare.nl (5.65c/4.31)
with SMTP id AA21481; Mon, 25 Apr 1994 16:02:08 +0200
Message-Id: <199404251402.AA21481 at erasmus.rare.nl>
X-Mail-Interface: Macintosh Eudora (Ac.Comp.Centr.Utrecht)
Date: Mon, 25 Apr 1994 15:02:48 +0100
To: coa at rare.nl, wg-all at rare.nl, newsletters at rare.nl, ceec at rare.nl,
M2107 at eurokom.ie, tcp-ip at nic.ddn.mil, iepg at nri.reston.va.ua,
ietf at nri.reston.va.us, ccirn at lbl.gov, apccirn at aarnet.edu.au,
ripe at ripe.net
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: kiers at rare.nl
Subject: INET'94/JENC5 Preliminary Programme - version 3 -
X-Attachments: :Judith Kiers:8110:PP-new:
- Version 3 -
(Apologies if you receive this more than once)
PRELIMINARY PROGRAMME AND INVITATION
- INET'94/JENC5 -
INET'94, the Annual Conference of the Internet Society
held in conjuction with the
5th Joint European Networking Conference (JENC5)
Prague, Czech Republic, June 13-17, 1994
Jointly organized by
The Internet Society (ISOC) and
Reseaux Associes pour la Recherche Europeenne (RARE)
ORGANIZATION:
CONFERENCE Committee
Chair...............................Geoff Manning, Independent consultant,
....................................UK
Co-ordination & Assistance..........Marieke Dekker, RARE, The Netherlands
....................................Elizabeth Barnhart, EDUCOM, USA
Local Organizers....................Jan Gruntorad, CVUT, Czech Republic
....................................Ingrid Ledererova, CVUT, Czech Republic
Internet Society Liaison............Larry Landweber, University of
....................................Wisconsin, USA
RARE Liaison........................Tomaz Kalin, RARE, The Netherlands
Programme Committee Chair...........Bernhard Plattner, ETH Zurich,
....................................Switzerland
Workshop Liaison....................George Sadowsky, University of
....................................New York, USA
PROGRAMME Committee
Chair...............................Bernhard Plattner, ETH Zurich,
....................................Switzerland
Co-chair............................Hannes Lubich, SWITCH, Switzerland
Co-ordination & Assistance..........Judith Kiers, RARE, The Netherlands
Track Leaders:
T1. User Support and Training.......Jill Foster, University of Newcastle,
....................................UK
....................................Joyce Reynolds, ISI, USA
T2. Distributed Applications........Erik Huizer, SURFnet, The Netherlands
....................................Barry Leiner, USRA, USA
T3. Policy Issues...................Michael Roberts, EDUCOM, USA
....................................Jurgen Harms, University of Geneva,
....................................Switzerland
T4. Regional Issues.................Richard Mandelbaum, NYSERNet, USA
T5. Network Engineering.............Elise Gerich, Merit Network Inc., USA
....................................Peter Elford, Cisco Systems, Australia
T6. Network Technology..............Paul Mockapetris, ISI, USA
....................................Juha Heinanen, FUNET, Finland
CONFERENCE SPONSORS (USD 25,000.- and above)
BT (British Telecommunications plc), Cisco, IBM, MCI, Novell,
Sun Microsystems, 3COM
CONFERENCE CONTRIBUTORS (USD 10,000.- to USD 24,999.-)
Advantis, AT&T, Bellcore, Digital Equipment Corporation, Interop,
Newbridge, Telekom.
(Please note: The technical content of the programme is subject to change)
WEDNESDAY, JUNE 15
09:00-10:30.......Opening Session
..................Welcome & Keynote Addresses
......Keynote Speakers:
......- Mr. George Soros, Founder of the Soros Foundation, New York, USA
......- Professor Petr Pitha, PhD, Minister of Education, Czech Republic
......- Professor Emanuel Ondracek, PhD, Deputy Minister of Education,
........Czech Republic
..................Chair: Geoff Manning, UK
11:00-12:30.......Parallel Sessions
T1-1. Training for the Network Citizen
......Chair: Peter Kemp, University of Glasgow, Scotland
- Internet training developments: An Australian perspective /
Jim Cleary, AUS
- Approaches to network training with particular reference to
a perceived need for self-help materials / Margaret Isaacs, UK
T2-1. MultiMedia (first session)
......Chair: Chris Adie, Edinburgh University Computing Service, UK
- FOCS - Flexibility Oriented teleCommunication System /
Jens-Peter Redlich, Germany
- HTML and Mosaic: A taste for more / Peter Linde, The Netherlands
- Developments in WWW technology / Dave Raggett, UK
T3-1. National and Regional Policies
......Chair: Tomaz Kalin, RARE, The Netherlands
- The European Commission RTD networking strategy /
Luis Rodriguez Rosello, DG XIII C/3, EU
- Policy issues from a Pacific perspective /
Geoff Huston, Australia
- USA policy update / Stephen Wolff, USA
- Policies required for the Internet development /
Vinton G. Cerf, USA
T4-1. Networking assists Societal Stability
......Chair: Steve Goldstein, National Science Foundation, USA
- The role of the Internet in distance education: the Russian experience /
Peter Thomas, USA
- Marketing the Internet to the industrial R & D sector in Israel /
Dov Winer, Israel
T5-1. Routing and Addressing
......Chair: Elise Gerich, Merit Network Inc. Ann Arbor, Michigan, USA
- Comparison of geographical and provider-rooted Internet addressing /
Paul Francis, Japan
- Authority and routing registration for CLNS networks / Henk Steenman,
The Netherlands and Marcel Wiget, Switzerland
- Rough Cuts - CDIR Deployment / Bill Manning, USA
T6-1. ATM Standardization and Deployment: Current Status and Issues
......Chair: Les Clyne, JNT, UK
This session is a tutorial-type presentation on ATM. It will discuss the
latest technology announcements, deployment and standardization timeframe
projections and needs from application providers.
Presentation by: Fred Sammartino, President ATM Forum, USA
14:00-15:30.......Plenary Session
..................Overview: Technical Programs of the IETF and RARE
........................Introduction by:
........................- Vinton G. Cerf, President of ISOC
........................- Kees Neggers, President of RARE
..................Chair: Erik Huizer, SURFnet, The Netherlands
16:00-18:00.......Parallel Sessions
T1-2. Network Information: Tools and Access
......Chair: David Sitman, EARN, France
- Mosaic, WWW and networked Multimedia as a learning tool /
..Michael Greenhalgh, Australia
- Becoming an information provider on the WWW / Brian Kelly, UK
- Overview of the current network information tools / Chris Weider, USA
T2-2. Internet Usage and Dial-up Access
......Chairs: Hariharasubrahmanian Shrikumar, Temporal Systems, India /
..............Archie Marshall, Jamaica
- Connecting the Carribean area / Archie Marshall, Jamaica
- Multimedia on low bandwidth / H. Shrikumar, India
- The growth of IP usage at Chrysler / Robert Moskowitz, USA
T3-2. International Coordination of Internet Standards.
......Chair: Lyman Chapin, Bolt Beranek and Newman, USA
A panel discussion of the cluster of issues around evolution of OSI and IP
protocols in the international policy context.
T4-2. Regional Developments I - Eastern Europe and CIS
......Chair: Frode Greisen, UNI-C Lyngby, Denmark
- The Romanian national academic network: The regional node of CLUJ
-NAPOCA / Kalman Pusztai, Vasile Dadarlat and Marius Joldos, Rumania
- Satellite link Moscow-Maribor: The aims and the prospective /
Slobodanka Vidakovic, Slovenia and Dmitry Demidov, CIS
- Networking for science and education in Byelorussia /
Andrey Ivanov and Sergei Kritsky, CIS
- Coordinating networks in Central and Eastern Europe: CEENet /
Peter Rastl, Austria
- Russian networks and services, general and subject oriented /
Nikolai Repin, CIS
T5-2. Performance Analysis
......Chair: Olivier Martin, CERN, Switzerland
- Optimising FTP traffic in the Internet / K. Jayanthi, G. Mansfield,
Y.Kimura, T. Johannsen, Y. Nemoto and S. Noguchi, Japan
- Internet interaction pinged and mapped / John S. Quarterman, Smoot
Carl-Mitchell and Gretchen Phillips, USA
- Windowed Ping: An IP layer performance disgnostic / Matt Mathis, USA
T6-2. Broadband Technology
......Chair: Jaap van Till, Consultancy Group Stratix BV, The Netherlands
- VINCE - A Vendor Independent Network Control Environment /
Allison Mankin and Eric Hoffman, USA
- Sorting out reality from the hype: Why you should be interested
in ATM WANs / Milo Medin, USA
- Bay area broadband testbeds and technology /
Mark Laubach and Berry Kercheval, USA
20:00-23:00.......Gala Dinner
THURSDAY, JUNE 16
09:00-10:30.......Parallel Sessions
T1-3. Electronic Documents
......Chair: Maria Heijne, SURFnet BV, Netherlands
- From Babel to Edil: The evolution of a standard / Andrew Braid, UK
- Work in Progress:
......- ELDORADOC 'the promised land of gold?' / Robert Janz,
........The Netherlands
......- RED SAge / Czeslaw Jan Grycz , USA
......- Networked delivery of Multimedia resources / Jane Williams, UK
......- Discussion
T3-3. European CERT Activities
......Chair: Hannes Lubich, SWITCH, Switzerland
- The DFN-CERT experience: Building up a new CERT within Europe /
Klaus-Peter Kossakowski, Germany
- Current development of CERTs in Europe: A progress report /
Barry Spaul, UK
T4-3. Regional Developments II - Pacific Rim and Latin America
......Chair: Richard Mandelbaum, NYSERnet, USA
- Chilean network for primary schools / Ernesto Laval, Pedro E. Hepp
and Enrique Hinostroza, Chile
- Electronic networking: Social and policy aspects of a rapidly growing
technology / Daniel Ingvarson, Dora Marinova and Peter Newman, Australia
- Issues in academic networking in the PRC / Franklin F. Kuo, Jian Ding,
Cindy Zheng and Farooq Hussain, USA
- An Internet project for 100.000 users in Thailand / Srisakdi Charmonman
and Firouz Anaraki, Thailand
T5-3. Heterogeneous Networks
......Chair: Toshiya Asaba, Internet Initiative Japan, Inc., Japan
- GeNeRIC: Living multi-protocols for years. So what? / Manfred Bogen,
Germany
- The INFNet distributed gateway system / P. Bonetti, Italy
T6-3. Broadband deployment and experiments
......Chair: Mark Laubach, HP Labs, USA
- Overview of US testbeds / Darleen Fisher, and Mike StJohns, USA
- Implementation of a B-ISDN/ATM connectionless data service in an
Internet environment / Nail Kavak, Kim Laraqui, Ala Nazari and Patrick
Ernberg, Sweden
- BALI - Integration of inhouse ATM and LANs/WANs: An ideal base for
Multimedia teleservices / Hermann Hartenthaler, Dirk Hetzer and Berthold
Butscher, Germany
11:00-12:30.......Parallel Sessions
T1-4. Building and Supporting Electronic Communities
......Chair: David Conrad, Asia Pacific Network Information Center, Japan
- Rural datafication: A multiple-network collaboration to extend the
Internet to underserved communities / E. Michael Staman, John Hankins,
Paul Holbrook and Rhana Jacot, USA
- Building electronic communities: Implementing electronic communication
within the European Law Students' Association (ELSA ) /
Christian B. Fulda, Switzerland
- The Internet and schools: A survey of networking activities /
Tracy LaQuey Parker, USA
T2-4. Networked Simulation and Virtual Reality
......Chair: Mark Pullen, George Mason University, USA
- Distributed Virtual Simulation / Duncan Miller, USA
- Extending WWW to support Platform Independent Virtual Reality /
Dave Raggett, UK
- Internetting Distributed Virtual Simulation / Mark Pullen, USA
T3-4. The Economics of Networks and Network Growth
......Chair: Robert Cohen, Fellow Strategy Institute, USA
- From SWITCH to SWITCH* - extrapolating from a case study /
Jurgen Harms, Switzerland
- Funding an Internet public good: Definitions and example /
Martyne Hallgren, USA
- The changing Internet landscape: A six-year perspective from NSFNET data
..Eric Aupperle and Ellen Hoffman, USA
T4-4. Internationalization of Network Applications
......Chair: Borka Jerman-Blazic, J. Stefan Institute, Ljubljana, Slovenia
- A tool supporting the Internationalisation of the generic network
services / Borka Jerman-Blazic, Slovenia
- Creating an Internet-enhanced directory of Central and Eastern European
environmental libraries / Czeslaw Jan Grycz, USA
- Writing your own language in X.400 messages / Harald Alvestrand, Norway
T5-4. Joint Videoconference with EEMA
......Chair: Jeroen Houttuin, RARE, The Netherlands
Electronic mail has been one of the main applications of the Internet and
international networking in general. This session will establish a live
link between the participants of the Annual Conference of the European
Electronic Messaging Association (EEMA), to be held in Stockholm, Sweden,
and Internet experts and interested participants of INET'94/JENC5.
T6-4. Mobility
......Chair: Charles Perkins, T.J. Watson Research Center IBM, USA
- An ISO IP protocol suite for the integrated road transport and traffic
mobile environment / Kim Laraqui, Magnus Lengdell, Frank Reichert and
Andreas Fasbender, Sweden
- The Internet mobile host protocol /
Charles E. Perkins, Andrew W. Myles and David B. Johnson, USA
- IP/Secure: Providing security on datagram delivery for mobile host
environment / Takeshi Tanida and Yoichi Shinoda, Japan
14:00-15:30.......Parallel Sessions
T1-5. Panel: Power to the User! Enabling users to help themselves
......Chair: Rolf Nordhagen, University of Oslo Information Technology
.............Services, Norway
To provide support for the increasing numbers of users on the network is a
formidable task. This session will be run as a panel discussion with expert
panelists from around the world sharing their knowledge and experience.
Audience participation is highly encouraged.
T2-5. MultiMedia (second session)
......Chair: John Dyer, Joint Network Team (JANET), UK
- Remote seminars through Multimedia conferencing: Experiences from the
MICE project / Ulf Bilting, Angela Sasse, Claus-Dieter Schulz and
Thierry Turletti, Sweden
- Experience with large videoconferences on Xunet II / S. Keshav, USA
- NTTs strategy for highspeed Multimedia communications /
Akihiro Shimizu and Hisao Uose, Japan
T3-5. Privacy
......Chair: David Farber, University of Pennsylvania, USA
- Electronic privacy legislation in the USA / Marc Rotenberg, USA
- Principles of Internet privacy / Frank Tuerkheimer, USA
T4-5. Regional Developments III - Africa and the Middle East
......Chair: Mondher Makni, Tunisia
An update on recent developments in the organization and operation of
national and regional networks in Africa and the Middle East.
T5-5. Quality Assurance
......Chair: Manfred Bogen, GMD, St. Augustin, Germany
- Assessing quality from an Internet service provider /
Peter Dawe, UK
- There is no such thing as a free Internet / Dai Davies, UK
- Quality aspects of network security evaluations /
Gerald Krummeck, Germany
T6-5. IPng: State of the art and process
.....Chair: Allison Mankin, NRL, USA
- Report from the IPng directorate / Scott Bradner, USA - IPng
- A vendor's perspective / Stev Knowles, USA
- ATM and IPng / Fred Sammartino, USA
16:00-17:30.......Plenary Session
..................Panel discussion on 'Industry and the Internet'
..................Chair: Geoff Manning, UK
The interest of the industry in the Internet - both as a resource and as a
marketplace - has grown tremendously in the last few years. The panel will
explore issues, requirements and future developments as seen from industry
leaders
18:00-19:00.......Cocktail Party
FRIDAY, JUNE 17
09:00-10:30.......Parallel Sessions
T1-6. Issues in building the Virtual Library
......Chair: Michael Breaks, Heriot-Watt University Library, UK
- Internet resource guides: Stories for the Net /
Louis B. Rosenfeld, USA
- Commercial services on the Infobahn / George Brett, USA
- Electronic journals: transforming the information cycle? /
Hans Roes, The Netherlands
T2-6. Directory Services
......Chair: Paul-Andre Pays, INRIA, France
- Strangers in paradise / Bruno Koechlin, Katy Treca and
Paul-Andre Pays, France
- Schema publishing in X.500 directory / P.V. Rajeev, S.V. Raghavan,
India and Glenn Mansfield, Japan
- The SOLO directory access protocol / Christian Huitema, France
T3-6. The Internet and the Press
......Chair: Ole Jacobsen, ConneXions, USA
Discussion forum with participants from around the world.
T4-6. National Research and Education Networks,
......Telephone Companies and PTT's
......Chair: Gary Augustson, Pennsylvania State University, USA
A panel discussion focussing on the relationships between Telephone
Companies and PTT's and national and regional research and education
networks. What is the current relationship? How is the development of the
coming global information infrastructure and the continuing deregulation
and increased competitiveness in the telephone industry going to effect these relationships.
T5-6. Network Management
......Chair: Peter Elford, Cisco Systems, Australia
- A high-level notation for the specification of network management
applications / Alfredo C.S.C. Brites, Paulo A.F. Simoes,
Paulo M.C. Leitao, Edmundo H.S. Monteiro and Fernando P.L. Boavida
Fernandes, Portugal
- A scheme for FTP management /
Jose Aparecido Carrilho and Edmundo Madeira, Brazil
- Network discovery algorithms for the NSFnet / Bill Norton, USA
T6-6. Future Generations of Internet Technology
......Chair: Dave Morton, ECRC, Germany
- DDT - a versatile tunnelling technology /
Noritoshi Demizu and Suguru Yamaguchi, Japan
- Growing the MBone: scaling, performance, and security issues with
Internet multicasting / Steve Deering, USA
- Massive and real time storage server for Multimedia applications /
Milind Buddhikot and Guru Parulkar, USA
11:00-12:30.......Closing Session
..................Farewell & Keynote Addresses
......Keynote Speakers:
......- Mr. Thomas Kalil, Director to the National Economic Council,
........Washington D.C., USA
......- Mr. Michel Richonnier, Director DG XIII/C, EU
..................Chair: Geoff Manning, UK
DEMONSTRATIONS
At the Conference there will be a demonstrations area where participants
may visit a number of stands to see displays and demonstrations of various
projects and applications of network services for the academic community.
Planned demonstrations:
- Demonstration of MICE technology / Peter Kirstein, UK
- MS-Windows DUA at INET'94/JENC / Nils Meulemans, Belgium
- A Multimedia WPS using X.500/WWW integration /
Jean-Christophe Touvet and Paul-Andre Pays, France
- 'Wright Brothers Flyer', a virtual simulation/ Mark Pullen, USA
- C3: Character-sets Transliteration / Olla Jarnefors, Sweden
- Security Project: PASSWORD / Peter Kirstein, UK
TUTORIAL: High- Speed Networking for MultiMedia Applications
Chair: Dave Probert, Digital Equipment Corporation, European Headquarters
During this one day tutorial, which is scheduled for Monday,
June 13, the following topics will be discussed:
- ATM Definition and Architecture: From LAN to WAN and back again!
- High-Speed NETWORK EVOLUTION for MULTI-MEDIA Applications
- Multiprotocol Routers, Bridges, Switches and Hubs
- Integrated Environments for High-Speed Network Management
- Discussion and Questions and Answers
If you are interested in attending this tutorial, please register as soon
as possible. Please note that tutorials are not included in the conference
programme and that a fee of USD 60,- has to be paid separately.
RARE Working Groups
Prior to the conference, on Monday June 13 and Tuesday June 14, RARE
Working Group meetings will take place. During these meetings the different
Working Groups will introduce their current activities and discuss various
high priority topics. The meetings are open to all those who are
interested.
Monday, June 13
a.....09:00-12:30 RARE Working Group on Network Applications Support (NAP)
......14:00-17:30 Plenary RARE Working Group NAP
b.....09:00-18:00 RARE Working Group on Information Services and User
..................Support
d.....09:00-12:30 RARE Working Group on Security Technology
e. ...12:30-18:00 RARE Task Force on ATM
Tuesday, June 14
c.....09:00-18:00 RARE Working Group on Lower-Layers Technology
b.....09:00-18:00 RARE Working Group on Information Services and User
..................Support
f.....09:00-13:00 RARE Working Group on MultiMedia
g.....14:00-18:00 RARE Task Force on European MultiMedia Project
h.....09:00-13:00 RARE Working Group on Network Operations
i.....14:00-18:00 RARE Working Group on Mail and Messaging
j.....09:00-12:00 RARE Working Group on Internation Character Sets
Network Training Workshop For Technologically Emerging Countries In
conjunction with the INET'94/JENC5 Conference, a workshop on different
aspects of networking, for developing countries will be held prior to the
conference. The workshop will take place at the Czech Technical University
during June 5 - 11, 1994.
An intensive program of instruction, with emphasis upon hands-on network construction,
configuration and use, is planned for each of four program tracks:
1) Dial-up networking technology
2) TCP/IP networking technology
3) Network navigation and services
4) National network management
For additional information, please contact:
Jo-Anne Scott (joscott at igc.apc.org).
CONFERENCE EVENTS
All participants and accompanying persons are invited to attend the
following events. We hope these events will provide an opportunity to renew
old friendships and to create new ones with colleagues from all over the
world.
Opening Reception - Tuesday, June 14, 18.30-20.30 Palace of Culture:
Enjoy light refreshments while "catching up" with friends and colleagues
directly on the premises of the Congress Venue.
Gala Dinner - Wednesday, June 15, 20.00-23.00 Obecni dum (Municipal House):
Come and see the beautifully decorated interiors of the most impressive
building in Art Nouveau style in Prague from the beginning of this century.
There are six representative halls; the biggest one, the Smetana Hall, is
frequently used for concerts.
Cocktail Party - Thursday, June 16, 18.00-19.00 Palace of Culture:
A Cocktail Party will be held on the second floor of the Palace of Culture.
The adjoining terrace has the most unforgettable view of Prague.
CONFERENCE VENUE
Palace of Culture
Trida 5.kvetna
140 09 PRAGUE 4
Czech Republic
Telephone: +42-2-6117-1111
HOTEL ACCOMMODATIONS
The following hotels are offering special INET'94/JENC5 conference rates.
The prices include breakfast and V.A.T. tax.
Forum Hotel....USD 153,- /single..........USD 168,- /double
(Conference headquarters)
Kongresova 1, Prague 4
Tel.: +42-2-6119-1111
Fax.: +42-2-421-669
Located opposite the Congress venue (approx. 200 meters).
Panorama Hotel..USD125,- /single..........USD 142,- /double
Milevska 7, Prague 4
Tel.: +42-2-6116-1111
Fax.: +42-2-426-263
Located very close to the Metro, line C, two stops from the Congress venue
(approx. 10 minutes).
Union Hotel......USD 95,- /single..........USD 112,- /double
(2 kilometers from Congress Venue)
Ostrcilovo nam. 4, Prague 2
Tel.: +42-2-6121-4812
Fax.: +42-2-6121-4820
Located in the neighbourhood of the
Congress venue, within walking distance (approx. 10-15 minutes).
Patty Hotel......USD 80,- /single..........USD 93,- /double
(1 kilometer from Congress Venue)
Fuegnerovo nam. 4, Prague 2
Tel.: +42-2-290-052 /3
Fax.: +42-2-292-197
Located within walking distance (approx. 5 minutes).
ILF Hotel.........USD 50,- /single.........USD 65,- /double
(3 kilometers from Congress Venue)
Budejovicka 15, Prague 4
Tel.: +42-2-433-553
Fax.: +42-2-423-692
Located very close to Metro, line C, three stops from the Congress venue
(approx. 10 minutes).
Kupa Hotel.........USD 30,-/single..........USD 40,-/double
(8 kilometers from Congress Venue)
Kupeckeho 842, Prague 4 -H
Tel.: +42-2-791-0321
Fax.: +42-2-791-0216
Located on Metro, line C (approx. 15 minutes)
CONFERENCE AND HOTEL RESERVATION
All participants are encouraged to register before May 1st to obtain
the reduced registration fee. Please complete the enclosed conference
registration form and return it, with a check payable in U.S. dollars,
by mail to the address listed on the form. Registration with credit
card payments are possible and may be sent by E-mail or Fax to the
Conference Registration Office. The conference registration form also
serves as a reservation for hotel accommodation. In order to reserve a
hotel room, either complete the credit card authorisation section on the
conference registration form, or include 1 night's payment for
accommodation along with the conference registration fee, payable by
company check in US dollars. (Personal checks are not acceptable.)
Several exciting optional tours have been arranged, as described below.
A separate form is enclosed and should be mailed, along with full payment,
directly to the tour company. A Registration and Information desk will be
open at the Palace of Culture in Prague beginning Tuesday, June 14, 1994,
from 12.00 hours up until Friday, June 17 12.00 hours.
CONFIRMATION OF REGISTRATION
A letter confirming conference registration and hotel accommodation
will be sent to each participant upon receipt of the completed
registration form and accompanying payment. This letter should be
presented to the Registration Desk at the Palace of Culture upon arrival.
REGISTRATION FEES COVER
The registration fees cover attendance to all conference sessions. Also
included are the Opening Reception, Gala Dinner, Cocktail Party, luncheons,
coffee breaks, and conference materials including the program, full paper
proceedings and other conference publications. The fee for an accompanying
person includes the Opening Reception, Gala Dinner, and Cocktail Party.
Attendance at the conference sessions, luncheons, and conference materials
are not included in this fee.
PAYMENT METHOD
All payments must be in United States Dollars. Bank transfer, check and
international credit cards (VISA, American Express and Master Card) are
acceptable. Name of the account is KONFERENCE INET'94/JENC5, bank account
No. 1412130287 / 0100, Komercni banka, Dejvicka 52, Praha 6, Czech
Republic. Please make sure your name is added on the transfer slip.
PAYMENT AND CANCELLATION CONDITIONS
In the case of cancellation, WRITTEN (postal, fax, or electronic)
notification must be sent to the Registration Office and received on or
before the dates indicated. Refunds will be made after deducting expenses
and cancellation charges according to the schedule below.
Cancellation of reservation for accommodation:
30 days prior to arrival without cancellation fee
30-15 days prior to arrival 30% from deposit 15- 7 days prior to arrival
60% from deposit 7 days and less prior to arrival 100%
Cancellation of conference registration:
on or before May 25....$50,-(administrative fee)
from May 25 to June 10..50% of Registration fee
from June 11............no refund
Tours
Full payment must be received by May 15, 1994 to confirm your
reservation. Requests for refunds must be received 10 days prior
to the tour. No refunds if cancellation received later than 10 days
prior to the tour. A minimum of 15 persons is required for the
operation of tours. Full refunds will be issued if the minimum number
of participants is not met.
REGISTRATION OFFICE
VC CVUT INET'94/JENC5
Conference Registration Office
Zikova 4 166 35 PRAHA 6
CZECH REPUBLIC
E-mail: register at earn.cvut.cz
Tel: +42-2-3322916
Fax: +42-2-24310271
ACCOMMODATION AND TOURS INET'94/JENC5
Guarant Ltd.
Opletalova 15
110 00 PRAHA 1
CZECH REPUBLIC
Tel: +42-2-24210650/24210735
Fax: +42-2-260130
GENERAL INQUIRIES
INET'94/JENC5 Secretariat
c/o RARE Secretariat
Singel 466-468
NL-1017 AW AMSTERDAM
Tel: +31 20 639 1131
Fax: +31 20 639 3289
E-mail: inet-jenc-sec at rare.nl
X.400: C=nl; ADMD=400net; PRMD=surf; O=rare; S=inet-jenc-sec
------------------------------------------------------------------
------------------------------------------------------------------
INET'94/JENC5 CONFERENCE REGISTRATION FORM
Return completed form to:
VC CVUT
INET'94/JENC5
Conference Registration Office
Zikova 4
166 35 Praha 6
Czech Republic
Tel. +42-2-3322916
Fax. +42-2-24310271
E-mail: register at earn.cvut.cz
Conference registration fee MUST accompany this form and must
be received before registration or accommodation can be processed.
Please make a copy of this form for your records. Please type
all applicable information requested below. Only one registration
per form, please.
__________________________________________________________________
SURNAME ......................
FIRST NAME ...................
Prof__ Dr__ Mr__ Ms__
Internet Society Member #___________________
TITLE .......................
AFFILIATION .................
STREET ADDRESS ..................................
CITY ........................
STATE .......................
POSTAL CODE .................
COUNTRY .....................
TELEPHONE ...................
FAX .........................
E-MAIL .......................
NAME TO APPEAR ON BADGE ...................
REGISTERED ACCOMPANYING PERSON(S)
.................................................
SPECIAL NEEDS/MEALS
.................................................
____________________________________________________________________
Payment Method:
All payments must be in United States Dollars. Bank transfer,
check and international credit cards (VISA, American Express and
Master Card) are acceptable. Personal checks are not acceptable.
Name of the account is: KONFERENCE INET'94/JENC5, bank account no.
1412130287/0100, Komercni banka, Dejvicka 52, Praha 6, Czech
Republic. PLEASE MENTION THE PARTICIPANT'S NAME.
_____________________________________________________________________
Registration Fees
Internet Society Member ..... (Before May 15) .....USD 425 ..USD____
............................. (May 15 - June 5) .......475 ..USD____
Desk Registration............ (from June 6) ...........525 ..USD____
Non-Member (includes a one year ISOC
membership).................. (Before May 15) .....USD 475 ..USD____
............................. (May 15 - June 5) .......525 ..USD____
Desk Registration ........... (from June 6) ...........575 ..USD____
Accompanying Person(s)
(Includes Opening Reception,
Gala Dinner and Cocktails) ........................USD 115 ..USD____
Hotel Deposit (if not guaranteed by credit card).............USD____
Tutorial...........................................USD 60 ...USD____
TOTAL AMOUNT TO BE CHARGED:..................................USD____
____VISA
____MasterCard
____American Express
____International Money Order
____Wire Transfer
Credit Card Number_________________________
Expiration Date____________________________
Name on Card_______________________________
Billing Address_____________________________
Signature__________________________________
------------------------------------------------------------------------
------------------------------------------------------------------------
INET'94/JENC5
Accommodation Reservation
Accommodation reservations must be made by completing this form.
Guaranteed accommodation cut-off date: MAY 1
Rooms: / Nights:
________Forum Hotel....USD 153,-/single,...USD 168,-/double
________Panorama Hotel.USD 125,-/single....USD 142,-/double
________Union Hotel....USD 95,-/single.....USD 112,-/double
________Patty Hotel....USD 80,-/single.....USD 93,-/double
________ILF Hotel......USD 50,-/single.....USD 65,-/double
________Kupa Hotel.....USD 30,-/single.....USD 40,-/double
Hotel extras will be paid directly to the hotel reception.
Room Reservation Name:____________________Sharing With:_________________
Arrival Date:________/______/1994
Departure Date:______/______/1994
Please check one of the following:
- 1 person, one bed
- 2 persons, double beds
- 2 persons, twin beds
Do you have a special accommodation request (e.g. no-smoking room)?
_______________________________________________
Suites (extra cost)?___________________________
Please describe disability/handicap
needs:_________________________________________
______I am arranging my own accommodation.
Accommodation Deposit:
Your room reservation can be guaranteed by either of the following methods:
1. Complete the Credit Card Authorization section of this form. This is the
easiest way to guarantee your reservation. 2. Send one night's hotel fee
along with the registration fee, if other payment methods are used.
____VISA
____MasterCard
____American Express
____International Money Order
Credit Card Number_________________________
Expiration Date____________________________
Name on Card_______________________________
Signature__________________________________
---------------------------------------------------------------------------
GENERAL INFORMATION
OFFICIAL CARRIER
INET'94/JENC5 appointed CSA (Czechoslovak Airlines) as official carrier
of the conference. CSA has guaranteed to provide the lowest available fare
at the time your ticket is issued. Please contact CSA representatives in
your countries together with the confirmation of paid registration fee.
An Information desk of CSA will be open at the Palace of Culture during
the Conference period.
E-MAIL FACILITIES AT INET'94/JENC5
Internet access will be available at the Conference Location (Palace of
Culture) beginning on Tuesday, 14 until Friday, 17 1994.
PASSPORT AND VISA REQUIREMENTS
All foreign visitors entering the Czech Republic must possess a passport
valid for at least the next 6 months. Participants requiring a visa should
apply immediately to consular offices of the Czech Republic or diplomatic
missions in their country (in order to avoid delays in travel to the
conference).
CURRENCY / CREDIT CARDS
The unit of currency is Czech crown (Kc) which subdivided into 100 hallers
(h). International credit cards are accepted for payment in most hotels,
restaurants and shops.
The exchange rate (February 1994): approx. $ 1,- is Kc 32.
TRANSPORTATION
The transport in Prague is organized by means of buses, trams and Metro
(subway). One ride-ticket costs Kc 6,- and is valid for all means of
transport. Individual tickets as well as 'travel passports' are available
at all tobacconists' shops, newspaper stands or at hotel desks. Prague
Metro is quite a new one and very efficient. At peak hours there is a train
every 1 or 2 minutes, off-peak at least every 10 minutes.
CLIMATE AND CLOTHING
Prague has a continental climate. In June the average temperature is about
20 C ( 68 F ). There might be an occasional shower, therefore it is
advisable to bring a jacket, a sweater and an umbrella.
VOLTAGE, SOCKETS AND PLUGS
220 V, sockets have the European norm, plug are three - prong grounded.
ACCESS TO THE CONFERENCE SITE
The Palace of Culture is located approximately 25 kilometers west of the
airport. Taxis (about Kc 500,-) are available to take you to the Congress
Venue.
PRAGUE
is like a history lesson come true. As you walk among the long stone
palaces or across the 'Charles Bridge', with Smetana's Vltava flowing
below and pointed towers all around, you will feel as if history had
stopped somewhere back in the 18th century. Goethe called Prague the
'prettiest gem in the stone crown of the world'. This cultural center of
Europe is famous for its architectural treasures that have been so well
preserved. Its wealth can be gathered from the diversity and quantity of
the many Romanesque monuments and its Gothic town planning. In time new
styles developed, like Baroque and later on Art Nouveau. The countenance
of Prague reflects every cultural period and all the different artistic
styles.
Musical life is a deeply rooted tradition in Prague. One only needs to
remember the names of the two greatest Czech composers, Antonin Dvorak
and Bedrich Smetana. Their music can still be heard. It is said that it
is an advantage to be a foreigner in Prague. The renowned Slavonic
hospitality manifests itself in Prague at every step. A lot of traditional
Czech products are offered, like crystal, porcelain, earthenware, but also
CDs, and illustrated art books. The national beverages like beer and
sliwowitz are worth a try and restaurants offer a wide variety of food.
Prague is ready to welcome its visitors and let you share in the experience
of 'awakening to a beautiful dream'.
TOURS
Saturday - Sunday, June 11 - 12
Pre-congress Tour: West Bohemian Spa Triangle Departure at 8:30 a.m. on
Saturday, June 11 from Palace of Culture, arrival at 7:00 p.m. on Sunday,
June 12 to Palace of Culture
.......single room USD 252,-
.......double room USD 231,-
Tour to the so-called West Bohemian Triangle - Karlovy Vary, Marianske
Lazne and Frantiskovy Lazne. You will be accommodated in the most famous
of these spas in Karlovy Vary, founded more than 600 years ago by Charles
IV, King of Bohemia. The colonnades with mineral water springs are
incorporated into a beautiful natural background of greenery. Accommodation
will be arranged at the Pupp Hotel - a hotel located in the spa area and
with a famous past dating back to the early 18th century. During the
walking tour you can taste mineral waters and the popular Czech elixir
Becher Liqueur. You will also visit the ancient royal town Cheb with the
unique architectonic group of medieval houses called Spalicek.
Saturday - Monday, June 11 - 13
Pre-congress Tour: Vienna - South Moravia - Prague Meeting point 1:00 p.m.,
Saturday, June 11 at a hotel in Vienna, Austria, return 7:00 p.m., Monday,
June 13 to the Palace of Culture, Prague
.......single room USD 480,-
.......double room USD 440,-
A combined 3-days tour to South Moravia and to the capital of Austria,
Vienna. You will see the main sights of this beautiful city (Schonbrunn,
Hofburg, Ringstrasse, Prater and more) and in the evening you can taste
Austrian wine in a traditional wine restaurant. Accommodation is in a
4 star hotel in the centre of the city. Then you will continue to the
picturesque region of South Moravia in the Czech Republic. This region has
always boasted its good wine, charming national songs and dulcimer music.
You will visit the historical towns Telc and Brno. Telc, with its unique
medieval houses and a beautiful Renaissance chateau, is protected by
UNESCO. Brno, the largest city in South Moravia, is well-known not only for
its historical monuments, but also for its international trade fairs.
Accommodation is also in a 4 star hotel in Brno. The last day after the
sightseeing tour of Brno you will enjoy a romantic boat trip through the
magnificent stalagtite Punkva caves in the Moravian Karst near town. A
professional Guarant guide will provide entertaining and informative
narration throughout the tour.
Tuesday, June 14, / Thursday, June 16
City Tour: Prague Castle and Mala Strana
(9:00 a.m. - 1:00 p.m.), USD 13,- per person
You will see the main attractions of Prague Castle (including St. Vitus
Cathedral from the 14th century, the Royal Palace, Golden Lane) and the
beautiful historical district under the Castle called Little Town
(Mala Strana).
Tuesday, June 14, 1994 / Thursday, June 16 1994 Konopiste Chateau
(9:30 a.m. - 1:00 p.m.), USD 24,- per person
A magnificent castle situated about 40 km southeast of Prague. The last
private owner was Archduke Franz Ferdinand d'Este, successor to the
Austrian throne (assassinated in Sarajevo in 1914). The castle is situated
in a lovely park and contains extensive collections of historical weapons,
hunting trophies, china and other artifacts.
Wednesday, June 15 / Friday, June 17
City Tour: The Old Town and Jewish Prague
(9:00 a.m. - 1:00 p.m.), USD 13,- per person
You will enjoy the Old Town Square with famous astronomical clock, Town
Hall and the Prague Ghetto with several Synagogues and the Jewish Cemetery.
Wednesday, June 15
Karlstejn Castle (9:30 a.m. - 1:30 p.m.), USD 23,- per person
Karlstejn Castle (35 km to the south-west of Prague) is the most visited
castle in the Czech Republic. The castle, originally built in the 14th
century by Charles IV to house the coronation jewels, is situated in a
lovely, romantic landscape amidst deep forest. The castle tour lets you
enjoy the interiors including the Royal Palace and the original bedroom of
Charles IV.
Thursday, June 16
An Evening in Prague's Oldest Brewery "U Fleku"
(8:00 p.m. - 11:00 p.m.), USD 25,- per person
Songs, traditional Czech cuisine, and world-famous Czech dark beer in the
spirit of Prague during the turn of the century.
Thursday, June 16
An Evening in the wine cellar "U Pastyrky"
(8:00 p.m. - 11:00 p.m.), USD 23,- per person
Enjoy traditional atmosphere, Gypsy music, the hearty dry Moravian red and
white wines and a delicious dinner cooked over an open fire.
Thursday, June 16
State Opera
(7:00 p.m. - 10:00 p.m.), USD 20,- per person
Verdi - IL TROVATORE
Saturday - Sunday, June 18 - 19
Post-Congress Tour: Treasure of South Bohemia Departure 8:30 a.m. on
Saturday 18, from Palace of Culture, return 7:00 p.m. on Sunday 19, to
Palace of Culture
.......single room USD 205,-
.......double room USD 184,-
South Bohemia is the region everybody likes to return to. It offers more
than 15.000 works of architecture, including castles, chateaux, monasteries
and historical towns. The natural riches of South Bohemia are also
immeasurable. You will enjoy the most impressive and interesting of these
monuments, Hluboka Castle. It is built in a beautiful Tudor Gothic style
and is filled with sumptuous tapestries, wood carvings, china, pictures
and old weapons. Ceske Budejovice is a South Bohemian metropolis and the
protected urban reservation was founded in the 13th century. Zlata Koruna,
a monastery, is also from the 13th century. Cesky Krumlov considered
to be the best-preserved Renaissance town in Central Europe, is protected
by UNESCO. Trebon is a small picturesque town with the atmosphere of the
Middle Ages, here you can rest for a while on the banks of the loveliest
South-Bohemian fishpond. You will be accommodated in a 4 star hotel in
Ceske Budejovice, while in the evening dinner will be served in a
traditional Czech restaurant. A great deal of walking is nvolved, so
please wear comfortable shoes.
Saturday - Monday, June 18 - 20
Post-Congress Tour: Prague - North Moravia - Budapest Departure 8:00 a.m.
on Saturday 18, from Palace of Culture, tour ends at 1:00 p.m. on Monday
20, in Budapest, Hungary
.......single room USD 492,-
.......double room USD 432,-
This Tour will show you the main attractions and natural beauties of
Northern Moravia. Olomouc with its 200 architectural sights, is second
only to Prague as a conservation area. At Sternberk Castle you will enjoy
the interesting clock museum. You will also visit the open-air museum in
Roznov pod Radhostem, set in delightful mountain scenery. The second day
we welcome you to Budapest, the capital of Hungary, where you can see all
the main sights (including Herous Square with its Millenium Monument,
Matthias Church and the Fishermen's Bastion in the Castle area). You will
spend the evening in a traditional Hungarian wine cellar with folklore show
and wine-tasting. Accommodation is in a 4-star hotel.
---------------------------------------------------------------------------
---------------------------------------------------------------------------
TOUR RESERVATION FORM
Payment Policy: Full payment must be received by May 1, 1994 to confirm
your reservation. Requests for refunds must be received 10 days prior to
the tour. No refunds if cancellation is received later than 10 days prior
to the tour. To cancel, send fax or write c/o the address noted below.
A minimum of 15 persons is required for the operation of tours. Full
refunds will be issued if the minimum number of registrants is not met.
Name:___________________________________________________Phone:___________
Address:_________________________________________________________________
City:________________________State:________ZIP:____Country:______________
Credit Card:______________VISA____________AMEX______________Master Card__
Credit Card Number:______________________________________________________
Expiry Date:_____________________________________________________________
Name on Credit Card (if different)_______________________________________
Saturday - Sunday, June 11 - 12, 1994
Pre-congress Tour: West Bohemian Spa Triangle Departure at 8:30 a.m. on
Saturday, June 11 from Palace of Culture, arrival at 7:00 p.m. on Sunday,
June 12 to Palace of Culture
______Tickets at USD 252,- / single room
______Tickets at USD 231,- / double room
Saturday - Monday, June 11 - 13, 1994
Pre-congress Tour: Vienna - South Moravia - Prague Meeting point at 1:00
p.m. on Saturday, June 11 at hotel in Vienna, Austria arrival at 7:00 p.m.
on Monday, June 13 to Palace of Culture.
______Tickets at USD 480,- / single room
______Tickets at USD 440,- / double room
Tuesday, June 14, 1994
City Tour: Prague Castle and Mala Strana (9:00 a.m. - 1.00 p.m.)
_______Tickets at USD 13,- per person
Tuesday, June 14, 1994
Konopiste Chateau, 9:30 a.m. - 1:00 p.m.
______Tickets at USD 24,- per person
Wednesday, June 15, 1994
City Tour: The Old Town and Jewish Ghetto (9:00 a.m. - 1:00 p.m.)
______Tickets at USD 13,- per person
Wednesday, June 15, 1994
Karlstejn Castle, 9:30 a.m. - 1.:30 p.m.
______Tickets at USD 23,- per person
Thursday, June 16, 1994
City Tour: Prague Castle and Mala Strana (9:00 a.m. - 1:00 p.m.)
______Tickets at USD 13,- per person
Thursday, June 16, 1994
Konopiste Chateau, 9:30 a.m. - 1:00 p.m.
______Tickets at USD 24,- per person
Thursday, June 16, 1994
An Evening in Prague's Oldest Brewery 'U Fleku' (8:00 p.m. - 11:00 p.m.)
______Tickets at USD 25,- per person
Thursday, June 16, 1994
An Evening in the wine cellar 'U Pastyrky' (8:00 p.m. - 11:00 p.m.)
______Tickets at USD 23,- per person
Thursday, June 16, 1994
State Opera, 7:00 p.m. - 10:00 p.m.
______Tickets at USD 20,- per person
Friday, June 17, 1994
City Tour: Old Town and Jewish Ghetto (9:00 a.m. - 1:00 p.m.)
______Tickets at USD 13,- per person
Saturday - Sunday, June 18 - 19, 1994
Post-Congress Tour: Treasure of South Bohemia Departure at 8:30 a.m. on
Saturday 18, from Palace of Culture, arrival at 7:00 p.m. on Sunday 19, to
Palace of Culture.
______ Tickets at USD 205,- / single room
______ Tickets at USD 184,- / double room
Saturday - Monday, June 18 - 20, 1994
Post-Congress Tour: Prague - North Moravia - Budapest Departure at 8:00
a.m. on Saturday 18, from Palace of Culture, the end of Tour at 1:00 p.m.
on Monday 20, in Budapest.
______Tickets at USD 492,- / single room
______Tickets at USD 432,- / double room
Mail to:
INET'94/JENC5
GUARANT Ltd.
Opletalova 15
Praha l, 110 00
Czech Republic
Tel. +42-2-24210650/24210735
Fax. +42-2-260130
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12433;
25 Apr 94 11:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17722;
25 Apr 94 11:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12410;
25 Apr 94 11:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12230;
25 Apr 94 11:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.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-pppext-frame-relay-03.txt
Date: Mon, 25 Apr 94 11:46:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404251146.aa12230 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP in Frame Relay
Author(s) : W. Simpson
Filename : draft-ietf-pppext-frame-relay-03.txt
Pages : 8
Date : 04/20/1994
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of Frame Relay for framing
PPP encapsulated packets.
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-pppext-frame-relay-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-ietf-pppext-frame-relay-03.txt".
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: <19940420101352.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-frame-relay-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-frame-relay-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940420101352.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15675;
25 Apr 94 14:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15665;
25 Apr 94 14:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20820;
25 Apr 94 14:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15654;
25 Apr 94 14:27 EDT
Received: from xap.xyplex.com by IETF.CNRI.Reston.VA.US id aa15597;
25 Apr 94 14:24 EDT
Received: by xap.xyplex.com id <AA29593 at xap.xyplex.com>; Mon, 25 Apr 94 14:19:24 -0500
Date: Mon, 25 Apr 94 14:19:24 -0500
Message-Id: <9404251919.AA29593 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at xap.xyplex.com>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Apology to Mr. Martillo
A few days ago I sent a message on this mailing list regarding Mr. Joachim
Martillo. It has come to my attention that my off-the-cuff comments might be
taken too seriously. I have no intention of damaging Mr. Martillo's
reputation in the industry, and apologize if I have done so.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17107;
25 Apr 94 15:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17094;
25 Apr 94 15:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22222;
25 Apr 94 15:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17074;
25 Apr 94 15:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16978;
25 Apr 94 15:28 EDT
Received: from uucp5.netcom.com by CNRI.Reston.VA.US id aa22125;
25 Apr 94 15:28 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id MAA27987; Mon, 25 Apr 1994 12:06:35 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA28706; Mon, 25 Apr 1994 11:59:33 -0700
Date: Mon, 25 Apr 1994 11:59:33 -0700
Message-Id: <9404251859.AA28706 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: concept/term indexing (more than you ever wanted to know?)
Reply-To: Lynn Wheeler <lynn at bli.com>
I'm interesting in solutions to concept/term indexing. I've loaded
lots of the IETF/RFC information into our semantic network dbms and
have been producing data base reports rfcindex.txt and rfcauthor.txt
(available from ftp.netcom.com:pub/lynn) ... as well as running some
rules (i.e. knowledge base) one of which results in the stuff
included in section 6.10 of rfc1600 (std1).
Past couple days I've been experimenting producing a rfcindex.html
document (currently ftp://ftp.netcom.com/pub/lynn/rfctest2.html). The
issue that I'm looking at now is the mapping of keyword/terms/phrases
to concepts for the "concept" index. As part of this endevor, I've
also run/created additional rules as part of the "standards" process
index (resulting in 3 minor differences between the rfc1600 and
rfctest2.html ... as noted in rfctest2.html).
The IETF SNDBMS currently contains the glossary (mostly from rfc1392)
with "IETF terms" and acronyms ... with appropriate relationships
defined between acronyms and their respective "IETF terms". The "IETF
terms" also have the glossary definitions. I've also manually defined
some "peer-to-peer", reflexive "IsASenseOf" relationships between
"IETF terms".
Producing the rfc concept index (in the html file) ... it is fairly
obvious to merge the acronym and term lists into single reference.
However, straight keyword isn't sufficient (for example of additional
clustering/ordering see rfc1000). I would like to be able to manual
define additional hiearchical relationships (of the term/acronym
flavor) between IETF terms ... and additional relationships between
RFCs and IETF terms.
A simple example is "Privacy Enhanced Mail" and "PEM" are defined IETF
terms and acronyms. However, the RFCs on the subject use the phrase
"Privacy Enhancement for Internet Electronic Mail". I've looking for a
new category of "things" (other than defined terms) that can be used
in searches/matches. Each of these "phrase" things would have the
appropriate relationship back to a defined "IETF term".
I then have some code that matches word combos in titles with Terms,
acronyms, and (now) phrases (where both acronyms and phrases map back
to specific selected "terms").
It would probably be useful ... in addition to "terms", "phrases",
"acronyms" which are used when looking for their occurance in text
(titles, abstracts, keywords, etc) ... it would also be useful to have
something like "IETF category" ... that directly associates the rfc,
totally independent of the "words" ... again likely an effort
requiring manual creation.
The "opportunity" was addressed in NLM's Unified Medical Language System
(UMLS). By defining the following type of schema:
[semantic category]
[conceptid]
[termid]
[type of language]
[attribute]]
[stringid]
[attribute]
[string]
The conceptid, termid, and stringid are all "numerical indexes"
effectively used for RDBMS implementations. A [semantic category] will
have one or more [conceptid] ... in addition, a [conceptid] may have
relations to one or more [semantic category].
I've taken some amount of liberties loading the "relational ascii
table" data on the UMLS cdrom (500 mbytes) into our SNDBMS. Basically
a [termid] [attribute] is an attribute "preferred", "synonym",
"non-preferred", and "other" ... which effectively involves the type
of relationship from the [conceptid]->[termid] ([stringid] [attribute]
is similar). Taking liberties ... instead of (just) making [attribute]
an entity-attribute ... I've defined different types of relations
between [conceptid] & [termid] ... that effectively correspond to the
[attribute] and used them when inserting the data.
It is then possible to look for matches across all possible strings
and appropriate classify/index the recognized item (i.e. "UMLS" was
created by a "library" organization ... i.e. National Library of
Medicine ... and is used by Medlars ... the medical library system).
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Words of wisdom from Zippy:
What's the MATTER Sid?.. Is your BEVERAGE unsatisfactory?
................ attachment ...............
Extract from UMLS(r) Metathesaurus(r) Fact Sheet:
Includes 152,444 concepts and 311,046 terms (including lexical
variants, synonyms, etc) from fifteen different vocabularies. It
contains all terms from the 1992, MeSH(r), the National Library of
Medicine's Meical Subject Headings, DSM-HIR, the American Psychiatric
Association's Diagnostic and Statistical Manual of Mental Disorders,
Third edition (revised); .... and another 20 or so sources.
Statistiical profile:
30,123 MeSH (16,760 preferred terms; 130,482 supplemental chemical
terms)
23,495 INSERM French translation of MeSH (Main headings and
French Synonyms)
12,495 SNOMED II (6,971 preferred terms)
21,293 ICD-9-CM terms (13,119 preferred terms)
5,595 CRISP (4,285 preferred terms)
5,094 LCSH (5,094 preferred terms)
2,619 COSTART (1,179 preferred terms)
1,511 COSTAR (1,511 preferred terms)
905 NIC (336 preferred terms)
776 AI Rheum (687 preferred terms)
604 Neuronames (604 preferred terms)
603 DXPlain (603 preferred terms)
450 DSM 3R (263 preferred terms)
557 CPT (210 preferred terms)
100 NANDA (99 preferred terms)
122 ACR (122 preferred terms)
112 UMDNS (112 preferred terms)
The Metathesaurus is organized by concept or meaning. Alternate names
for the same concept (synonyms, lexical variants and translations) are
linked together. Each Metathesaurus concept has attributes that help
to define its meaning. A number of relationships between different
concepts are represented. Some of these relationships are derived from
the source vocabularies; others are created during the construction of
the Metathesaurus. Most inter-concept relationships in the
Metathesaurus link concepts that are similar along some dimension.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00895;
25 Apr 94 20:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00884;
25 Apr 94 20:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03583;
25 Apr 94 20:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00868;
25 Apr 94 20:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00808;
25 Apr 94 20:39 EDT
Received: from ri.engin.umich.edu by CNRI.Reston.VA.US id aa03524;
25 Apr 94 20:39 EDT
Received: (dweller at localhost) by ri.engin.umich.edu (8.6.8/8.6.4) id UAA03293; Mon, 25 Apr 1994 20:39:32 -0400
Date: Mon, 25 Apr 1994 20:38:10 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Daniel Arthur Weller <dweller at engin.umich.edu>
Subject: Unsubscribe
To: ietf at CNRI.Reston.VA.US
Message-ID: <Pine.3.87.9404252010.E3105-0100000 at ri.engin.umich.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Please remove me from your mailing list.
Thank you.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00974;
25 Apr 94 20:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00966;
25 Apr 94 20:42 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa03624;
25 Apr 94 20:42 EDT
Received: by bitsy.MIT.EDU
id AA25477; Mon, 25 Apr 94 20:30:57 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA25469; Mon, 25 Apr 94 20:30:55 EDT
Received: from [128.2.10.101] by MIT.EDU with SMTP
id AA00804; Mon, 25 Apr 94 20:30:46 EDT
Received: (from postman at localhost) by andrew.cmu.edu (8.6.7/8.6.6) id UAA22730 for cat-ietf at MIT.EDU; Mon, 25 Apr 1994 20:30:43 -0400
Received: via switchmail; Mon, 25 Apr 1994 20:30:42 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Ehj62Fy00WBwI0WKQ3>;
Mon, 25 Apr 1994 20:30:10 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.Ehj62BC00WBw8RsUg2>;
Mon, 25 Apr 1994 20:30:05 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
Mon, 25 Apr 1994 20:30:02 -0400 (EDT)
Message-Id: <4hj62_600WBwQRsUVo at andrew.cmu.edu>
Date: Mon, 25 Apr 1994 20:30:02 -0400 (EDT)
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+ at cmu.edu>
To: cat-ietf at mit.edu
Subject: Re: Staying within the PBSZ using GSSAPI
In-Reply-To: <9404252354.AA18179 at tsx-11.MIT.EDU>
References: <9404252354.AA18179 at tsx-11.MIT.EDU>
Beak: Is
tytso at ATHENA.MIT.EDU (Theodore Ts'o) writes:
> I agree. I also like John Linn's suggestion that we specify an
> "implementor's agreement" that all mechanisms support at least a 2k
> input token size.
The suggested "implementor's agreement" was that no mechanism produce
an output token more than 2k larger than the input token.
--
_.John G. Myers Internet: jgm+ at CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02702;
25 Apr 94 21:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02686;
25 Apr 94 21:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05482;
25 Apr 94 21:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02617;
25 Apr 94 21:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02312;
25 Apr 94 21:55 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa05239;
25 Apr 94 21:54 EDT
Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94)
id AA11629; Mon, 25 Apr 94 18:39:44 -0700
Received: by skidrow.lkg.dec.com (5.65/MS-081993);
id AA17032; Mon, 25 Apr 1994 21:41:29 -0400
Message-Id: <9404260141.AA17032 at skidrow.lkg.dec.com>
To: Daniel Arthur Weller <dweller at engin.umich.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: netiquette
In-Reply-To: Your message of "Mon, 25 Apr 94 20:38:10 EDT."
<Pine.3.87.9404252010.E3105-0100000 at ri.engin.umich.edu>
Date: Mon, 25 Apr 94 21:41:29 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.lkg.dec.com>
X-Mts: smtp
Please learn how to subscribe to and unsubscribe from mailing lists.
Unless all other paths fial, you *never* sent the request directly
to the main mailing list name. You either sent it to the list
name with "-request" appended or to LISTSERV or the like at that
host.
Donald
From: Daniel Arthur Weller <dweller at engin.umich.edu>
X-Orig-Sender: ietf-request at IETF.CNRI.Reston.VA.US
Sender: ietf-request at IETF.CNRI.Reston.VA.US
To: ietf at CNRI.Reston.VA.US
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
>Please remove me from your mailing list.
>Thank you.
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04405;
25 Apr 94 22:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04397;
25 Apr 94 22:11 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa06555;
25 Apr 94 22:11 EDT
Received: by bitsy.MIT.EDU
id AA24964; Mon, 25 Apr 94 19:54:26 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA24956; Mon, 25 Apr 94 19:54:16 EDT
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA28686; Mon, 25 Apr 94 19:54:11 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA18179; Mon, 25 Apr 94 19:54:03 EDT
Date: Mon, 25 Apr 94 19:54:03 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9404252354.AA18179 at tsx-11.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: Steve Lunt <lunt at ctt.bellcore.com>, cat-ietf at mit.edu, jgm+ at cmu.edu
In-Reply-To: Marc Horowitz's message of Wed, 20 Apr 1994 18:08:15 -0400,
<9404202208.AA16248 at dun-dun-noodles.aktis.com>
Subject: Re: Staying within the PBSZ using GSSAPI
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Wed, 20 Apr 1994 18:08:15 -0400
From: Marc Horowitz <marc at cam.ov.com>
>> > I would have the query facility take an input parameter. Given a
>> > plaintext of X bytes, tell me the upper bound on the size of the
>> > output token.
>>
>> I would change this to be: given a desired output token size of X,
>> what is the largest input token Y which will not be larger than X on
>> output.
I would support both.
I agree. I also like John Linn's suggestion that we specify an
"implementor's agreement" that all mechanisms support at least a 2k
input token size. We may actually want to specify that in a future RFC
revision as a requirement.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00731;
26 Apr 94 6:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00721;
26 Apr 94 6:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02513;
26 Apr 94 6:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00711;
26 Apr 94 6:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00603;
26 Apr 94 6:14 EDT
Received: from access1.digex.net by CNRI.Reston.VA.US id aa02331;
26 Apr 94 6:14 EDT
Received: by access1.digex.net id AA03279
(5.67b8/IDA-1.5 for IETF List <ietf at cnri.reston.va.us>); Tue, 26 Apr 1994 06:14:37 -0400
Newsgroups: tdr.paul.private.mail
Date: Tue, 26 Apr 1994 06:14:37 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Robinson <PAUL at tdr.com>
X-Orig-Sender: Paul Robinson <PAUL at tdr.com>
Reply-To: Paul Robinson <PAUL at tdr.com>
Subject: Top 10 networks more shaky than T3.....
To: Everyone Else Lurking on Com-Priv <com-priv at psi.com>,
IETF List <ietf at CNRI.Reston.VA.US>, telecom at delta.eecs.nwu.edu
Message-Id: <01.1994Apr26.06h12m24s.PAUL-0100000 at TDR.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Top 10 less reliable networks than NSFnet's T3:
10. Cans tied together with string during a San Fran 8.5 earthquake.
9. The Arthritic's Morse Code net.
8. AT&T's net during a transparent software upgrade.
7. Bouncing signals off satellite, orbiting asteroid near Alpha Centauri.
6. "Great Valleys Of The World"'s semaphore net.
5. Chain-packet net (every time you get a packet, send off two more).
4. Using carrier mackerel across the Sahara.
3. Single Side Band transmitted from ground zero of a thermonuclear
explosion.
2. 100 monkeys sending at random (by chance,
they'll eventually send the information you want sent).
1. L.A.'s smog signal net.
---
Paul Robinson - Paul at TDR.COM
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy at psg.com>
-----
The following Automatic Fortune Cookie was selected only for this message:
"He is now rising from affluence to poverty."
-- Mark Twain
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04933;
26 Apr 94 7:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04922;
26 Apr 94 7:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05737;
26 Apr 94 7:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04890;
26 Apr 94 7:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04385;
26 Apr 94 7:48 EDT
Received: from ghost.darpa.mil by CNRI.Reston.VA.US id aa05499;
26 Apr 94 7:48 EDT
Received: by ghost.arpa.mil (4.1/SMI-4.1)
id AA11265; Tue, 26 Apr 94 07:54:24 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "W.S. Harborth" <wharbort at ghost.arpa.mil>
Message-Id: <9404261154.AA11265 at ghost.arpa.mil>
Subject: Duplicate Messages
To: IETF List <ietf at CNRI.Reston.VA.US>
Date: Tue, 26 Apr 1994 07:54:24 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 344
What is going on here? Am I the only one that is getting two copies of
everyting from this list.
Skip Harborth
Network Security Engineer
Houston Associates, Incorporated
4601 North Fairfax Dr., Suite 704
(703) 812-8730 812-5099 (fax)
INTERNET> wharbort at ghost.arpa.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05689;
26 Apr 94 8:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05678;
26 Apr 94 8:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06381;
26 Apr 94 8:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05662;
26 Apr 94 8:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05592;
26 Apr 94 8:19 EDT
Received: from inet-gw-3.pa.dec.com by CNRI.Reston.VA.US id aa06308;
26 Apr 94 8:19 EDT
Received: from cssec4.pcs.dec.com by inet-gw-3.pa.dec.com (5.65/21Mar94)
id AA12541; Tue, 26 Apr 94 05:10:34 -0700
Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05);
id AA27506; Tue, 26 Apr 94 14:10:18 +0200
Message-Id: <9404261210.AA27506 at cssec4.pcs.dec.com>
To: "W.S. Harborth" <wharbort at ghost.arpa.mil>
Cc: IETF List <ietf at CNRI.Reston.VA.US>, ihanson at cssec4.pcs.dec.com
Subject: Re: Duplicate Messages
In-Reply-To: Your message of "Tue, 26 Apr 94 07:54:24 EDT."
<9404261154.AA11265 at ghost.arpa.mil>
Date: Tue, 26 Apr 94 14:10:17 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Iain K. Hanson" <ihanson at pcs.dec.com>
X-Mts: smtp
>What is going on here? Am I the only one that is getting two copies of
>everyting from this list.
No your not. And the mail archive is getting up to 3 copies!!!
/ikh
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08362;
26 Apr 94 10:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09384;
26 Apr 94 10:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08346;
26 Apr 94 10:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08155;
26 Apr 94 10:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.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-pppext-multilink-08.txt
Date: Tue, 26 Apr 94 10:21:03 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404261021.aa08155 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The PPP Multilink Protocol (MP)
Author(s) : K. Sklower, B. Lloyd, G. McGregor, D. Carr
Filename : draft-ietf-pppext-multilink-08.txt
Pages : 20
Date : 04/25/1994
This document proposes a method for splitting, recombining and sequencing
datagrams across multiple logical data links. This work was originally
motivated by the desire to exploit multiple bearer channels in ISDN, but is
equally applicable to any situation in which multiple PPP links connect two
system, including async links. This is accomplished by means of new PPP
options and protocols.
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-pppext-multilink-08.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-pppext-multilink-08.txt".
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: <19940425093221.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-multilink-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-multilink-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940425093221.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08508;
26 Apr 94 10:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08504;
26 Apr 94 10:34 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa09529; 26 Apr 94 10:34 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA08458; Tue, 26 Apr 94 07:31:22 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA13917; Tue, 26 Apr 94 07:30:26 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA03153; Tue, 26 Apr 94 07:31:41 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA03147; Tue, 26 Apr 94 07:31:40 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA28458; Tue, 26 Apr 94 07:30:15 PDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM)
id AA08397; Tue, 26 Apr 94 07:31:07 PDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08319;
26 Apr 94 10:26 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
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sipp-sa-02.txt
Date: Tue, 26 Apr 94 10:26:28 -0400
Message-Id: <9404261026.aa08319 at IETF.CNRI.Reston.VA.US>
X-Orig-Sender: sipp-request 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 : SIPP Security Architecture
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-sa-02.txt
Pages : 8
Date : 04/25/1994
This memo describes the overall SIPP Security Architecture. The security
architecture is a high-level description of the several security mechanisms
for the SIPP protocol and their relationship. Each security mechanism is
specified separately.
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-sa-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-sipp-sa-02.txt".
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: <19940425145923.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-sipp-sa-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-sa-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940425145923.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08552;
26 Apr 94 10:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09571;
26 Apr 94 10:35 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08536;
26 Apr 94 10:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08390;
26 Apr 94 10:29 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-03.txt
Date: Tue, 26 Apr 94 10:29:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404261029.aa08390 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 : SIPP Authentication Header
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-ap-03.txt
Pages : 10
Date : 04/25/1994
This memo describes the SIPP Authentication Header (AH). This payload
seeks to provide integrity and authentication for SIPP datagrams.
Non-repudiation may be provided by an authentication algorithm used with
AH, but it is not provided with all authentication algorithms that might be
used with AH. Confidentiality, and protection from traffic analysis are not
provided by AH. Users desiring confidentiality should consider using the
SIPP Encapsulating Security Protocol (ESP) either in lieu of or in
conjunction with AH. This document assumes the reader has previously read
and understood the related "SIPP Security Architecture" document which
defines the overall security architecture for SIP Plus and provides
important background information for this specification.
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-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-ietf-sipp-ap-03.txt".
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: <19940425150724.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-sipp-ap-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-ap-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940425150724.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08617;
26 Apr 94 10:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09600;
26 Apr 94 10:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08583;
26 Apr 94 10:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08439;
26 Apr 94 10:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sipp at sunroof2.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-esp-02.txt
Date: Tue, 26 Apr 94 10:30:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404261030.aa08439 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 : SIPP Encapsulating Security Payload (ESP)
Author(s) : R. Atkinson
Filename : draft-ietf-sipp-esp-02.txt
Pages : 11
Date : 04/25/1994
The SIPP Encapsulating Security Payload (ESP) seeks to provide
confidentiality and integrity by encrypting data to be protected and
placing the encrypted data in the data portion of the SIPP Encapsulating
Security Payload. Either a transport-layer (e.g. UDP or TCP) frame may be
encrypted or an entire SIPP datagram may be encrypted, depending on the
user's security requirements. This encapsulating approach is necessary to
provide confidentiality for the entire original datagram, but can be very
expensive to implement. Use of this specification will increase the SIPP
protocol processing costs in participating end systems and will also
increase the communications latency. The increased latency is primarily
due to the encryption and decryption required for each SIPP datagram
containing an Encapsulating Security Payload.
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-esp-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-sipp-esp-02.txt".
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: <19940425151600.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-sipp-esp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-esp-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940425151600.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08920;
26 Apr 94 10:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09936;
26 Apr 94 10:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08880;
26 Apr 94 10:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08762;
26 Apr 94 10:46 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-direct-provider-01.txt
Date: Tue, 26 Apr 94 10:46:03 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404261046.aa08762 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Selecting a Direct Provider
Author(s) : Y. Rekhter
Filename : draft-rekhter-direct-provider-01.txt
Pages : 8
Date : 04/25/1994
Within the existing Internet routing architecture/protocols different hosts
within a domain (autonomous system) usually can't control the choice of
adjacent domains for forwarding of the inter-domain traffic originated by
the hosts. In this document we describe a simple mechanism that provides
hosts with such control. The proposed scheme can be realised with the
existing technology, off-the shelf components, and minor tweaking of
forwarding algorithm by border routers. The scheme doesn't require any new
routing protocols.
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-direct-provider-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-rekhter-direct-provider-01.txt".
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: <19940425102202.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-rekhter-direct-provider-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-direct-provider-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940425102202.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08930;
26 Apr 94 10:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09938;
26 Apr 94 10:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08895;
26 Apr 94 10:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08795;
26 Apr 94 10:46 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-rzepa-chemical-mime-type-00.txt
Date: Tue, 26 Apr 94 10:46:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404261046.aa08795 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Chemical Primary MIME Type.
Author(s) : H. Rzepa, P. Murray-Rust
Filename : draft-rzepa-chemical-mime-type-00.txt
Pages : 4
Date : 04/25/1994
This document indicates why we believe there is a need for a new primary
"chemical" MIME type. We outline the typical expected uses of such a MIME
type and propose a number of secondary chemical types.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rzepa-chemical-mime-type-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-rzepa-chemical-mime-type-00.txt".
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: <19940425133734.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-rzepa-chemical-mime-type-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rzepa-chemical-mime-type-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940425133734.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11398;
26 Apr 94 13:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11388;
26 Apr 94 13:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13650;
26 Apr 94 13:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11373;
26 Apr 94 13:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11339;
26 Apr 94 13:18 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa13610;
26 Apr 94 13:18 EDT
Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA26057 (mail destined for ietf at CNRI.Reston.VA.US) on Tue, 26 Apr 94 13:18:05 -0400
Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0)
id AA09591; Tue, 26 Apr 94 13:20:25 -0400
Message-Id: <9404261720.AA09591 at expresso.bunyip.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Peter Deutsch <peterd at bunyip.com>
Date: Tue, 26 Apr 1994 13:20:23 -0400
In-Reply-To: "W.S. Harborth"'s message as of Apr 26, 7:54
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: "W.S. Harborth" <wharbort at ghost.arpa.mil>,
IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: Duplicate Messages
[ You wrote: ]
> What is going on here? Am I the only one that is getting two copies of
> everyting from this list.
No you're not. I am, too.
No you're not. I am, too.
;-)
- peterd
--
-----------------------------------------------------------------------------
"What do thay got, a whole lot of sand? We got a hot crustacean band!
Each little clam here, know how to jam here! Under the Sea!"
-----------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12093;
26 Apr 94 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12089;
26 Apr 94 13:52 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa14407;
26 Apr 94 13:52 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA04103; Tue, 26 Apr 94 12:41:59 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA18265; Tue, 26 Apr 1994 12:41:54 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA18257; Tue, 26 Apr 1994 12:41:50 +0600
Received: from Sun.COM ([192.9.9.1]) by cray.com (Bob mailer 1.2)
id AA04094; Tue, 26 Apr 94 12:41:47 CDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA14643; Tue, 26 Apr 94 10:41:42 PDT
Received: from damrak.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA01438; Tue, 26 Apr 94 10:40:29 PDT
Received: from damrak (localhost) by damrak.Eng.Sun.COM (5.x/SMI-SVR4)
id AA12127; Tue, 26 Apr 1994 10:43:01 -0700
Message-Id: <9404261743.AA12127 at damrak.Eng.Sun.COM>
To: telnet-ietf at cray.com
Subject: Question about linemode implementation...
Date: Tue, 26 Apr 1994 10:43:00 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Parker <sparker at damrak.eng.sun.com>
Content-Length: 1402
In rfc1184 there is this text:
+ Normally, the entire user interface is left up to the implementor.
+ However, there is functionality that the user should be able to
+ specify on the client side of the connection. During a Telnet
+ session, the client side should allow some mechanism for the user to
+ give commands to the local Telnet process. These commands should at
+ least allow the user to:
+ 1) Change the mode of the connection. The user should be able to
+ attempt to turn EDIT, FLOW, TRAPSIG, and ECHO on and off. The
+ server may refuse to change the state of the EDIT and TRAPSIG
+ bits.
My question is about the last sentence above. I certainly can see how
it is good to require clients to attempt to negotiate these options
when the user requests. However, nowhere does this make clear when and
why a server might refuse these state changes.
To me, it seems clear that the server would refuse to negotiate those
options if they were in conflict with the present state of the "pty"
set by the application. For example, if the application has set the
pty into "raw" mode, negotiating remote edit should probably be refused.
(And I think I can make similar arguments about flow, trapsig and echo.)
Is it correct that a reasonable and compliant linemode server would
refuse mode changes in that way?
Cheers,
~sparker
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14490;
26 Apr 94 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14486;
26 Apr 94 16:19 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa17760;
26 Apr 94 16:19 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA13953; Tue, 26 Apr 94 14:58:30 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA03994; Tue, 26 Apr 1994 14:57:41 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA03989; Tue, 26 Apr 1994 14:57:37 +0600
Received: from tsx-11.MIT.EDU by cray.com (Bob mailer 1.2)
id AA13891; Tue, 26 Apr 94 14:57:35 CDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA00444; Tue, 26 Apr 94 15:55:49 EDT
Date: Tue, 26 Apr 94 15:55:49 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9404261955.AA00444 at tsx-11.MIT.EDU>
To: Steve Parker <sparker at damrak.eng.sun.com>
Cc: telnet-ietf at cray.com
In-Reply-To: Steve Parker's message of Tue, 26 Apr 1994 10:43:00 -0700,
<9404261743.AA12127 at damrak.Eng.Sun.COM>
Subject: Re: Question about linemode implementation...
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 872
Date: Tue, 26 Apr 1994 10:43:00 -0700
From: Steve Parker <sparker at damrak.Eng.Sun.COM>
To me, it seems clear that the server would refuse to negotiate those
options if they were in conflict with the present state of the "pty"
set by the application. For example, if the application has set the
pty into "raw" mode, negotiating remote edit should probably be refused.
(And I think I can make similar arguments about flow, trapsig and echo.)
Is it correct that a reasonable and compliant linemode server would
refuse mode changes in that way?
That might be one reason why a server might refuse changes. The server
is free to refuse changes for any reason, including the fact that it
doesn't support linemode --- or perhaps the way the server is
implemented, it isn't able to switch into linemode after the connection
is set up.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15252;
26 Apr 94 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15244;
26 Apr 94 16:59 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa18902;
26 Apr 94 16:59 EDT
Received: by bitsy.MIT.EDU
id AA10796; Tue, 26 Apr 94 16:44:49 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA10788; Tue, 26 Apr 94 16:44:48 EDT
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA04010; Tue, 26 Apr 94 16:44:39 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA01167; Tue, 26 Apr 94 16:44:27 EDT
Date: Tue, 26 Apr 94 16:44:27 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9404262044.AA01167 at tsx-11.MIT.EDU>
To: John Gardiner Myers <jgm+ at cmu.edu>
Cc: cat-ietf at mit.edu
In-Reply-To: John Gardiner Myers's message of Mon, 25 Apr 1994 20:30:02 -0400 (EDT),
<4hj62_600WBwQRsUVo at andrew.cmu.edu>
Subject: Re: Staying within the PBSZ using GSSAPI
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Mon, 25 Apr 1994 20:30:02 -0400 (EDT)
From: John Gardiner Myers <jgm+ at CMU.EDU>
tytso at ATHENA.MIT.EDU (Theodore Ts'o) writes:
> I agree. I also like John Linn's suggestion that we specify an
> "implementor's agreement" that all mechanisms support at least a 2k
> input token size.
The suggested "implementor's agreement" was that no mechanism produce
an output token more than 2k larger than the input token.
Sorry, my mistake. I still think it would be a good idea to have a
minimum input token size that all mechanisms could support, though.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15317;
26 Apr 94 17:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15313;
26 Apr 94 17:01 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa18969;
26 Apr 94 17:01 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA17239; Tue, 26 Apr 94 15:40:40 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA09355; Tue, 26 Apr 1994 15:40:33 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA09345; Tue, 26 Apr 1994 15:40:29 +0600
Received: from frenzy.cray.com (frenzy-eth.cray.com) by cray.com (Bob mailer 1.2)
id AA17211; Tue, 26 Apr 94 15:40:26 CDT
Received: by frenzy.cray.com
id AA01970; 4.1/CRI-5.6; Tue, 26 Apr 94 15:42:21 CDT
Date: Tue, 26 Apr 94 15:42:21 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9404262042.AA01970 at frenzy.cray.com>
To: sparker at damrak.eng.sun.com, telnet-ietf at cray.com
Subject: Re: Question about linemode implementation...
Content-Length: 2507
> In rfc1184 there is this text:
>
> + Normally, the entire user interface is left up to the implementor.
> + However, there is functionality that the user should be able to
> + specify on the client side of the connection. During a Telnet
> + session, the client side should allow some mechanism for the user to
> + give commands to the local Telnet process. These commands should at
> + least allow the user to:
>
> + 1) Change the mode of the connection. The user should be able to
> + attempt to turn EDIT, FLOW, TRAPSIG, and ECHO on and off. The
> + server may refuse to change the state of the EDIT and TRAPSIG
> + bits.
>
>
> My question is about the last sentence above. I certainly can see how
> it is good to require clients to attempt to negotiate these options
> when the user requests.
The goal of this section was to ensure that the client provided a way
for the user to make the request. It was assumed that the client would
turn the request into the appropriate telnet command.
> However, nowhere does this make clear when and
> why a server might refuse these state changes.
>
> To me, it seems clear that the server would refuse to negotiate those
> options if they were in conflict with the present state of the "pty"
> set by the application. For example, if the application has set the
> pty into "raw" mode, negotiating remote edit should probably be refused.
> (And I think I can make similar arguments about flow, trapsig and echo.)
On a typical UNIX based system, you can do things like "stty -echo".
This would change the state of the pty, which notifies the telnetd
of the state change, and it then sends a MODE command to the client
to let it know of the change. The telnet client interface allows
the opposite to happen. The client sends the MODE command to the
server, it takes the new mode and sends it to the pty, which then
becomes apparent to any application that looks at the pty state.
It was assumed that there might be some systems where the state
of the pty couldn't be changed by the server, and we didn't want
to make it impossible to implement linemode telnet on those systems.
> Is it correct that a reasonable and compliant linemode server would
> refuse mode changes in that way?
>
> Cheers,
>
> ~sparker
The server shouldn't refuse to change the state of these bits unless
there is a valid restriction in the pty driver that precludes changing
them.
-David Borman, dab at cray.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16821;
26 Apr 94 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16817;
26 Apr 94 19:26 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa21676;
26 Apr 94 19:26 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA27380; Tue, 26 Apr 94 18:07:07 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA24607; Tue, 26 Apr 1994 18:07:02 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA24600; Tue, 26 Apr 1994 18:06:57 +0600
Received: from Sun.COM ([192.9.9.1]) by cray.com (Bob mailer 1.2)
id AA27373; Tue, 26 Apr 94 18:06:49 CDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA28642; Tue, 26 Apr 94 16:06:41 PDT
Received: from damrak.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA11844; Tue, 26 Apr 94 16:05:40 PDT
Received: from damrak (localhost) by damrak.Eng.Sun.COM (5.x/SMI-SVR4)
id AA12901; Tue, 26 Apr 1994 16:07:39 -0700
Message-Id: <9404262307.AA12901 at damrak.Eng.Sun.COM>
To: "David A. Borman" <dab at berserkly.cray.com>
Cc: telnet-ietf at cray.com
Subject: Re: Question about linemode implementation...
Date: Tue, 26 Apr 1994 16:07:38 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Parker <sparker at damrak.eng.sun.com>
Content-Length: 1775
- > To me, it seems clear that the server would refuse to negotiate those
- > options if they were in conflict with the present state of the "pty"
- > set by the application. For example, if the application has set the
- > pty into "raw" mode, negotiating remote edit should probably be refused.
- > (And I think I can make similar arguments about flow, trapsig and echo.)
-
- On a typical UNIX based system, you can do things like "stty -echo".
- This would change the state of the pty, which notifies the telnetd
- of the state change, and it then sends a MODE command to the client
- to let it know of the change.
Sure.
- The telnet client interface allows
- the opposite to happen. The client sends the MODE command to the
- server, it takes the new mode and sends it to the pty, which then
- becomes apparent to any application that looks at the pty state.
So when should it look at its pty state? Before now there hasn't been
anything turning on and shutting off bits like "ECHO" and "ICANON".
The application isn't _notified_ when this stuff gets changed. And
applications shouldn't have to be changed to work with telnet.
If the application allows echo, then it seems perfectly fine if telnet
negotiates echo back and forth between local and remote. It doesn't
seem fine to me if the client can re-arrange virtual terminal behavior
my application has specified. It also doesn't seem right to me that
the application should see the "echo bit" off, just because echoing
is being done by the telnet client.
At least in the UNIX world, a process which continuously holds a
controlling terminal does not need to keep querying the terminal
modes: it is assured the system isn't going to change it.
I guess this means I'm unconvinced? :)
Cheers,
~sparker
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18000;
26 Apr 94 21:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17998;
26 Apr 94 21:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23559;
26 Apr 94 21:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17977;
26 Apr 94 21:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17902;
26 Apr 94 21:24 EDT
Received: from uucp4.netcom.com by CNRI.Reston.VA.US id aa23492;
26 Apr 94 21:24 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id SAA14707; Tue, 26 Apr 1994 18:04:08 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA23377; Tue, 26 Apr 1994 18:00:03 -0700
Date: Tue, 26 Apr 1994 18:00:03 -0700
Message-Id: <9404270100.AA23377 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: faces test for experimental rfctest2.html
Reply-To: Lynn Wheeler <lynn at bli.com>
Ken Hardwick didn't seemed me his face's URL .. but I did get a test
gif from him ... try selecting on "Hardwick. K" in the author's index
(ftp://ftp.netcom.com/pub/lynn/rfctest2.html). (he sort of owed me
one, long ago and far away I did a product rfc1044 implementation).
keep those author faces URLs coming in.
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00679;
27 Apr 94 2:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00669;
27 Apr 94 2:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01335;
27 Apr 94 2:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00642;
27 Apr 94 2:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00556;
27 Apr 94 2:36 EDT
Received: from eis.CalState.EDU by CNRI.Reston.VA.US id aa01115;
27 Apr 94 2:36 EDT
Received: from [130.150.1.15] (swrl15.slip.csu.net) by eis.calstate.edu (4.1/KNMods2.1)
id AA25444; Tue, 26 Apr 94 23:36:33 PDT
Date: Tue, 26 Apr 94 23:36:29 PDT
Message-Id: <9404270636.AA25444 at eis.calstate.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ray Harder <rharder at eis.calstate.edu>
Reply-To: Ray Harder <rharder at eis.calstate.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Repetitions?
Am I the only one who is receiving all postings from this list three times?
(Usually with other mail between the second and third one.) My other mail seems
fine.... I am receiving mail from the Cal State University backbone which is
attched to CERFNET (?) I Think....
I would be interested in corresponding off the list with a patient engineer
regarding these matters
Ray
****************************************************************************
* Raymond G. Harder "Can't walk today, I don't feel well."*
* Educational Technology Consultant "Why don't you sit out in the sun?" *
* 909-983-4713 "What? People will think I'm lazy!" *
* rharder at ctp.org -- My 92 year old grandmother *
****************************************************************************
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01201;
27 Apr 94 4:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01191;
27 Apr 94 4:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02250;
27 Apr 94 4:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01178;
27 Apr 94 4:13 EDT
Received: from bells.cs.ucl.ac.uk by IETF.CNRI.Reston.VA.US id aa01142;
27 Apr 94 4:11 EDT
Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.29765-0 at bells.cs.ucl.ac.uk>; Wed, 27 Apr 1994 09:10:17 +0100
To: tccc at cs.umass.edu
To: comp.dcom.cell-relay at news-relay.indiana.edu
To: ietf at IETF.CNRI.Reston.VA.US
Reply-To: craig at bbn.com
Subject: Funding for Students to Attend SIGCOMM
Date: Wed, 27 Apr 94 09:10:11 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: C.Partridge at cs.ucl.ac.uk
Message-ID: <9404270411.aa01142 at IETF.CNRI.Reston.VA.US>
Hi folks:
I wanted to make folks aware that NSF and ARPA have provided
some money to fund 8 graduate students in the US to attend SIGCOMM '94
in London August 31 to Sep 2. Funding is only for graduate students of
US institution and students must apply to a SIGCOMM panel for a travel
grant. Details of how to apply and where to send applications will
appear in about two weeks. (This note is being circulated so you
know to look for the ad).
Craig
**************************************************************************
DRAFT SIGCOMM TECHNICAL PROGRAM (subject to change)
Tuesday Evening: Reception
Wednesday: Keynote Address (ACM SIGCOMM Award Winner)
Wednesday: Protocol Performance
Experiences with a High-Speed Network Adaptor: A Software Perspective;
P. Druschel, L.L. Peterson, and B.S. Davie. (Best Student Paper).
User-space Protocols Deliver High Performance to Applications on a Low-Cost
Gb/s LAN; G. Watson, A. Edwards, J. Lumley, D. Banks, C. Calamvokis,
and C. Dalton
TCP Vegas: New Techniques for Congestion Detection and Avoidance;
L.S. Brakmo, L.L. Peterson, and S.W. O'Malley
A Structured TCP in Standard ML; E. Biagioni
Wednesday: Congestion Management
Making Greed Work in Networks: A Game-Theoretic Analysis of Switch Service
Disciplines; S. Shenker
Scalable Feedback Control for Multicast Video Distribution in the Internet;
J. Bolot, T. Turletti and I. Wakeman
Statistical Analysis of Generalized Processor Sharing Scheduling
Discipline; Z.-L. Zhang, D. Towsley, and J. Kurose
Wednesday: ATM Flow Control
The Dynamics of TCP Traffic over ATM Networks; A. Romanow and S. Floyd
Reliable and Efficient Hop-by-Hop Flow Control; G. Varghese, C. Ozveren
and R. Simcoe.
Credit Updated Protocol for Flow-Controlled ATM Networks: Statistical
Multiplexing and Adaptive Credit Allocation; H.T. Kung, T. Blackwell,
and A. Chapman
Wednesday Evening: SIGCOMM Social
Thursday: Internet Routing
Flexible Routing and Addressing for a Next Generation IP; R. Govindan
and P. Francis
An Architecture for Wide-Area Multicast Routing; D. Estrin, S. Deering,
D. Farinacci, V. Jacobson, C.-G. Liu and L. Wei
Distributed Routing Based on Link-State Vectors; J. Behrens and J.J.
Garcia-Luna-Aceves
Thursday: ATM Switching and Signalling
Signaling and Operating System Support for Native-Mode ATM Applications;
S. Keshav and R. Sharma
Experiences of Building ATM Switches for the Local Area; D.R. McAuley,
R.J. Black and I.M. Leslie
Controlling Alternate Routing in General-Mesh, Rate-Based Networks
using a Lightweight State-Protection Scheme; A. DeSimone and S. Sibal
Thursday: Neural and Optical Networks
On Optimization of Polling Policy Represented by Neural Network;
Y. Matsumoto
An Optical Deflection Network; J. Feehrer, L. Ramfelt, and J. Sauer
Conflict-Free Channel Assignment for an Optical Cluster-Based Shuffle
Network Configuration; K.A. Aly
Thursday: Selected Topics
MACAW: A Media Access Protocol for Wireless LANs; B. Vaduvur,
A. Demers, S. Shenker and L. Zhang.
Asymptotic Resource Consumption in Multicast Reservation Styles;
D.J. Mitzel and S. Shenker
Highly Dynamic Destination-Sequenced Distance-Vector Routing (DTDV) for
Mobile Computers; C.E. Perkins and P. Bhagwat
A Methodology for Designing Communication Protocols; G. Singh
Thursday Evening: SIGCOMM Business Meeting
Friday: Traffic Models
Wide-Area Traffic: The Failure of Poisson Modeling; V. Paxson and S. Floyd
Analysis, Modeling and Generation of Self-Similar VBR Video Traffic; M.W.
Garrett and W. Willinger
An Algorithm for Lossless Smoothing of MPEG Video; S.S. Lam, S. Chow,
and D. Yau
Friday: Host Software
USC: A Universal Stub Compiler; S.W. O'Malley, T. Proebsting, and
A. Montz
An Object-based Approach to Protocol Software Implementation;
C.-S. Liu
Improved Algorithms for Synchronizing Computer Network Clocks;
D.L. Mills
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01682;
27 Apr 94 5:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01672;
27 Apr 94 5:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03127;
27 Apr 94 5:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01648;
27 Apr 94 5:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01608;
27 Apr 94 5:23 EDT
Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa03086;
27 Apr 94 5:23 EDT
Received: from ptpc00.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA27121; Wed, 27 Apr 1994 11:23:36 +0200
Received: by ptpc00.cern.ch (NX5.67d/NX3.0S)
id AA00448; Wed, 27 Apr 94 11:23:18 +0200
Date: Wed, 27 Apr 94 11:23:18 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tim Berners-Lee <timbl at ptpc00.cern.ch>
Message-Id: <9404270923.AA00448 at ptpc00.cern.ch>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: kasten at ftp.com
Subject: Re: entirely toooooooo weird
Cc: ietf at CNRI.Reston.VA.US
Reply-To: timbl at www0.cern.ch
> E-Mail on Underwear
There does seem to be some confusion. When I was married, a
local paper in Falmouth MA, where my wife had spent some time,
reported that she was marrying a specialist in softwear.
Tim BL
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06496;
27 Apr 94 11:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06491;
27 Apr 94 11:18 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa08962;
27 Apr 94 11:18 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA07274; Wed, 27 Apr 94 10:09:16 CDT
Received: from berserkly.cray.com by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA05797; Wed, 27 Apr 1994 10:09:08 +0600
Received: by berserkly.cray.com
id AA08644; 5.64/CRI-4.9; Wed, 27 Apr 94 10:08:46 -0500
Received: by berserkly.cray.com
id AA08638; 5.64/CRI-4.9; Wed, 27 Apr 94 10:08:33 -0500
Date: Wed, 27 Apr 94 10:08:33 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Borman <dab at berserkly.cray.com>
Message-Id: <9404271508.AA08638 at berserkly.cray.com>
To: sparker at damrak.eng.sun.com
Subject: Re: Question about linemode implementation...
Cc: telnet-ietf at cray.com
Content-Length: 4670
Mike said it correctly, having the telnet client able to
change the state of the ECHO(TRAPSIG,EDIT) bits is like
doing
"stty -echo(isig,icanon) </dev/tty_whatever"
> So when should it look at its pty state? Before now there hasn't been
> anything turning on and shutting off bits like "ECHO" and "ICANON".
> The application isn't _notified_ when this stuff gets changed. And
> applications shouldn't have to be changed to work with telnet.
Normally it isn't real useful, and can (will) confuse applications
because they don't know that the state of the pty/tty has changed.
> If the application allows echo, then it seems perfectly fine if telnet
> negotiates echo back and forth between local and remote. It doesn't
> seem fine to me if the client can re-arrange virtual terminal behavior
> my application has specified. It also doesn't seem right to me that
> the application should see the "echo bit" off, just because echoing
> is being done by the telnet client.
Oh my. By these statements it now becomes clear to me that you do
not have a clear understanding of how linemode works, and what
support is needed in the terminal driver on the server to allow
linemode to work.
The goal of linemode is to offload the input character processing
from the server to the client, without any noticable change to
the application that is attached to the slave side of the pty.
The meaning of the "echo", "isig", "icanon", "oxtabs", "ixany" bits
should not change as far as the application is concerned.
On BSD systems, this is acheived via the EXTPROC bit. This bit
is set by the telnet server when it is running in linemode. Most
of the input processing is then skipped, because it knows that that
has already happened externally (in the client).
The usage of the ECHO option can be especially confusing if you
don't think it through. When the server is WILL ECHO, it means
that the server will be echoing back any characters of the input
stream that need to be echoed back to the screen. When the server
is WONT ECHO, it means that the server will not be echoing back
any of the input characters, so the client will be responsabile
for doing any character echo back to the screen that needs to be
done.
So, with this in mind, with the EXTPROC bit set the terminal
driver on the server will never echo any characters, no matter
what the state of the "echo" bit in the tty. When the "echo"
bit is set in the tty, the server will negotiate "WONT ECHO",
which tells the client that it needs to do any terminal echo.
When the "echo" is off, the server will negotiate "WILL ECHO",
which tells the client that it should not do any terminal echo,
because the server will take care of any that needs to be done.
But the server doesn't do any echoing, so you get the effect that
you want, no terminal echo. When the application turns the "echo"
bit back on, the server negotiates "WONT ECHO" again.
As an example, here is what happens on a BSD system when turning
off and on various state bits in the tty, when telnet option
debugging is turned on:
% stty -icanon
RCVD IAC SB LINEMODE MODE TRAPSIG|SOFT_TAB
SENT IAC SB LINEMODE MODE TRAPSIG|SOFT_TAB|ACK
% stty icanon
RCVD IAC SB LINEMODE MODE EDIT|TRAPSIG|SOFT_TAB
SENT IAC SB LINEMODE MODE EDIT|TRAPSIG|SOFT_TAB|ACK
% stty -echo
RCVD WILL ECHO
SENT DO ECHO
% <typed "stty echo">
RCVD WONT ECHO
SENT DONT ECHO
% stty -isig
RCVD IAC SB LINEMODE MODE EDIT|SOFT_TAB
SENT IAC SB LINEMODE MODE EDIT|SOFT_TAB|ACK
% stty isig
RCVD IAC SB LINEMODE MODE EDIT|TRAPSIG|SOFT_TAB
SENT IAC SB LINEMODE MODE EDIT|TRAPSIG|SOFT_TAB|ACK
% stty -oxtabs
RCVD IAC SB LINEMODE MODE EDIT|TRAPSIG
SENT IAC SB LINEMODE MODE EDIT|TRAPSIG|ACK
% stty oxtabs
RCVD IAC SB LINEMODE MODE EDIT|TRAPSIG|SOFT_TAB
SENT IAC SB LINEMODE MODE EDIT|TRAPSIG|SOFT_TAB|ACK
% stty -ixon
RCVD IAC SB TOGGLE-FLOW-CONTROL OFF
% stty ixon
RCVD IAC SB TOGGLE-FLOW-CONTROL ON
% stty -ixany
RCVD IAC SB TOGGLE-FLOW-CONTROL RESTART-XON
% stty ixany
RCVD IAC SB TOGGLE-FLOW-CONTROL RESTART-ANY
The two features that need to be implemented in the terminal driver
on the server is:
1) The ability to turn off input character processing
(including character echo), by having the terminal
driver ignore those state bits (icanon, echo, isig,
etc.) In BSD this is done through the EXTPROC bit.
2) The application on the master pty side has to be
notified whenever the state of the pty changes, so
that it can negotiate the appropriate new state with
the client.
Without both of these features, you cannot do a transparent (to
the application) implementation of server linemode.
-David Borman, dab at cray.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09381;
27 Apr 94 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09377;
27 Apr 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12746;
27 Apr 94 14:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09366;
27 Apr 94 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09362;
27 Apr 94 14:43 EDT
Received: from itd.nrl.navy.mil by CNRI.Reston.VA.US id aa12738;
27 Apr 94 14:43 EDT
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA09850; Wed, 27 Apr 94 14:39:41 EDT
Date: Wed, 27 Apr 94 14:39:41 EDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Allison Mankin <mankin at itd.nrl.navy.mil>
Message-Id: <9404271839.AA09850 at itd.nrl.navy.mil>
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US
Subject: IPng Area Update
This is a quick update on the status of the IETF IPng effort.
Since the creation of the IPng area late last year we have been focused on
two primary tasks; developing a reasonable estimate of the projected
lifetime for the IPv4 address space and producing a draft requirements
document.
The IPv4 Address Expectations Working Group (ALE), chaired by Frank
Solensky and Tony Li reported during a session held at the IETF meeting in
Seattle that their current estimate was that the IPv4 address supply would
be exhausted in the year 2008 ( plus or minus 3 years), assuming no changes
in the basic rate of growth in the demand for addresses. Clearly, if there
were a request for a very large block (many millions) of addresses, it
would affect this estimate.
The Transition and Coexistence Including Testing (TACIT) working group,
chaired by Atul Bansal and Geoff Huston had its first meeting in Seattle.
This group will focus on the long term transition and coexistence issues
and will define recommendations for testing IPng specifications and
implementations.
Of course, the working groups for each of the IPng candidates have been
busy and did meet in Seattle to further refine the details of their
proposals.
The IPng Requirements BOF, chaired by Frank Kastenholz and Jon Crowcroft,
has produced a draft of an IPng requirements document. The current draft
is a refinement of an initial document by Frank Kastenholz and Craig
Partridge. It reflects input from a number of the white papers that the
IPng area solicited with RFC1550 and comments from the IPng directorate.
The requirements draft is ready for public comment. It has been published
as an internet-draft (draft-kastenholz-ipng-criteria-01.txt). We need
as many comments as possible by May 10. All interested
persons (that should be just about all reading this message)
should take a look at this document and, if you have comments or
suggestions, send them to the big-internet list. (Send a note to
big-internet-request at munnari.oz.au to subscribe.) You should also take a
look at the RFC1550 white papers, they have been published as internet
drafts. Look for any internet draft with "ipng" in its filename. All of
these documents are available at you favorite internet-drafts site and from
hsdndev.harvard.edu in pub/ipng/wp for anonymous ftp. Hsdndev also allows
gopher access.
The IPng directorate mailing list archives and directorate teleconference
minutes are also available from hsdndev.
We urge you to take a look at these documents and records. Let us know on
the big-internet list or in private mail what you think. This is an effort
that will effect us all and anyone who can help make the result better or
the transition easier is encouraged to participate.
Appended to this update is the area status report from the Seattle IETF
meeting.
Scott & Allison
IETF 29
IP: Next Generation Area Report
Seattle, Washington
Scott Bradner <sob at harvard.edu>
Allison Mankin <mankin at cmf.nrl.navy.mil>
Meetings of 4 IP: Next Generation working group, 3 BOFs, and an
open IPng directorate meeting were held during the 29th IETF meeting
in Seattle, Washington.
Address Extension by IP Option Utilisation BOF (AEIOU)
Reported by Peter Ford
Chair Brian Carpenter <brian at dxcoms.cern.ch>
Brian Carpenter presented the aeiou proposal (draft-carpenter-aeiou-00.txt)
and there was a lively discussion. Most people felt that aeiou would work
and could, with effort, be developed into a viable stop-gap solution.
There was one significant technical issue, the impact of option analysis
on local router performance. The main debate was whether the savings in
work and time to implement and deploy aeiou compared to a full IPng
solution were significant and worthwhile. There was a range of views on
this. The conclusion was not to propose an aeiou working group at this
time, but to document the proposal (possibly as an Informational RFC)
to keep it in reserve for future eventualities. Interested people
should contact brian at dxcoms.cern.ch.
Address Lifetime Expectations WG (ALE)
Reported by Tony Li
Chairs: Tony Li <tli at cisco.com>, Frank Solensky <solensky at ftp.com>
The ALE WG met to discuss its projections and future mechanisms for
improving the lifetime of the address space. Our current projections
were presented and subsequent discussion ensued. As a result, ALE
will also begin to track routing table sizes. We have volunteers to
collect data for us. We discussed address efficiency and have a
volunteer to produce a document on improving address space efficiency.
RFC 1597 was presented, and was thought to be very helpful. We
discussed the timetable for IPng, but were unable to come to any
reasonable conclusions due to uncertainty about the deployment of CIDR
and the explosion of the routing tables.
Common Architecture for Next-Generation IP WG (CATNIP)
Reported by Robert Ullmann
Chair (pro tem) Robert Ullmann <robert_ullmann at lotus.com>
WG meeting was chaired pro-tem by Robert Ullmann, as Vladimir
Sukonnik was unable to attend. Robert did a small soapbox on
the proper scope of the IPng proposals. This was followed by
discussion of a number of minor technical issues identified
recently on the CATNIP list. Several IPX related issues were
left uncertain. The issue of TUBA TCP and UDP checksums to be
discussed with the TUBA WG. DNS issues to be resolved in a near
future revision of the Collela/Manning draft which will be used
by both TUBA and CATNIP. Fragment translation was discussed, with
the differring semantics between CLNP, IPv4, and SIPP making it
less useful than would be expected.
IPNG Requirements WG (NGREQS)
Reported by Frank Kastenholz
Chairs Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>,
Frank Kastenholz <kasten at Research.Ftp.Com>
The working group had a number of presentations from members of the
community who are experts in particular technical areas. These included
Mike StJohns on Security, Greg Minshall on Mobility, Dave Clark on Network
Services, Lixia Zhang on RSVP, Mark Handly on AVT, Peter Ford on
Backbones, and John Curran on Market Needs. The intent was to give the
group background information on these particular areas and their specific
needs -- similar to the White Papers solicited by the Directorate.
The working group then proceeded into a lively and spirited debate on the
various criteria. The community suggested many significant improvements
which are still being digested by the chairs and authors. One important
improvement that seemed to have great support from the community was that
the requirements should be strengthened amd made firmer -- fewer "should
allows" and the like and more "musts".
SIPP WG
Reported by Bob Hinden
Chair Bob Hinden <Bob.Hinden at eng.sun.com>
March 1994 IETF
The SIPP working group held a implementors meeting on Sunday afternoon
and two working group sessions on Wednesday and Thursday.
Bob Hinden presented a summary of recent working group activities. This
included that the SIPP charter had been approved, the SIPP Whitepaper had
been completed on time, a summary of the SIPP specifications which had
been completed since the last IETF meeting, and the SIPP specifications
which were submitted to the IPng area directors for publication as
experimental RFC's. Also presented was the announcement that Mosaic
pages had been created for the SIPP working group. These can be found at
http://town.hall.org
Jim Bound presented a summary of the implementors meeting. A number of
SIPP implementors had attended and several refinements had been made to
some of the SIPP options based on implementation experience. These
changes will be documented in an update to the SIPP specification.
Steve Deering presented an overview of the changes from last fall's SIP
spec to the current SIPP specification. This included details on the
layout of the Flow ID. Ramesh Govindan and Sue Thompson presented the
current approach for dealing with auto configuration and discovery. This
resolved the issues that were outstanding with the current drafts. New
specifications will be published.
Bob Gilligan presented an overview of IPAE. This resulted in a
discussion of some of the details of IPAE and uncovered a bug. There was
general agreement that IPAE needs to be simplified. This will be worked
on and the specification will be updated.
The Transition and Coexistence including Testing (TACIT) BOF
Reported by Geoff Huston
Chairs: Geoff Huston <G.Huston at aarnet.edu.au>
Atul Bansal <bansal at lkg.dec.com>
The BOF discussed the issues relating to transition and coexistence
in general terms as they relate to the constituency of the Internet, and
also discussed the specific issues relating to potential IPng transition
environments. The view was expressed that the characteristics and potential
timeframe of transition, coexistence and testing processes will be greatly
influenced through the interplay of market forces within the Internet, and
that any IPng transition plan should recognise these motivations and provide
ample levels opportunity identification to encourage the broad Internet
constituency to subscribe to the transition process (and therefore undertake
to meet the associated deployment costs of such transition).
The group decided to recommend to the IPNG Area Directoriate to form a
Working Group to explore the generic issues of the IPng transition process
and gather experience from previous technology transition that have occured
both within the Internet and within related networking technologies. A draft
charter was reviewed, with the view that this Working Group work would
contribute to the IETF IPng process by identifying these issues and reviewing
IPng transition plans at the appropriate phase of the IPng process.
TCP and UDP with Big Addresses (TUBA) WG
Reported by Peter Ford
Chairs Peter Ford <peter at goshawk.lanl.gov>
Mark Knopper <mak at aads.com>
Dave Marlow presented an update on the status of CLNP multicast. His
Internet Draft is intended to be multicast routing protocol independent,
and was presented from the ES viewpoint. Discussion ensued as to whether
the complexity of the network-to-data-link address mapping protocol was
worthwhile. The "extra hop" problem is widely viewed as being a
show-stopper and Dave presented an approach to address this problem and will
be updating the ID to reflect this.
Lyman Chapin updated the group on the electronic availability of the
pertinent ISO standards. Lyman is now comfortable
posting these documents as I-Ds and the network layer protocols (CLNP,
IS-IS, ES-IS and IDRP) will all be published by the end of the Seattle
IETF.
Dino Farinacci gave a short presentation on the status of Protocol
Independent Multicasting (PIM) in the IDMR working group. He noted there
would be little difficulty in using PIM for multicast routing of CLNP.
Ross Callon presented his work on flows in CLNP. In this scheme the
source NSEL is used to demultiplex flows between a single host pair.
The size of this field (eight bits) was a source of controversy and there
was concern that using the Source NSEL might cause to non-TUBA CLNP
entitities.
Dave Piscitello gave an overview of the current TUBA transition document.
Bob Brenner from GTE gave an overview of Cellular Packet Data Network
(CDPD). CDPD is using CLNP as an underlying protocol, but it can support
mobile hosts that are either CLNP or IP speakers.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12364;
27 Apr 94 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12353;
27 Apr 94 17:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16280;
27 Apr 94 17:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12341;
27 Apr 94 17:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12294;
27 Apr 94 17:39 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa16205; 27 Apr 94 17:39 EDT
Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA18185; Wed, 27 Apr 1994 17:39:14 -0400
Date: Wed, 27 Apr 94 20:47:26 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <2267.bill.simpson at um.cc.umich.edu>
To: qed at rice.edu
Cc: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: recent AN_S PSI route flapping
OK, I'm back after a beautiful weekend at the 50th New England Folk Festival,
and am now catching up on 1.8 MB of email.
> From: Curtis Villamizar <curtis at ans.net>
> I just checked the nets.unl.now files and the combination 1:2149 2:174
> and 1:2149 alone both appear 2389 times, meaning that all PSI nets
> announced at E136 are configured to be backed up at E133. Apparently
> withdrawing the fallback was never implemented.
>
> I cannot provide proof of what occurred since we are not archiving
> routing logs since we made the transition from rcp_routed to gated.
>
I can definitively say that the routes did not fall back, based on
observation of 6 traceroutes a minute.
Is there a latency in the gated, so that no route is in the routing
table during a transient?
By what I observed, we went from routing through MAE-EAST, then no
route at Merit ENSS, then routing to MAE-EAST (but no reply after that
point), to routing through again.
> > I would say this is only a very weird definition of "working", in that
> > it's failing to work but that's how it's configured.
>
> Well it wasn't configured that way. I also agree that this is a poor
> definition of working, but in some cases working means working as the
> client network has asked it to be configured.
>
It is a very poor definition of working, and not compatible with what is
expected from an IP routing protocol.
Noting that there are 2389 entries between these two nets alone, aren't
we backing into a corner where hand configuring these policy tables will
be intractable?
I will note that there are T1 inter-connections between AN_S and PSI in
at least two places here in Michigan. Why aren't these in the table for
Heartland sites? What about the probably hundreds of other multi-homed
sites?
Sounds to me like policy routing is already out of its depth, and we
should abandon it in favor of something dynamic.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12855;
27 Apr 94 18:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12847;
27 Apr 94 18:32 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa17009;
27 Apr 94 18:32 EDT
Received: by bitsy.MIT.EDU
id AA29596; Wed, 27 Apr 94 18:14:10 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA29588; Wed, 27 Apr 94 18:14:08 EDT
Received: from relay1.UU.NET by MIT.EDU with SMTP
id AA00902; Wed, 27 Apr 94 18:14:02 EDT
Received: from kerby.ocsg.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwnmm24552; Wed, 27 Apr 94 18:13:57 -0400
Received: from localhost (z at localhost) by kerby.ocsg.com (8.6.4/8.6.4, dpg hack 10jan94) id PAA09160 for cat-ietf at mit.edu; Wed, 27 Apr 1994 15:13:49 -0700
Date: Wed, 27 Apr 1994 15:13:49 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: testuser <z at ocsg.com>
Message-Id: <199404272213.PAA09160 at kerby.ocsg.com>
To: cat-ietf at mit.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13675;
27 Apr 94 20:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13667;
27 Apr 94 20:15 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa18552;
27 Apr 94 20:15 EDT
Received: by bitsy.MIT.EDU
id AA01230; Wed, 27 Apr 94 20:04:07 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA01222; Wed, 27 Apr 94 20:04:01 EDT
Received: from relay2.UU.NET by MIT.EDU with SMTP
id AA07440; Wed, 27 Apr 94 20:03:42 EDT
Received: from kerby.ocsg.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwnmu15509; Wed, 27 Apr 94 20:02:30 -0400
Received: from localhost (uucp at localhost) by kerby.ocsg.com (8.6.4/8.6.4, dpg hack 10jan94) with UUCP id RAA10323; Wed, 27 Apr 1994 17:01:27 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA04417; Wed, 27 Apr 94 16:58:27 -0700
Date: Wed, 27 Apr 94 16:58:27 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at ocsg.com>
Message-Id: <9404272358.AA04417 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: cat-ietf at mit.edu
Subject: Questions regarding GGS/Kerberos names
Cc: gssapi at ocsg.com
Reply-To: dpg at ocsg.com
I have some questions regarding the specifications contained in
Section 2 (Name Types and Object Identifiers) of the March, 1994
Kerberos Version 5 GSS-API Mechanism draft RFC.
* Section 2.2 describes the GSS name form in terms of a Kerberos
principal. Section 2.2 seems to provide utility for a developer
working at both the GSS and Kerberos API layers. Such cases should
be infrequent and raise questions regarding circumvention of GSS or
mechanism integrity.
To pass a Kerberos principal to gss_import_name() it must be
encapsulated in a gss_buffer. This raises the question: what is the
gss_buffer's length? Further, it implies the gss_buffer cannot be
deleted using gss_release_buffer().
What is the benefit of the GSS name form described in Section 2.2?
* Section 2.3 describes the GSS name form: service at hostname.
How is Kerberos realm information included in the form described in
Section 2.3?
* Section 2.4 appears to be no different than Section 2.1.
Are sections 2.4 and 2.1 different and if they are different that
what are the differences?
* Sections 2.5 and 2.6 describe a GSS name in terms of a UID (user
ID). Those specifications seem tailored to a UNIX environment. My
questions regarding the forms described in Sections 2.5 and 2.6 are:
* If the environment is DOS, NT, or a Mac then what is a UID?
* How is Kerberos realm information included in the UID forms?
* What utility do Sections 2.5 and 2.6 provide that section 2.4
does not provide?
Section 2.5 appears to have the same problems as Section 2.2
regarding buffer length and deletion.
Kerberos has several principal types but only three are commonly
useful to an application developer: KRB5_NT_PRINCIPAL,
KRB5_NT_SRV_HST, and KRB5_NT_UNKNOWN. Section 2.1 addresses the
Kerberos principal type KRB5_NT_PRINCIPAL. Section 2.3 addresses the
Kerberos principal type KRB5_NT_SRV_HST. I see no section that
addresses the Kerberos principal type KRB5_NT_UNKNOWN. (The most
common use of KRB5_NT_UNKNOWN is as a parameter to
krb5_sname_to_principal() indicating the host name is not to be
canonicalized.)
Since GSS/Kerberos names can be commonly expressed in three Kerberos
principal forms (KRB5_NT_PRINCIPAL, KRB5_NT_SRV_HST, and
KRB5_NT_UNKNOWN) then why not specify only those three forms? The
remaining forms such as UID translation can be provided in OS
specific libraries.
(I would appreciate responses to this message be CC's to me. I have
been removed from the cat-ietf mailing list. Why? I dunno. I have
sent requests for subscription.)
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19608;
27 Apr 94 23:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19598;
27 Apr 94 23:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21444;
27 Apr 94 23:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19587;
27 Apr 94 23:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19555;
27 Apr 94 23:24 EDT
Received: from fcr.FCR.Com by CNRI.Reston.VA.US id aa21408; 27 Apr 94 23:24 EDT
Received: from stemwinder.fcr.com by fcr.fcr.com (4.1/SMI-4.1)
id AA13700; Wed, 27 Apr 94 23:23:52 EDT
Received: by stemwinder.fcr.com (4.1/SMI-4.1)
id AA07097; Wed, 27 Apr 94 23:23:08 EDT
Date: Wed, 27 Apr 94 23:23:08 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brad Parker <brad at fcr.com>
Message-Id: <9404280323.AA07097 at stemwinder.fcr.com>
To: ietf at CNRI.Reston.VA.US
Cc: throop at wilder.com
Subject: Internet connectivity in the Costa Rican jungle?
I'll probably get flamed for asking this here, but I honestly could not
think of a better place.
Problem:
A group of researchers working in a remote area of Costa Rica
would like email connectivity to the Internet. Currently they drive 5
hours to a small town where they share a FAX machine with about 80
other people. They could use a slightly higher bandwidth communication
channel. Apparently there are no phone lines anywhere near their
location.
Also, since this is not a commercial project, money is an
issue. (so running a fiber optic cable across the country or having
phone lines installed is not possible).
I thought real hard about this but most of my experience is
with ethernet, modems and leased lines. Even the spread spectrum
wireless devices I've seen will only do line of sight for about 10
miles (or less).
Does anyone have any experience with VSAT? We can skip over
the know problems with satellites (half-duplex + very long turn around
delays). I'm just curious if this is a solution at all i.e. can one
buy a small aperture dish + box and pump IP though it on a research
budget.
Does that "satellite cell-phone in a brief case" I saw in the
Steven Segall movie really exist? (the one where the ship's cook
saves the world from nuclear winter) Can I run a modem through it?
(even at 1200 baud this would be a win). I'm only half joking here -
I seem to recall seeing something like it on the open market. (ok,
maybe it's a bit Dick Tracey but I had to ask).
If you have any suggestions, please send them to me. I
figured with all these bright people someone would have run across
this sort of problem before and found a creative solution.
And please, no boat full of magtape replies... ;-) These folks use
PC's.
-brad
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11398;
28 Apr 94 11:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06717;
28 Apr 94 11:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11330;
28 Apr 94 11:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10794;
28 Apr 94 10:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rdbmsmib at us.oracle.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-rdbmsmib-mib-03.txt
Date: Thu, 28 Apr 94 10:44:48 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404281044.aa10794 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 Relational Database
Management Systems MIB Working Group of the IETF.
Title : RDBMS-MIB
Author(s) : D. Brower, R. Purvy, A. Daniel,
M. Sinykin, J. Smith
Filename : draft-ietf-rdbmsmib-mib-03.txt
Pages : 41
Date : 04/26/1994
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
relational database (RDBMS) implementations.
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-rdbmsmib-mib-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-ietf-rdbmsmib-mib-03.txt".
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: <19940427094434.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-rdbmsmib-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rdbmsmib-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940427094434.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11744;
28 Apr 94 11:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11736;
28 Apr 94 11:16 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa07123;
28 Apr 94 11:16 EDT
Received: by bitsy.MIT.EDU
id AA11894; Thu, 28 Apr 94 10:58:23 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA11886; Thu, 28 Apr 94 10:58:13 EDT
Received: from mgm.ctt.bellcore.com by MIT.EDU with SMTP
id AA11877; Thu, 28 Apr 94 10:57:55 EDT
Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA08897
(5.65c/IDA-1.4.4 for <cat-ietf at mit.edu>); Thu, 28 Apr 1994 10:57:52 -0400
Received: from bartman.secure.bellcore.com.secure (bartman.secure.bellcore.com) by shadow.secure.bellcore.com with SMTP id AA04352
(5.65c/IDA-1.4.4); Thu, 28 Apr 1994 10:57:51 -0400
Date: Thu, 28 Apr 1994 10:57:51 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <199404281457.AA04352 at shadow.secure.bellcore.com>
To: Everette_Allen at ncsu.edu
Subject: Re: Kerberized mail --> Anyone kerberize ipop/imap?
Cc: kerberos at mit.edu, cat-ietf at mit.edu
John Gardiner Myers <jgm+ at CMU.EDU> is working on adding strong
authentication to IMAP.
-- Steve
> From: Everette Gray Allen <Everette_Allen at ncsu.edu>
> Organization: NCSU Computing Center
> Subject: Kerberized mail --> Anyone kerberize ipop/imap?
>
> I need to talk to folks who are working with large mail setups under kerberos.
> I would like to know if anyone has kerberized any of the ipop/imap servers.
> What would be neat is to be able to move the users mailbox on the fly to
> different afs serves and them still be able to get mail with any old pop
> client. I am not real interested in moding user agents to do kpop but instead
> maybe using APOP to speak to a server like ipop which can look up the user in
> hesiod and make an imap connection to the mailbox dejour and spool the mail to
> them. I would seem to be secure and if the "kaipop" were considered a client
> and spoke to a kerberized imapd then that would be great too. Of course if
> someone has a nice kerberized, hesioded, Eudora-like mail agent for motif,
> Window, and MacOS then that might work too.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12074;
28 Apr 94 11:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12064;
28 Apr 94 11:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07473;
28 Apr 94 11:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12042;
28 Apr 94 11:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11953;
28 Apr 94 11:27 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa07418; 28 Apr 94 11:27 EDT
Received: from pm002-02.dialip.mich.net (pm002-02.dialip.mich.net [35.1.48.83]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA26237 for <ietf at CNRI.Reston.VA.US>; Thu, 28 Apr 1994 11:27:12 -0400
Date: Thu, 28 Apr 94 14:51:08 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <2286.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: Internet connectivity in the Costa Rican jungle?
Might as well use the same thing Steve Roberts was using on the bike --
the Qualcomm satellite uplink. I understand they use it on trucks all
over the hemisphere.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12825;
28 Apr 94 11:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12821;
28 Apr 94 11:54 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa08205;
28 Apr 94 11:54 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA26114; Thu, 28 Apr 94 10:45:47 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA27374; Thu, 28 Apr 1994 10:45:42 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA27364; Thu, 28 Apr 1994 10:45:37 +0600
Received: from ns.Novell.COM by cray.com (Bob mailer 1.2)
id AA26087; Thu, 28 Apr 94 10:45:34 CDT
Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1)
id AA04820; Thu, 28 Apr 94 09:50:47 MDT
Received: from by WC.Novell.COM (4.1/SMI-4.1)
id AB14056; Thu, 28 Apr 94 08:44:16 PDT
Date: Thu, 28 Apr 94 08:44:16 PDT
Message-Id: <9404281544.AB14056 at WC.Novell.COM>
X-Sender: minshall at optics.wc.novell.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: David Borman <dab at berserkly.cray.com>, sparker at damrak.eng.sun.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Greg Minshall <Greg_Minshall at novell.com>
Subject: Re: Question about linemode implementation...
Cc: telnet-ietf at cray.com
Content-Length: 2154
Dave and Steve,
>> If the application allows echo, then it seems perfectly fine if telnet
>> negotiates echo back and forth between local and remote. It doesn't
>> seem fine to me if the client can re-arrange virtual terminal behavior
>> my application has specified. It also doesn't seem right to me that
>> the application should see the "echo bit" off, just because echoing
>> is being done by the telnet client.
>Oh my. By these statements it now becomes clear to me that you do
>not have a clear understanding of how linemode works, and what
>support is needed in the terminal driver on the server to allow
>linemode to work.
Interesting.
Actually, Dave wrote the thing and wrote the code and, etc., but i think i
actually agree with Steve's point of view.
If the application wants to be running in some mode "linemode" supports
(mostly, standard shell prompt mode), then linemode should be "operative".
But, as soon as the application wants to do something funny (like, run vi,
say), then the application will put the pty in something like "raw" mode,
and *that* should cause the telnet server to say "drop out of linemode for
a bit" to the client (until the application says "go back into "normal"
mode).
That's my base view of how linemode should be operating. It protects the
server side from traffic generated during "normal" TTY operations, but not
during "raw" TTY operations.
Then, Steve's point (to me) is that NO MATTER WHAT THE CLIENT says
(prompted by the user into saying it, or by some other trigger), linemode
should *NOT* be made operative by the server if the pty is in *RAW* mode
(set there by the application).
Dave, clearly you think i'm wrong. But, *i* think i'm write :). What say you?
> 2) The application on the master pty side has to be
> notified whenever the state of the pty changes, so
> that it can negotiate the appropriate new state with
> the client.
Now, i'm not a pty expert, so i can't tell if "the application on the
master pty side" is a) telnetd, or b) vi/csh/whatever. Maybe my confusion
is here (since i'm assuming you meant b, but *i* want a).
Greg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13895;
28 Apr 94 12:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13885;
28 Apr 94 12:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09302;
28 Apr 94 12:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13866;
28 Apr 94 12:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13809;
28 Apr 94 12:39 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa09235;
28 Apr 94 12:39 EDT
Received: from ames.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-14)
id <AA16003>; Thu, 28 Apr 1994 09:39:11 -0700
Received: from wdl1.wdl.loral.com by ames.arc.nasa.gov with SMTP id AA29286
(5.65c/IDA-1.4.4 for <info-ietf at ames.arc.nasa.gov>); Thu, 28 Apr 1994 06:17:32 -0700
Received: by wdl1.wdl.loral.com (5.65a/WDL-4.0)
id AA19933; Thu, 28 Apr 94 09:39:02 -0700
Date: Thu, 28 Apr 94 09:39:02 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: news at wdl.loral.com
Message-Id: <9404281639.AA19933 at wdl1.wdl.loral.com>
To: info-ietf at ames.arc.nasa.gov
Newsgroups: info.ietf
Path: irm124.wdl.loral.com!user
From: wrl at wdl.loral.com (Bill Lewandowski)
Subject: Re: Internet connectivity in the Costa Rican jungle?
Message-ID: <wrl-280494092110 at irm124.wdl.loral.com>
Followup-To: info.ietf
Sender: news at wdl.loral.com
Organization: Loral Western Development Labs
References: <9404280323.AA07097 at stemwinder.fcr.com>
Date: Thu, 28 Apr 1994 16:21:10 GMT
In article <9404280323.AA07097 at stemwinder.fcr.com>, brad at fcr.com (Brad
Parker) wrote:
>
> Does anyone have any experience with VSAT? We can skip over
> the know problems with satellites (half-duplex + very long turn around
> delays). I'm just curious if this is a solution at all i.e. can one
> buy a small aperture dish + box and pump IP though it on a research
> budget.
>
You can buy a VSAT with two 56Kbps channels for approx $25K. Hughes and
others
have the terminals or can tell you where to get them. I researched this
last
year for a project. We were going to hook-up some Cisco routers via
a VSAT link. We were going to have van that traveled all over North America
and since it moved a lot, dedicated 128Kbps was not practical. Project
got canceled but I had lots of data.
ATT told me they would lease a full-time 56Kbs non-vsat circuit to me for
$3K a month. I'm don't think that applies to Central America though
(See next set of comments below).
> Does that "satellite cell-phone in a brief case" I saw in the
> Steven Segall movie really exist? (the one where the ship's cook
> saves the world from nuclear winter) Can I run a modem through it?
> (even at 1200 baud this would be a win). I'm only half joking here -
> I seem to recall seeing something like it on the open market. (ok,
> maybe it's a bit Dick Tracey but I had to ask).
>
Oh yeah, the Magnavox MagnaPhone does work and is available. I don't
have any costing but would guess its about $15K-$25K. The problem here
is that it uses satellite service from INTELSAT or INMARSAT which have
very very high usage rates. I should note, this should also apply to VSAT
to Central America.
I think you will find out you can afford to ground station but you can
not afford the air-time charges for dial-up or fixed bandwidth full-time.
How I started was I began to read all networking magazines and rag sheets.
P.S. There will be VSAT vendors at InterOP next week. Last year there were
about 6 at the show and I got most of my information there.
--
Bill Lewandowski Systems Planning & Telecommunications
Systems Engineer Loral Western Development Labs
V:(408) 473-4362 wrl at wdl.loral.com
F:(408) 473-4440 CIS:72407,3552
/pn=lewandowski, bill/u=msmac/o=lwdl/p=loral/a=attmail/c=us/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18737;
28 Apr 94 15:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18733;
28 Apr 94 15:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14133;
28 Apr 94 15:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18722;
28 Apr 94 15:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18718;
28 Apr 94 15:59 EDT
Received: from itd.nrl.navy.mil by CNRI.Reston.VA.US id aa14128;
28 Apr 94 15:59 EDT
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA24111; Thu, 28 Apr 94 15:59:03 EDT
Date: Thu, 28 Apr 94 15:59:03 EDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Allison Mankin <mankin at itd.nrl.navy.mil>
Message-Id: <9404281959.AA24111 at itd.nrl.navy.mil>
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US
Subject: IPng Addendum
Whoops, the IPng Area Directors forgot to mention one important
item, which is that we are still on track to present our
recommendation on IPng at the Toronto IETF at the end of July.
Also, note that our presentation from the Houston IETF Monday
plenary is available by ftp and gopher from hsdndev.harvard.edu in
pub/ipng/ietf.3.94.
Allison and Scott
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19768;
28 Apr 94 16:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19763;
28 Apr 94 16:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15457;
28 Apr 94 16:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19733;
28 Apr 94 16:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19723;
28 Apr 94 16:44 EDT
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa15450;
28 Apr 94 16:44 EDT
Received: by CSLI.Stanford.EDU (4.1/25-CSLI-eef) id AA04993; Thu, 28 Apr 94 13:43:29 PDT
Date: Thu, 28 Apr 94 13:43:27 PDT
X-Orig-Sender:iesg-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: Allison Mankin <mankin at itd.nrl.navy.mil>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US
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: Re: IPng Addendum
In-Reply-To: Your message of Thu, 28 Apr 94 15:59:03 EDT
Message-Id: <CMM.0.90.4.767565807.ole at Csli.Stanford.EDU>
Let me also mention that the May 1994 issue of ConneXions is a special
56 page edition devoted entirely to IPng. It contains description of
all three IPng candidates, analysis of the problem, description of the
selection process, etc.
You may request a sample copy of this issue by sending me a simple
message with your POSTAL address.
Thanks,
Ole
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 aa13830;
29 Apr 94 11:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13824;
29 Apr 94 11:12 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa09193; 29 Apr 94 11:11 EDT
Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
id AA20515; Fri, 29 Apr 94 08:11:04 PDT
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA24647; Fri, 29 Apr 94 08:10:10 PDT
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA05305; Fri, 29 Apr 94 08:11:26 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
id AA05299; Fri, 29 Apr 94 08:11:24 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA02759; Fri, 29 Apr 94 08:09:49 PDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM)
id AA20425; Fri, 29 Apr 94 08:10:39 PDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13718;
29 Apr 94 11:07 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
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sipp-bsd-api-02.txt
Date: Fri, 29 Apr 94 11:07:55 -0400
Message-Id: <9404291107.aa13718 at IETF.CNRI.Reston.VA.US>
X-Orig-Sender: sipp-request 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 : SIPP Program Interfaces for BSD Systems
Author(s) : R. Gilligan, R. Govindan, S. Thomson, J. Bound
Filename : draft-ietf-sipp-bsd-api-02.txt
Pages : 12
Date : 04/28/1994
In order to implement the Simple Internet Protocol (SIPP) in an operating
system based on 4.x BSD, changes must be made to some of the application
program interfaces (APIs). TCP/IP applications written for BSD-based
operating systems have in the past enjoyed a high degree of portability
because most of the systems derived from BSD provide the same API, known
informally as "the socket interface". We would like the same portability
to be possible with SIPP applications. This memo presents a set of changes
to the BSD socket API to support SIPP. The changes include a new data
structure to carry SIPP address sequences, new name to address translation
library functions, new address conversion functions, and some new
setsockopt() options. The changes are designed to be minimal and to provide
source and binary compatibility for existing applications.
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-bsd-api-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-sipp-bsd-api-02.txt".
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: <19940428102702.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-sipp-bsd-api-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sipp-bsd-api-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940428102702.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14600;
29 Apr 94 11:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10128;
29 Apr 94 11:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14558;
29 Apr 94 11:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13693;
29 Apr 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-rare-msg-c-bombs-01.txt
Date: Fri, 29 Apr 94 11:06:48 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404291106.aa13693 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 and Messaging Working
Group of RARE.
Title : Bombs series: Behaviour of Mail Based Servers
Part 1: C-bombs
Classification of Breeds of Mail Based Servers
Author(s) : J. Houttuin
Filename : draft-rare-msg-c-bombs-01.txt
Pages : 12
Date : 04/28/1994
This document defines a classification of Mail Based Servers (MBSs)
according to their behaviour towards their users. The most important
distinction is between mail responders (e.g. echo servers, file servers)
and mail forwarders (e.g. mailing lists, auto-forwarders). The document
aims at a common understanding of these MBS classes and other common MBS
attributes, such as roles (administrators, owners), MBS lifetime and
restricted MBS use.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rare-msg-c-bombs-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-rare-msg-c-bombs-01.txt".
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: <19940428115046.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-rare-msg-c-bombs-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rare-msg-c-bombs-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940428115046.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15797;
29 Apr 94 12:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11391;
29 Apr 94 12:57 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15777;
29 Apr 94 12:57 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15670;
29 Apr 94 12:54 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-rare-msg-a-bombs-00.txt
Date: Fri, 29 Apr 94 12:54:35 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9404291254.aa15670 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 and Messaging Working
Group of RARE.
Title : Bombs series: Behaviour of Mail Based Servers
Part 2: A-bombs
Answering servers
Author(s) : J. Houttuin
Filename : draft-rare-msg-a-bombs-00.txt
Pages : 19
Date : 04/28/1994
This document defines rules for the behaviour of Mail Based Echo Servers
and Vacation Servers in the Internet. It is highly desirable that other
e-mail networks connected to the Internet also implement these rules.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rare-msg-a-bombs-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-rare-msg-a-bombs-00.txt".
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: <19940428114945.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-rare-msg-a-bombs-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rare-msg-a-bombs-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940428114945.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19651;
29 Apr 94 14:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19641;
29 Apr 94 14:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14507;
29 Apr 94 14:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19630;
29 Apr 94 14:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19442;
29 Apr 94 14:45 EDT
Received: from relay2.UU.NET by CNRI.Reston.VA.US id aa14415;
29 Apr 94 14:45 EDT
Received: from uucp1.uu.net by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AAwntj25650; Fri, 29 Apr 94 14:45:11 -0400
Received: from clrcom.UUCP by uucp1.uu.net with UUCP/RMAIL
; Fri, 29 Apr 1994 14:45:12 -0400
Received: from hobbes.clearcom (timehost) by Com. (4.1/SMI-4.0)
id AA19151; Fri, 29 Apr 94 13:21:18 CDT
Received: from kirk.Com. by hobbes.clearcom (4.1/SMI-4.1)
id AA20873; Fri, 29 Apr 94 13:21:18 CDT
Date: Fri, 29 Apr 94 13:21:18 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kurt Hall <clrcom!hobbes!khall at uunet.uu.net>
Message-Id: <9404291821.AA20873 at hobbes.clearcom>
To: uunet!fcr.com!brad at uunet.uu.net
Subject: Re: Internet connectivity in the Costa Rican jungle?
Cc: ietf at CNRI.Reston.VA.US
I passed your email on to a friend of mine that does exactly the type
of thing that you're trying to accomplish. I'm forwarding his reply
to you. If you want to respond via email to him, explicitly use his
reply address since he's not on the ietf list.
-kurt
----- Begin Included Message -----
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.
