--- /dev/null
+# File generated by xf86config.
+
+#
+# Copyright (c) 1994 by The XFree86 Project, Inc.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+#
+# Except as contained in this notice, the name of the XFree86 Project shall
+# not be used in advertising or otherwise to promote the sale, use or other
+# dealings in this Software without prior written authorization from the
+# XFree86 Project.
+#
+
+# **********************************************************************
+# Refer to the XF86Config(4/5) man page for details about the format of
+# this file.
+# **********************************************************************
+
+# **********************************************************************
+# Files section. This allows default font and rgb paths to be set
+# **********************************************************************
+
+Section "Files"
+
+# The location of the RGB database. Note, this is the name of the
+# file minus the extension (like ".txt" or ".db"). There is normally
+# no need to change the default.
+
+ RgbPath "/usr/X11R6/lib/X11/rgb"
+
+# Multiple FontPath entries are allowed (which are concatenated together),
+# as well as specifying multiple comma-separated entries in one FontPath
+# command (or a combination of both methods)
+#
+# If you don't have a floating point coprocessor and emacs, Mosaic or other
+# programs take long to start up, try moving the Type1 and Speedo directory
+# to the end of this list (or comment them out).
+#
+
+ FontPath "/usr/X11R6/lib/X11/fonts/misc/"
+ FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
+ FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"
+ FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
+ FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
+
+EndSection
+
+# **********************************************************************
+# Server flags section.
+# **********************************************************************
+
+Section "ServerFlags"
+
+# Uncomment this to cause a core dump at the spot where a signal is
+# received. This may leave the console in an unusable state, but may
+# provide a better stack trace in the core dump to aid in debugging
+
+# NoTrapSignals
+
+# Uncomment this to disable the <Crtl><Alt><BS> server abort sequence
+# This allows clients to receive this key event.
+
+# DontZap
+
+# Uncomment this to disable the <Crtl><Alt><KP_+>/<KP_-> mode switching
+# sequences. This allows clients to receive these key events.
+
+# DontZoom
+
+EndSection
+
+# **********************************************************************
+# Input devices
+# **********************************************************************
+
+# **********************************************************************
+# Keyboard section
+# **********************************************************************
+
+Section "Keyboard"
+
+ Protocol "Standard"
+
+# when using XQUEUE, comment out the above line, and uncomment the
+# following line
+
+# Protocol "Xqueue"
+
+ AutoRepeat 500 5
+# Let the server do the NumLock processing. This should only be required
+# when using pre-R6 clients
+# ServerNumLock
+
+# Specifiy which keyboard LEDs can be user-controlled (eg, with xset(1))
+# Xleds 1 2 3
+
+# To set the LeftAlt to Meta, RightAlt key to ModeShift,
+# RightCtl key to Compose, and ScrollLock key to ModeLock:
+
+ LeftAlt Meta
+# RightAlt ModeShift
+ LeftAlt Meta
+# RightCtl Compose
+# ScrollLock ModeLock
+
+EndSection
+
+
+# **********************************************************************
+# Pointer section
+# **********************************************************************
+
+Section "Pointer"
+ Protocol "PS/2"
+ Device "/dev/mouse"
+# eller Device "/dev/psmouse"
+
+# When using XQUEUE, comment out the above two lines, and uncomment
+# the following line.
+
+# Protocol "Xqueue"
+
+# Baudrate and SampleRate are only for some Logitech mice
+
+# BaudRate 9600
+# SampleRate 150
+
+# Emulate3Buttons is an option for 2-button Microsoft mice
+# Emulate3Timeout is the timeout in milliseconds (default is 50ms)
+
+ Emulate3Buttons
+ Emulate3Timeout 50
+
+# ChordMiddle is an option for some 3-button Logitech mice
+
+# ChordMiddle
+
+EndSection
+
+
+# **********************************************************************
+# Monitor section
+# **********************************************************************
+
+# Any number of monitor sections may be present
+
+Section "Monitor"
+
+ Identifier "My Monitor"
+ VendorName "HP"
+ ModelName "OmniBook 4000C"
+
+# HorizSync is in kHz unless units are specified.
+# HorizSync may be a comma separated list of discrete values, or a
+# comma separated list of ranges of values.
+# NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S
+# USER MANUAL FOR THE CORRECT NUMBERS.
+
+# HorizSync 31.47
+ HorizSync 30-64
+# HorizSync 30-64 # multisync
+# HorizSync 31.5, 35.2 # multiple fixed sync frequencies
+# HorizSync 15-25, 30-50 # multiple ranges of sync frequencies
+
+# VertRefresh is in Hz unless units are specified.
+# VertRefresh may be a comma separated list of discrete values, or a
+# comma separated list of ranges of values.
+# NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S
+# USER MANUAL FOR THE CORRECT NUMBERS.
+
+# VertRefresh 59.94
+ VertRefresh 50-100
+
+# Modes can be specified in two formats. A compact one-line format, or
+# a multi-line format.
+
+# These two are equivalent
+
+# ModeLine "1024x768i" 45 1024 1048 1208 1264 768 776 784 817 Interlace
+
+# Mode "1024x768i"
+# DotClock 45
+# HTimings 1024 1048 1208 1264
+# VTimings 768 776 784 817
+# Flags "Interlace"
+# EndMode
+
+# This is a set of standard mode timings. Modes that are out of monitor spec
+# are automatically deleted by the server (provided the HorizSync and
+# VertRefresh lines are correct), so there's no immediate need to
+# delete mode timings (unless particular mode timings don't work on your
+# monitor). With these modes, the best standard mode that your monitor
+# and video card can support for a given resolution is automatically
+# used.
+
+# 640x480 @ 60 Hz, 31.5 kHz hsync
+Mode "640x480"
+ DotClock 25.175
+ HTimings 640 664 760 800
+ VTimings 480 491 493 525
+EndMode
+
+# 640x400 @ 70 Hz, 31.5 kHz hsync
+Modeline "640x400" 25.175 640 664 760 800 400 409 411 450
+
+# 640x480, 31.5 hsync
+Modeline "640x480" 28.32 640 680 720 864 480 488 491 521
+
+# 800x600 @ 56 Hz, 35.15 kHz hsync
+Modeline "800x600.36" 36 800 824 896 1024 600 601 603 625
+
+# 800x600 @ 72Hz Non interlace mode
+Mode "800x600.50"
+ DotClock 50
+ HTimings 800 856 896 1040
+ VTimings 600 637 643 666
+ Flags "+HSync" "+VSync"
+EndMode
+
+# 1024x768 @ 87 Hz interlaced, 35.5 kHz hsync
+Modeline "1024x768" 44.9 1024 1048 1208 1264 768 776 784 817 Interlace
+
+# 640x480 @ 72 Hz, 36.5 kHz hsync
+Modeline "640x480" 31.5 640 680 720 864 480 488 491 521
+# 800x600 @ 60 Hz, 37.8 kHz hsync
+Modeline "800x600" 40 800 840 968 1056 600 601 605 628 +hsync
++vsync
+
+# 800x600 @ 72 Hz, 48.0 kHz hsync
+Modeline "800x600" 50 800 856 976 1040 600 637 643 666 +hsync
++vsync
+# 1024x768 @ 60 Hz, 48.4 kHz hsync
+Modeline "1024x768" 65 1024 1032 1176 1344 768 771 777 806 -hsync
+-vsync
+
+# 1024x768 @ 70 Hz, 56.5 kHz hsync
+Modeline "1024x768" 75 1024 1048 1184 1328 768 771 777 806 -hsync
+-vsync
+# 1280x1024 @ 87 Hz interlaced, 51 kHz hsync
+Modeline "1280x1024" 80 1280 1296 1512 1568 1024 1025 1037 1165 Interlace
+
+# 1024x768 @ 76 Hz, 62.5 kHz hsync
+Modeline "1024x768" 85 1024 1032 1152 1360 768 784 787 823
+# 1280x1024 @ 61 Hz, 64.2 kHz hsync
+Modeline "1280x1024" 110 1280 1328 1512 1712 1024 1025 1028 1054
+
+# 1280x1024 @ 74 Hz, 78.85 kHz hsync
+Modeline "1280x1024" 135 1280 1312 1456 1712 1024 1027 1030 1064
+
+# 1280x1024 @ 76 Hz, 81.13 kHz hsync
+Modeline "1280x1024" 135 1280 1312 1416 1664 1024 1027 1030 1064
+
+# Low-res Doublescan modes
+# If your chipset does not support doublescan, you get a 'squashed'
+# resolution like 320x400.
+
+# 320x200 @ 70 Hz, 31.5 kHz hsync, 8:5 aspect ratio
+Modeline "320x200" 12.588 320 336 384 400 200 204 205 225
+Doublescan
+# 320x240 @ 60 Hz, 31.5 kHz hsync, 4:3 aspect ratio
+Modeline "320x240" 12.588 320 336 384 400 240 245 246 262
+Doublescan
+# 320x240 @ 72 Hz, 36.5 kHz hsync
+Modeline "320x240" 15.750 320 336 384 400 240 244 246 262
+Doublescan
+# 400x300 @ 56 Hz, 35.2 kHz hsync, 4:3 aspect ratio
+ModeLine "400x300" 18 400 416 448 512 300 301 602 312
+Doublescan
+# 400x300 @ 60 Hz, 37.8 kHz hsync
+Modeline "400x300" 20 400 416 480 528 300 301 303 314
+Doublescan
+# 400x300 @ 72 Hz, 48.0 kHz hsync
+Modeline "400x300" 25 400 424 488 520 300 319 322 333
+Doublescan
+# 480x300 @ 56 Hz, 35.2 kHz hsync, 8:5 aspect ratio
+ModeLine "480x300" 21.656 480 496 536 616 300 301 302 312
+Doublescan
+# 480x300 @ 60 Hz, 37.8 kHz hsync
+Modeline "480x300" 23.890 480 496 576 632 300 301 303 314
+Doublescan
+# 480x300 @ 63 Hz, 39.6 kHz hsync
+Modeline "480x300" 25 480 496 576 632 300 301 303 314
+Doublescan
+# 480x300 @ 72 Hz, 48.0 kHz hsync
+Modeline "480x300" 29.952 480 504 584 624 300 319 322 333
+Doublescan
+
+EndSection
+
+
+# **********************************************************************
+# Graphics device section
+# **********************************************************************
+
+# Any number of graphics device sections may be present
+
+# Standard VGA Device:
+
+Section "Device"
+ Identifier "Generic VGA"
+ VendorName "Unknown"
+ BoardName "Unknown"
+ Chipset "generic"
+
+ VideoRam 256
+
+ Clocks 25.2 28.3
+
+EndSection
+
+# Sample Device for accelerated server:
+
+# Section "Device"
+# Identifier "Actix GE32+ 2MB"
+# VendorName "Actix"
+# BoardName "GE32+"
+# Ramdac "ATT20C490"
+# Dacspeed 110
+# Option "dac_8_bit"
+# Clocks 25.0 28.0 40.0 0.0 50.0 77.0 36.0 45.0
+# Clocks 130.0 120.0 80.0 31.0 110.0 65.0 75.0 94.0
+# EndSection
+
+# Device configured by xf86config:
+
+Section "Device"
+ Identifier "WD 90C24A or 90C24A2 (laptop)"
+ VendorName "Western Digital"
+ BoardName "RocketChip"
+# VideoRam 512
+# Chipset "wd90c24"
+ Option "med_dram" # Set Mclk to 49.219
+
+ Clocks 25.175 28.322 65 36 # These are not programmable
+ Clocks 29.979 77.408 62.195 59.957 # These are programmable
+ Clocks 31.5 35.501 75.166 50.114 # These are not programmable
+ Clocks 39.822 72.038 44.744 65.1 # These are programmable
+ Clocks 49.219 # Must match Mclk
+ # Insert Clocks lines here if appropriate
+EndSection
+
+
+# **********************************************************************
+# Screen sections
+# **********************************************************************
+
+# The Colour SVGA server
+
+Section "Screen"
+ Driver "svga"
+ Device "WD 90C24A or 90C24A2 (laptop)"
+ Monitor "My Monitor"
+ Subsection "Display"
+ Depth 8
+ #Modes "640x480" "800x600.36" "1024x768i"
+ Modes "640x480"
+ ViewPort 0 0
+ #Virtual 800 600
+ Virtual 0 0
+ EndSubsection
+EndSection
+
+# The 16-color VGA server
+
+Section "Screen"
+ Driver "vga16"
+ Device "Generic VGA"
+ Monitor "My Monitor"
+ Subsection "Display"
+ Modes "640x480" "800x600"
+ ViewPort 0 0
+ Virtual 800 600
+ EndSubsection
+EndSection
+
+# The Mono server
+
+Section "Screen"
+ Driver "vga2"
+ Device "Generic VGA"
+ Monitor "My Monitor"
+ Subsection "Display"
+ Modes "640x480" "800x600"
+ ViewPort 0 0
+ Virtual 800 600
+ EndSubsection
+EndSection
--- /dev/null
+<HTML>
+<HEAD>
+<META HTTP-EQUIV=REFRESH CONTENT="0; URL=http://www.quiknet.com/~abond/4000c/hptop.html">
+<TITLE>Redirect to new maintainter</TITLE>
+<!-- Changed by: Petter Reinholdtsen, 18-Oct-1996 -->
+<LINK REV="made" HREF="mailto:pere@td.org.uit.no">
+</HEAD>
+<BODY>
+<H1>Redirect to new maintainter</H1>
+
+As of 1996-10-18, this page got a new maintainer, Aaron Bond
+<abond@mail2.quiknet.com>. Take the jump to the
+<A HREF="http://www.quiknet.com/~abond/4000c/hptop.html">new site</a>.
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>HP Omnibook 4000C - Linux page</TITLE>
+<!-- Changed by: Petter Reinholdtsen, 14-Sep-1996 -->
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+
+<HR>
+
+This page is no longer maintained by me, as I don't have access to my
+old laptop. I would therefore like to transfer this page to anyone
+who is interested in maintaining it. Mail me at
+<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A> if you are
+interested.
+
+<HR>
+
+<H1>HP Omnibook 4000C - Linux page</H1>
+
+I created this page after searching the web for information about the
+HP Omnibook 4000C. I did not find anything, so I created my own.
+This is most of the information I found useful to configure my HP
+Omnibook 4000C for Linux.
+
+<P>4000C contains an 16bit sound-card and an infrared sender/receiver.
+The IR-device is <CODE>/dev/{ttyS1,cua1}</CODE>. The tracking ball
+has an PS/2 busmouse interface.
+
+<UL>
+<LI><A HREF="#kernel">Kernel configuration</A>
+<LI><A HREF="#xfree86">XFree86 configuration</A>
+<LI><A HREF="#screen">My screen is screwed up</A>
+<LI><A HREF="#pcmcia">Problems with PCMCIA</A>
+<LI><A HREF="#info">More information</A>
+</UL>
+
+<A NAME="kernel"><H2>Kernel configuration</H2></A>
+
+All this is tried on Linux kernel v.1.3.59.
+
+<P>The option <CODE>Pocket and portable adaptors</CODE> is not needed to
+use PCMCIA cards.
+
+<H3>Advanced Power Management configuration</H3>
+
+<DL>
+<DT><CODE>Ignore USER SUSPEND</CODE>: <B>N</B>
+<DT><CODE>Enable PM at boot time</CODE>: <B>N</B>
+<DD>This seems to be important to get a stable system.
+<DT><CODE>Make CPU Idle calls when idle</CODE>: <B>Y</B>
+<DT><CODE>Enable console blanking using APM</CODE>: <B>N</B>
+<DD>Console blanking was not supported on linux 1.3.75
+</DL>
+
+<H3>Sound configuration</H3>
+
+Windows gives me the following information about the sound facilities:
+<PRE>
+ESS AudioDrive ES688
+ I/O port 220
+ IRQ 7
+ DMA 1 size 32
+ESS AudioDrive MIDI
+</PRE>
+
+Brian Vinter reported IRQ 5 from Windows 95. This is normal, as the
+IRQ and DMA can be changed in the bios setup.
+
+<P>It seems to be compatible with Soundblaster Pro. With a simple
+<A HREF="soundconf">configuration file</A> I managed to get stereo
+sound. Copy this to <CODE>/etc/soundconf</CODE> and run <CODE>make config</CODE> in <CODE>/usr/src/linux/drivers/sound/</CODE>.
+
+<A NAME="xfree86"><H2>XFree86 configuration</H2></A>
+
+The 4000c seems to be using the Western Digital 90C24A chipset. This
+is supported by the XF86_SVGA server. It has 512k videoram. I have a
+<A HREF="XF86Config">sample <CODE>XF86Config</CODE></A> which gives
+you resolution 640x480. Copy this file to
+<CODE>/etc/XF86Config</CODE> or <CODE>/etc/X11/XF86Config</CODE>.
+
+
+<A NAME="screen"><H2>My screen is screwed up</H2></A>
+
+Sometime, after leaving X, the screen gets completely screwed up.
+This is due to a bug in the chipset. To restore the screen, press
+<KBD>fn F5</KBD>.
+
+<A NAME="pcmcia"><H2>Problems with PCMCIA</H2></A>
+
+Dag Brattli has experimented with two different Ethernet-cards and
+discovered many problems.
+
+<P>"3Com 3c589C Etherlink III worked with pcmcia-cs-2.7.6 but not with
+pcmcia-cs-2.8.6 and 2.8.7. 'if_port=3' must be present in
+<CODE>/etc/pcmcia/config</CODE>, or
+<CODE>/etc/pcmcia/config.opts</CODE> to get the card to work at
+all. 'exclude 0x300-0x30f' in the same file seems to avoid some strange
+conflict.
+
+<P>IBM CCA Ethernet II works with all the pcmcia-cs versions tried.
+This card needs 'mem_speed=600' in <CODE>/etc/pcmcia/config</CODE> or
+<CODE>/etc/pcmcia/config.opts</CODE> if it exists. This improves
+transfer speed and prevents filling <CODE>/usr/adm/messages</CODE>
+with UDP error messages."
+
+<A NAME="info"><H2>More information</H2></A>
+<UL>
+<LI><A HREF="http://www.cs.utexas.edu/users/kharker/linux-laptop/">The
+Linux Laptop Home Page</A>
+<LI><A HREF="http://hyper.stanford.edu/~dhinds/pcmcia/pcmcia.html">Linux
+PCMCIA Information Page</a>
+<LI><A HREF="http://www.cs.utexas.edu/users/kharker/linux-laptop/apm.html">Linux
+and Advanced Power Management</A>
+</UL>
+
+
+<A NAME="acknow"><H2>Acknowledgments</H2></A>
+
+Thanks to Dag Brattli <dagb@stud.cs.uit.no> for the
+XF86Config-file and lots of other info. Thanks to Brian Vinter
+<vinter@cs.uit.no> for some informations on the screen.
+
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+/* Generated by configure. Don't edit!!!! */
+/* Making changes to this file is not as simple as it may look. */
+
+/* If you change the CONFIG_ settings in local.h you */
+/* _have_ to edit .defines too. */
+
+#undef CONFIG_PAS
+#define CONFIG_SB
+#undef CONFIG_ADLIB
+#undef CONFIG_GUS
+#undef CONFIG_MPU401
+#undef CONFIG_UART6850
+#undef CONFIG_PSS
+#undef CONFIG_GUS16
+#undef CONFIG_GUSMAX
+#undef CONFIG_MSS
+#undef CONFIG_SSCAPE
+#undef CONFIG_TRIX
+#undef CONFIG_MAD16
+#undef CONFIG_CS4232
+#undef CONFIG_MAUI
+#undef CONFIG_PNP
+#define CONFIG_SBPRO
+#undef CONFIG_SB16
+#undef CONFIG_AEDSP16
+#define CONFIG_AUDIO
+#define CONFIG_MIDI
+#define CONFIG_YM3812
+#define CONFIG_SEQUENCER
+
+#undef CONFIG_MPU_EMU
+#undef CONFIG_AD1848
+
+#define SBC_BASE 0x220
+#define SBC_IRQ 7
+#define SBC_DMA 1
+#define DSP_BUFFSIZE 32768
+#define SELECTED_SOUND_OPTIONS 0x01a90002
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Møter i Studenthuset AS</TITLE>
+</HEAD>
+<BODY>
+
+<UL>
+<LI> 930626 Generalforsamling
+<HR>
+<LI> 940126 Styremøte 01.94 sak 01-03/94
+<LI> 940325 Styremøte 02.94 sak 04-07/94
+<LI> 940426 Styremøte 03.94 sak 08-11/94
+<LI> 940511 Styremøte 04.94 sak 12-14/94
+<LI> 940603 Styremøte 05.94 sak 15-17/94
+<LI> 940901 Styremøte 06.94 sak 18-22/94
+<LI> 940922 Ekstraordinært styremøte 07.94 sak 23/94
+<LI> 940925 Styremøte 08.94 sak 24-26/94
+<LI> 941007 Styremøte 09.94 sak 27-31/94
+<LI> 941014 Styremøte 10.94 sak 32-34/94
+<LI> 941020 Styremøte 11.94 sak 35-37/94
+</UL>
+
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+ <HEAD>
+ <TITLE> A Simple Program </TITLE>
+ </HEAD>
+ <BODY>
+
+ Here is the output of my program:
+ <APPLET CODE="HelloWorld.class" WIDTH=150 HEIGHT=25>
+ </APPLET>
+ </BODY>
+ </HTML>
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Sendmail statistics</TITLE>
+</HEAD>
+<BODY bgcolor=#ffffff>
+
+<TABLE BORDER=0 CELLSPACING=0 CELLPADING=0 WIDTH=100%>
+ <TR><TD><A HREF="http://www.ethz.ch">
+ <IMG border=0 alt="ETH: " WIDTH=199 HEIGHT=32 SRC="/eth.199x32.gif" ></A>
+ </TD>
+ <TD ALIGN=RIGHT>
+ <A HREF="http://www.ethz.ch/">
+ Swiss Federal Institute of Technology Zurich</A><BR>
+ <A HREF="http://www.ee.ethz.ch/">
+ Department of Electrical Engineering</A><BR>
+ </TD>
+ </TR>
+</TABLE>
+
+<H1>Sendmail statistics</H1>
+<P><B><A HREF="mq.html">terror.hungry.com Sendmail MailQueue Statistics</B><P>
+ <SMALL><!--#flastmod file="mq.html" --></SMALL></P>
+ <IMG WIDTH=600 HEIGHT=163 SRC="mq-day.gif"></A>
+ <HR>
+<P><B><A HREF="mail.html">terror.hungry.com Sendmail send/receive Statistics</B><P>
+ <SMALL><!--#flastmod file="mail.html" --></SMALL></P>
+ <IMG WIDTH=600 HEIGHT=163 SRC="mail-day.gif"></A>
+ <HR>
+<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
+ <TR>
+ <TD WIDTH=63><A ALT="MRTG"
+ HREF="http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-l.gif"></A></TD>
+ <TD WIDTH=25><A ALT=""
+ HREF="http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-m.gif"></A></TD>
+ <TD WIDTH=388><A ALT=""
+ HREF="http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-r.gif"></A></TD>
+ </TR>
+</TABLE>
+<SPACER TYPE=VERTICAL SIZE=4>
+<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
+ <TR VALIGN=top>
+ <TD WIDTH=88 ALIGN=RIGHT><FONT FACE="Arial,Helvetica" SIZE=2>
+ 2.0-1997/01/26</FONT></TD>
+ <TD WIDTH=388 ALIGN=RIGHT><FONT FACE="Arial,Helvetica" SIZE=2>
+ <A HREF="http://www.ee.ethz.ch/~oetiker">Tobias Oetiker</A>
+ <A HREF="mailto:oetiker@ee.ethz.ch"><oetiker@ee.ethz.ch></A>
+ and <A HREF="http://www.bungi.com">Dave Rand</A> <A HREF="mailto:dlr@bungi.com"><dlr@bungi.com></A></FONT>
+ </TD>
+</TR>
+</TABLE>
+</BODY></HTML>
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>
+terror.hungry.com Sendmail send/receive Statistics
+</TITLE>
+<META HTTP-EQUIV="Refresh" CONTENT=300 >
+<META HTTP-EQUIV="Expires" CONTENT="Wed, 11 Mar 1998 10:05:23 GMT">
+<!-- maxin d 28 -->
+<!-- maxout d 154 -->
+<!-- avin d 3 -->
+<!-- avout d 16 -->
+<!-- cuin d 0 -->
+<!-- cuout d 0 -->
+<!-- maxin w 41 -->
+<!-- maxout w 164 -->
+<!-- avin w 2 -->
+<!-- avout w 12 -->
+<!-- cuin w 2 -->
+<!-- cuout w 7 -->
+<!-- maxin m 41 -->
+<!-- maxout m 332 -->
+<!-- avin m 2 -->
+<!-- avout m 9 -->
+<!-- cuin m 0 -->
+<!-- cuout m 6 -->
+<!-- maxin y 243 -->
+<!-- maxout y 974 -->
+<!-- avin y 1 -->
+<!-- avout y 8 -->
+<!-- cuin y 1 -->
+<!-- cuout y 13 -->
+
+</HEAD>
+<BODY bgcolor=#000000 text="#ffffff" link="#cfcfcf" alink="#00ff00" vlink="#9f9f9f">
+terror.hungry.com Sendmail Statistics</H1><P>
+<HR>
+The statistics were last updated <B>Wednesday, 11 March 1998 at 2:00 </B>
+,<BR>
+at which time <B>'localhost'</B> had been up for <B>Thu Jan 1 09:00:10 1998</B>.
+
+<HR>
+<B>`Daily' Graph (5 Minute Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mail-day.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+<TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>28.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>3.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>0.0 messages
+ </SMALL></TD>
+ </TR>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>154.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>16.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>0.0 messages
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+<HR>
+<B>`Weekly' Graph (30 Minute Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mail-week.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+<TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>41.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>2.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>2.0 messages
+ </SMALL></TD>
+ </TR>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>164.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>12.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>7.0 messages
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+<HR>
+<B>`Monthly' Graph (2 Hour Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mail-month.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+<TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>41.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>2.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>0.0 messages
+ </SMALL></TD>
+ </TR>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>332.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>9.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>6.0 messages
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+<HR>
+<B>`Yearly' Graph (1 Day Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mail-year.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+<TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>243.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>1.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#00cc00> Incoming:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>1.0 messages
+ </SMALL></TD>
+ </TR>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>974.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>8.0 messages
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Outgoing:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>13.0 messages
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+ <HR><P>
+ <TABLE WIDTH=500 BORDER=0 CELLPADDING=4 CELLSPACING=0>
+ <TR><TD ALIGN=RIGHT><FONT SIZE=-1 COLOR="#00cc00">
+ <B>GREEN ###</B></FONT></TD>
+ <TD><FONT SIZE=-1>Incoming Traffic in Bytes per Second</FONT></TD></TR>
+ <TR><TD ALIGN=RIGHT><FONT SIZE=-1 COLOR="#0000ff">
+ <B>BLUE ###</B></FONT></TD>
+ <TD><FONT SIZE=-1>Outgoing Traffic in Bytes per Second</FONT></TD></TR>
+ <TR><TD ALIGN=RIGHT><FONT SIZE=-1 COLOR="#006600">
+ <B>DARK GREEN###</B></FONT></TD>
+ <TD><FONT SIZE=-1>Maximal 5 Minute Incoming Traffic</FONT></TD></TR>
+ <TR><TD ALIGN=RIGHT><FONT SIZE=-1 COLOR="#ff00ff">
+ <B>MAGENTA###</B></FONT></TD>
+ <TD><FONT SIZE=-1>Maximal 5 Minute Outgoing Traffic</FONT></TD></TR> </TABLE><P><HR><P>
+
+<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
+ <TR>
+ <TD WIDTH=63><A ALT="MRTG"
+ HREF="http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-l.gif"></A></TD>
+ <TD WIDTH=25><A ALT=""
+ HREF="http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-m.gif"></A></TD>
+ <TD WIDTH=388><A ALT=""
+ HREF="http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-r.gif"></A></TD>
+ </TR>
+</TABLE>
+<SPACER TYPE=VERTICAL SIZE=4>
+<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
+ <TR VALIGN=top>
+ <TD WIDTH=88 ALIGN=RIGHT><FONT FACE="Arial,Helvetica" SIZE=2>
+ 2.5.1-1997/10/24</FONT></TD>
+ <TD WIDTH=388 ALIGN=RIGHT><FONT FACE="Arial,Helvetica" SIZE=2>
+ <A HREF="http://ee-staff.ethz.ch/~oetiker/">Tobias Oetiker</A>
+ <A HREF="mailto:oetiker@ee.ethz.ch"><oetiker@ee.ethz.ch></A>
+ and <A HREF="http://www.bungi.com">Dave Rand</A> <A HREF="mailto:dlr@bungi.com"><dlr@bungi.com></A></FONT>
+ </TD>
+</TR>
+</TABLE>
+</BODY>
+</HTML>
--- /dev/null
+889610410 0 0
+889610410 0 0 0 0
+889610108 4 35 4 35
+889610100 4 35 5 40
+889609800 4 38 5 40
+889609500 0 0 1 17
+889609200 1 16 2 17
+889608900 2 14 6 15
+889608600 5 14 6 14
+889608300 3 13 5 14
+889608000 4 10 5 11
+889607700 2 6 3 7
+889607400 0 1 3 2
+889607100 3 1 4 2
+889606800 3 0 4 0
+889606500 3 0 3 8
+889606200 2 8 3 9
+889605900 1 8 2 9
+889605600 1 8 1 17
+889605300 1 16 3 17
+889605000 2 12 3 13
+889604700 2 0 3 3
+889604400 2 2 3 3
+889604100 1 1 2 2
+889603800 0 1 1 2
+889603500 0 0 0 0
+889603200 0 0 0 0
+889602900 0 0 0 0
+889602600 0 0 1 0
+889602300 0 0 1 0
+889602000 0 0 4 1
+889601700 3 1 4 1
+889601400 0 1 1 17
+889601100 0 17 3 21
+889600800 2 20 3 21
+889600500 0 2 1 24
+889600200 0 23 0 24
+889599900 0 0 4 1
+889599600 3 1 4 1
+889599300 2 1 2 19
+889599000 1 18 2 19
+889598700 0 0 0 0
+889598400 0 0 0 0
+889598100 0 0 0 1
+889597800 0 0 0 1
+889597500 0 0 4 18
+889597200 3 17 4 18
+889596900 0 0 5 49
+889596600 4 48 5 49
+889596300 0 0 1 0
+889596000 0 0 1 0
+889595700 0 0 0 0
+889595400 0 0 4 0
+889595100 3 0 4 20
+889594800 2 19 3 20
+889594500 0 0 0 2
+889594200 0 1 0 2
+889593900 0 0 0 0
+889593600 0 0 1 1
+889593300 0 0 1 1
+889593000 0 0 0 0
+889592700 0 0 0 11
+889592400 0 11 1 17
+889592100 0 16 1 17
+889591800 0 0 4 2
+889591500 3 1 4 2
+889591200 0 0 0 0
+889590900 0 0 0 0
+889590600 0 0 0 0
+889590300 0 0 0 0
+889590000 0 0 3 1
+889589700 3 1 4 17
+889589400 3 16 4 17
+889589100 0 0 1 1
+889588800 0 0 0 0
+889588500 0 0 4 0
+889588200 3 0 4 0
+889587900 0 0 1 1
+889587600 1 0 1 1
+889587300 1 0 2 0
+889587000 2 0 8 3
+889586700 7 2 8 3
+889586400 1 1 8 3
+889586100 7 2 8 3
+889585800 5 0 6 0
+889585500 0 0 1 1
+889585200 0 0 1 1
+889584900 0 0 3 0
+889584600 3 0 4 8
+889584300 3 8 4 9
+889584000 1 8 2 9
+889583700 0 0 1 1
+889583400 0 0 2 2
+889583100 2 1 3 2
+889582800 2 1 3 4
+889582500 2 3 4 4
+889582200 3 0 4 1
+889581900 2 0 2 1
+889581600 2 1 4 1
+889581300 3 1 4 8
+889581000 2 8 3 9
+889580700 2 9 6 30
+889580400 5 29 6 30
+889580100 2 1 2 1
+889579800 1 1 2 8
+889579500 0 7 1 8
+889579200 0 0 4 0
+889578900 4 0 7 10
+889578600 6 10 7 27
+889578300 4 26 5 27
+889578000 0 0 1 1
+889577700 1 0 2 1
+889577400 2 0 2 21
+889577100 2 20 5 21
+889576800 5 16 5 17
+889576500 4 8 5 9
+889576200 0 0 0 0
+889575900 0 0 0 0
+889575600 0 0 0 0
+889575300 0 0 5 17
+889575000 5 17 10 23
+889574700 9 22 10 23
+889574400 1 1 4 2
+889574100 4 2 12 2
+889573800 11 1 12 2
+889573500 0 0 0 0
+889573200 0 0 0 0
+889572900 0 0 5 8
+889572600 4 7 5 8
+889572300 1 0 11 2
+889572000 10 1 11 2
+889571700 0 0 5 1
+889571400 5 1 8 16
+889571100 7 15 8 16
+889570800 4 0 4 0
+889570500 3 0 4 20
+889570200 1 19 2 20
+889569900 0 0 0 0
+889569600 0 0 11 60
+889569300 10 59 11 60
+889569000 5 13 8 14
+889568700 7 8 8 14
+889568400 6 13 9 14
+889568100 8 8 9 41
+889567800 5 40 9 41
+889567500 8 2 9 13
+889567200 2 13 5 39
+889566900 4 38 5 39
+889566600 0 0 8 18
+889566300 7 18 8 78
+889566000 5 76 6 78
+889565700 0 0 0 0
+889565400 0 0 4 10
+889565100 4 10 8 38
+889564800 7 37 8 38
+889564500 6 10 7 11
+889564200 0 0 13 8
+889563900 12 7 13 8
+889563600 0 0 10 46
+889563300 9 45 10 46
+889563000 4 18 14 38
+889562700 13 38 14 72
+889562400 8 71 8 72
+889562100 8 28 11 84
+889561800 11 83 11 84
+889561500 10 70 11 71
+889561200 0 0 12 26
+889560900 11 25 12 26
+889560600 0 0 4 39
+889560300 4 38 6 39
+889560000 5 27 6 35
+889559700 4 34 5 35
+889559400 5 17 9 26
+889559100 8 25 9 26
+889558800 0 1 4 50
+889558500 3 49 4 50
+889558200 0 0 6 2
+889557900 5 1 6 2
+889557600 0 0 6 7
+889557300 5 6 6 7
+889557000 0 0 0 0
+889556700 0 0 3 2
+889556400 3 2 9 4
+889556100 8 3 9 4
+889555800 0 0 13 11
+889555500 12 10 13 11
+889555200 6 2 7 9
+889554900 4 8 5 9
+889554600 0 0 0 0
+889554300 0 0 2 1
+889554000 2 1 2 2
+889553700 2 2 4 2
+889553400 3 1 4 2
+889553100 2 1 3 1
+889552800 2 0 2 1
+889552500 1 0 2 0
+889552200 1 0 8 11
+889551900 7 11 8 12
+889551600 2 11 3 12
+889551300 0 0 3 1
+889551000 2 1 3 1
+889550700 2 1 8 2
+889550400 7 2 8 101
+889550100 1 100 2 101
+889549800 1 2 2 3
+889549500 0 0 0 0
+889549200 0 0 3 9
+889548900 3 8 3 9
+889548600 2 6 3 18
+889548300 2 18 2 37
+889548000 2 36 2 37
+889547700 2 0 3 1
+889547400 2 0 3 1
+889547100 0 0 4 8
+889546800 3 8 4 9
+889546500 1 8 2 9
+889546200 0 0 0 0
+889545900 0 0 0 0
+889545600 0 0 0 0
+889545300 0 0 2 12
+889545000 2 12 5 55
+889544700 4 54 5 55
+889544400 2 0 3 0
+889544100 0 0 0 0
+889543800 0 0 9 28
+889543500 8 27 9 28
+889543200 0 0 3 38
+889542900 2 37 3 38
+889542600 0 0 6 8
+889542300 5 7 6 8
+889542000 0 0 0 0
+889541700 0 0 6 5
+889541400 5 4 6 5
+889541100 0 0 3 13
+889540800 2 12 3 13
+889540500 0 0 0 0
+889540200 0 0 0 0
+889539900 0 0 4 14
+889539600 4 13 5 14
+889539300 4 3 5 4
+889539000 3 0 4 0
+889538700 0 0 2 1
+889538400 2 1 2 2
+889538100 2 1 3 2
+889537800 3 0 7 10
+889537500 6 9 7 10
+889537200 0 8 1 9
+889536900 1 1 2 2
+889536600 2 0 2 0
+889536300 1 0 2 0
+889536000 0 0 0 0
+889535700 0 0 0 0
+889535400 0 0 0 0
+889535100 0 0 0 0
+889534800 0 0 0 0
+889534500 0 0 4 0
+889534200 3 0 4 8
+889533900 1 8 1 9
+889533600 0 8 1 9
+889533300 0 0 0 2
+889533000 0 1 1 2
+889532700 0 0 1 2
+889532400 0 1 1 2
+889532100 0 0 1 0
+889531800 0 0 1 0
+889531500 0 0 1 0
+889531200 0 0 1 5
+889530900 1 4 4 5
+889530600 3 0 4 0
+889530300 1 0 5 43
+889530000 4 42 5 43
+889529700 0 6 1 7
+889529400 0 0 0 0
+889529100 0 0 1 34
+889528800 1 33 3 34
+889528500 3 9 4 14
+889528200 4 14 29 33
+889527900 28 32 29 33
+889527600 1 22 2 23
+889527300 0 0 2 0
+889527000 2 0 3 61
+889526700 2 60 3 61
+889526400 0 0 1 0
+889526100 1 0 3 2
+889525800 2 2 3 10
+889525500 1 9 2 10
+889525200 0 0 6 39
+889524900 5 38 6 39
+889524600 0 15 1 16
+889524300 0 0 1 0
+889524000 1 0 3 51
+889523700 2 50 3 51
+889523400 0 31 1 73
+889523100 0 72 1 73
+889522800 0 0 2 26
+889522500 2 25 4 26
+889522200 4 5 4 6
+889521900 4 0 4 1
+889521600 3 1 4 1
+889521300 1 1 2 40
+889521000 0 39 1 40
+889520700 0 0 0 0
+889520400 0 0 2 71
+889520100 2 70 3 71
+889519800 2 11 3 12
+889519500 1 2 1 5
+889519200 1 4 2 5
+889518900 2 1 7 2
+889518600 6 0 7 71
+889518300 2 70 3 71
+889518000 0 7 2 11
+889517700 2 11 6 18
+889517400 5 17 6 18
+889517100 0 0 1 16
+889516800 1 15 1 16
+889516500 1 11 1 42
+889516200 0 41 1 42
+889515900 0 0 4 2
+889515600 3 1 4 2
+889515300 1 0 2 1
+889515000 1 0 2 0
+889514700 2 0 4 1
+889514400 3 1 4 3
+889514100 2 2 2 3
+889513800 2 1 2 1
+889513500 1 0 2 1
+889513200 1 0 4 1
+889512900 3 0 4 1
+889512600 1 0 1 0
+889512300 1 0 3 1
+889512000 3 1 4 11
+889511700 4 10 4 11
+889511400 3 0 4 1
+889511100 1 0 2 18
+889510800 2 17 2 18
+889510500 2 0 3 2
+889510200 2 2 3 10
+889509900 1 9 4 10
+889509600 4 6 4 7
+889509300 4 0 5 1
+889509000 4 0 5 1
+889508700 1 0 3 0
+889508400 2 0 3 0
+889508100 0 0 1 0
+889507800 0 0 0 0
+889507500 0 0 3 0
+889507200 3 0 5 28
+889506900 4 27 5 28
+889506600 2 6 3 7
+889506300 0 0 0 0
+889506000 0 0 1 51
+889505700 1 50 3 51
+889505400 3 27 4 36
+889505100 3 35 4 36
+889504800 2 7 3 15
+889504500 1 15 1 22
+889504200 1 22 1 55
+889503900 0 54 1 55
+889503600 0 0 2 13
+889503300 1 12 2 13
+889503000 0 0 7 0
+889502700 6 0 7 1
+889502400 2 1 5 2
+889502100 4 1 5 2
+889501800 2 0 3 1
+889501500 0 0 2 0
+889501200 2 0 4 0
+889500900 3 0 4 0
+889500600 0 0 3 1
+889500300 3 1 3 2
+889500000 3 1 6 2
+889499700 5 0 6 0
+889499400 0 0 5 12
+889499100 4 12 5 37
+889498800 0 36 1 37
+889498500 0 0 7 27
+889498200 6 27 7 36
+889497900 4 35 5 36
+889497600 4 8 5 39
+889497300 3 38 4 39
+889497000 3 28 3 29
+889496700 3 17 5 18
+889496400 5 5 6 30
+889496100 5 29 6 30
+889495800 3 20 7 28
+889495500 7 27 7 28
+889495200 6 5 7 17
+889494900 2 16 3 17
+889494600 1 4 2 11
+889494300 1 10 12 11
+889494000 11 2 12 2
+889493700 2 2 2 4
+889493400 1 3 2 4
+889493100 0 0 0 0
+889492800 0 0 0 0
+889492500 0 0 0 0
+889492200 0 0 2 3
+889491900 2 3 5 9
+889491600 5 8 5 9
+889491300 4 0 5 1
+889491000 0 0 6 39
+889490700 6 39 6 121
+889490400 5 119 6 121
+889490100 2 0 6 56
+889489800 5 55 6 56
+889489500 0 0 0 0
+889489200 0 0 0 0
+889488900 0 0 0 0
+889488600 0 0 0 0
+889488300 0 0 2 18
+889488000 2 18 7 58
+889487700 6 57 7 58
+889487400 3 3 10 49
+889487100 9 48 10 49
+889486800 7 43 8 44
+889486500 3 28 4 40
+889486200 3 39 4 40
+889485900 0 0 2 29
+889485600 2 29 11 52
+889485300 10 52 11 93
+889485000 3 91 4 93
+889484700 0 1 2 123
+889484400 2 121 7 123
+889484100 6 15 7 27
+889483800 5 28 6 87
+889483500 5 86 6 87
+889483200 6 12 6 27
+889482900 6 27 9 42
+889482600 8 41 9 42
+889482300 0 21 9 22
+889482000 8 22 9 102
+889481700 6 100 7 102
+889481400 5 71 5 72
+889481100 4 50 5 51
+889480800 0 1 2 85
+889480500 1 84 2 85
+889480200 0 0 0 0
+889479900 0 0 2 52
+889479600 2 51 8 52
+889479300 7 12 8 13
+889479000 0 0 3 27
+889478700 2 26 3 27
+889478400 0 0 6 14
+889478100 5 13 6 14
+889477800 2 4 5 5
+889477500 5 0 6 3
+889477200 5 3 6 5
+889476900 2 4 3 5
+889476600 2 0 3 0
+889476300 2 0 3 0
+889476000 2 0 5 0
+889475700 4 0 5 0
+889475400 0 0 3 0
+889475100 3 0 4 2
+889474800 3 1 4 2
+889474500 1 1 2 1
+889474200 1 1 9 8
+889473900 8 7 9 8
+889473600 0 0 3 16
+889473300 2 15 3 16
+889473000 0 0 0 0
+889472700 0 0 4 0
+889472400 4 0 10 2
+889472100 9 2 10 14
+889471800 2 13 3 14
+889471500 0 0 3 10
+889471200 2 9 3 10
+889470900 2 7 7 17
+889470600 6 16 7 17
+889470300 1 9 2 9
+889470000 2 8 2 9
+889469700 1 0 2 0
+889469400 0 0 4 9
+889469100 3 8 4 9
+889468800 0 0 1 1
+889468500 0 1 6 10
+889468200 5 10 6 10
+889467900 5 10 7 10
+889467600 6 10 7 17
+889467300 2 17 5 25
+889467000 4 24 5 25
+889466700 0 0 3 8
+889466400 2 7 3 8
+889466100 0 0 2 2
+889465800 2 2 2 5
+889465500 1 4 2 5
+889465200 0 0 3 62
+889464900 2 61 3 62
+889464600 0 0 3 5
+889464300 3 5 3 85
+889464000 2 84 3 85
+889463700 1 58 3 59
+889463400 2 31 3 32
+889463100 0 0 2 59
+889462800 2 58 3 59
+889462500 2 48 3 66
+889462200 1 66 7 142
+889461900 6 140 7 142
+889461600 0 1 4 156
+889461300 3 154 4 156
+889461000 0 0 10 65
+889460700 9 64 10 65
+889460400 2 11 4 60
+889460100 3 59 4 60
+889459800 2 9 3 10
+889459500 0 1 3 101
+889459200 2 100 3 101
+889458900 1 22 2 67
+889458600 2 66 4 67
+889458300 3 61 4 62
+889458000 0 28 1 37
+889457700 0 36 1 37
+889457400 0 0 3 30
+889457100 2 29 3 30
+889456800 0 0 3 9
+889456500 3 9 5 34
+889456200 5 34 5 80
+889455900 4 79 5 80
+889455600 2 45 3 100
+889455300 2 98 3 100
+889455000 0 0 6 25
+889454700 5 25 6 107
+889454400 3 106 3 107
+889454100 2 48 3 49
+889453800 0 0 5 83
+889453500 5 82 5 83
+889453200 5 13 5 14
+889452900 4 12 5 13
+889452600 0 0 2 11
+889452300 2 11 12 66
+889452000 11 65 12 66
+889451700 0 0 1 11
+889451400 1 11 3 14
+889451100 2 14 3 105
+889450800 0 104 3 105
+889450500 3 52 3 53
+889450200 2 21 3 22
+889449900 2 8 2 30
+889449600 2 29 5 30
+889449300 4 11 5 12
+889449000 0 0 0 0
+889448700 0 0 0 0
+889448400 0 0 1 12
+889448100 1 11 4 12
+889447800 3 3 4 62
+889447500 0 61 1 62
+889447200 0 0 3 0
+889446900 2 0 3 2
+889446600 1 4 2 106
+889446300 1 105 3 106
+889446000 2 17 3 85
+889445700 0 84 1 85
+889445400 1 40 5 58
+889445100 4 57 5 58
+889444800 1 30 2 31
+889444500 0 1 1 107
+889444200 0 104 1 107
+889443900 0 0 0 0
+889443600 0 0 0 0
+889443300 0 0 0 0
+889443000 0 0 0 0
+889442700 0 0 0 0
+889442400 0 0 0 0
+889442100 0 0 0 0
+889441800 0 0 0 0
+889441500 0 0 0 0
+889441200 0 0 0 0
+889440900 0 0 0 0
+889440600 0 0 0 0
+889440300 0 0 0 0
+889440000 0 0 0 0
+889439700 0 0 0 0
+889439400 0 0 0 0
+889439100 0 0 0 0
+889438800 0 0 0 0
+889438500 0 0 0 0
+889438200 0 0 0 0
+889437900 0 0 0 0
+889437600 0 0 0 0
+889437300 0 0 0 0
+889437000 0 0 0 0
+889436700 0 0 0 0
+889436400 0 0 0 0
+889436100 0 0 0 0
+889435800 0 0 0 0
+889435500 0 0 0 0
+889435200 0 0 0 0
+889434900 0 0 0 0
+889434600 0 0 0 0
+889434300 0 0 0 0
+889434000 0 0 0 0
+889433700 0 0 0 0
+889433400 0 0 0 0
+889433100 0 0 0 0
+889432800 0 0 0 0
+889432500 0 0 0 0
+889432200 0 0 0 0
+889431900 0 0 0 0
+889431600 0 0 0 0
+889431300 0 0 0 0
+889431000 0 0 0 0
+889430700 0 0 0 0
+889430400 0 0 0 0
+889428600 0 0 0 0
+889426800 0 0 0 0
+889425000 0 0 0 0
+889423200 0 0 0 0
+889421400 0 0 0 0
+889419600 0 0 0 0
+889417800 0 0 0 0
+889416000 0 0 0 0
+889414200 0 0 0 0
+889412400 0 0 0 0
+889410600 0 0 0 0
+889408800 0 0 0 0
+889407000 0 0 0 0
+889405200 0 0 0 0
+889403400 0 0 0 0
+889401600 0 0 0 0
+889399800 0 0 0 0
+889398000 0 0 0 0
+889396200 0 0 0 0
+889394400 0 0 0 0
+889392600 0 0 0 0
+889390800 0 0 0 0
+889389000 0 0 0 0
+889387200 0 0 0 0
+889385400 0 0 0 0
+889383600 0 0 0 0
+889381800 0 0 0 0
+889380000 0 0 0 0
+889378200 0 0 0 0
+889376400 0 0 0 0
+889374600 0 0 0 0
+889372800 0 0 0 0
+889371000 0 0 0 0
+889369200 0 0 0 0
+889367400 0 0 0 0
+889365600 0 0 0 0
+889363800 0 0 0 0
+889362000 0 0 0 0
+889360200 0 0 0 0
+889358400 0 0 0 0
+889356600 0 0 0 0
+889354800 0 0 0 0
+889353000 0 0 0 0
+889351200 0 0 0 0
+889349400 0 0 0 0
+889347600 0 0 0 0
+889345800 0 0 0 0
+889344000 0 0 0 0
+889342200 0 0 0 0
+889340400 0 0 0 0
+889338600 0 0 0 0
+889336800 0 0 0 0
+889335000 0 0 0 0
+889333200 0 0 0 0
+889331400 0 0 0 0
+889329600 0 0 0 0
+889327800 0 0 0 0
+889326000 0 0 0 0
+889324200 0 0 0 0
+889322400 0 0 0 0
+889320600 0 0 0 0
+889318800 0 0 0 0
+889317000 0 0 0 0
+889315200 0 0 0 0
+889313400 0 0 0 0
+889311600 0 0 0 0
+889309800 0 0 0 0
+889308000 0 0 0 0
+889306200 0 0 0 0
+889304400 0 0 0 0
+889302600 0 0 0 0
+889300800 0 0 0 0
+889299000 0 0 0 0
+889297200 0 0 0 0
+889295400 0 0 0 0
+889293600 0 0 0 0
+889291800 0 0 0 0
+889290000 0 0 0 0
+889288200 0 0 0 0
+889286400 0 0 0 0
+889284600 0 0 0 0
+889282800 0 0 0 0
+889281000 0 0 0 0
+889279200 0 0 0 0
+889277400 0 0 0 0
+889275600 0 0 0 0
+889273800 0 0 0 0
+889272000 0 0 0 0
+889270200 0 0 0 0
+889268400 0 0 0 0
+889266600 0 0 0 0
+889264800 0 0 0 0
+889263000 0 0 0 0
+889261200 0 0 0 0
+889259400 0 0 0 0
+889257600 0 0 0 0
+889255800 0 0 0 0
+889254000 0 0 0 0
+889252200 0 0 0 0
+889250400 0 0 0 0
+889248600 0 0 0 0
+889246800 0 0 0 0
+889245000 0 0 0 0
+889243200 0 0 0 0
+889241400 0 0 0 0
+889239600 0 0 0 0
+889237800 0 0 0 0
+889236000 0 0 0 0
+889234200 0 0 0 0
+889232400 0 0 0 0
+889230600 0 0 0 0
+889228800 0 0 0 0
+889227000 0 0 0 0
+889225200 0 0 0 0
+889223400 0 0 0 0
+889221600 0 0 0 0
+889219800 0 0 0 0
+889218000 0 0 0 0
+889216200 0 0 0 0
+889214400 0 0 0 0
+889212600 0 0 0 0
+889210800 0 0 0 0
+889209000 0 0 0 0
+889207200 0 0 0 0
+889205400 0 0 0 0
+889203600 0 0 0 0
+889201800 0 0 0 0
+889200000 0 0 0 0
+889198200 0 0 0 0
+889196400 0 0 0 0
+889194600 0 0 0 0
+889192800 0 0 0 0
+889191000 0 0 0 0
+889189200 0 0 0 0
+889187400 0 0 0 0
+889185600 0 0 0 0
+889183800 0 0 0 0
+889182000 0 0 0 0
+889180200 0 0 0 0
+889178400 0 0 0 0
+889176600 0 0 0 0
+889174800 0 0 0 0
+889173000 0 0 0 0
+889171200 0 0 0 0
+889169400 0 0 0 0
+889167600 0 0 0 0
+889165800 0 0 0 0
+889164000 0 0 0 0
+889162200 0 0 0 0
+889160400 0 0 0 0
+889158600 0 0 0 0
+889156800 0 0 0 0
+889155000 0 0 0 0
+889153200 0 0 0 0
+889151400 0 0 0 0
+889149600 0 0 0 0
+889147800 0 0 0 0
+889146000 0 0 0 0
+889144200 0 0 0 0
+889142400 0 0 0 0
+889140600 0 0 0 0
+889138800 0 0 0 0
+889137000 0 0 0 0
+889135200 0 0 0 0
+889133400 0 0 0 0
+889131600 0 0 0 0
+889129800 0 0 0 0
+889128000 0 0 0 0
+889126200 0 0 0 0
+889124400 0 0 0 0
+889122600 3 0 9 1
+889120800 2 0 7 31
+889119000 5 8 8 31
+889117200 2 5 5 18
+889115400 2 0 8 2
+889113600 3 2 6 14
+889111800 1 0 6 0
+889110000 1 9 6 53
+889108200 2 0 10 2
+889106400 2 0 7 0
+889104600 2 9 5 46
+889102800 1 0 3 0
+889101000 2 1 5 6
+889099200 0 0 3 6
+889097400 1 0 5 6
+889095600 2 5 5 18
+889093800 3 1 5 9
+889092000 3 3 4 9
+889090200 2 8 4 18
+889088400 2 30 3 86
+889086600 2 61 7 128
+889084800 3 11 7 43
+889083000 3 22 7 65
+889081200 2 6 5 22
+889079400 2 7 6 21
+889077600 2 2 6 16
+889075800 3 0 6 1
+889074000 3 0 5 4
+889072200 2 9 5 41
+889070400 7 0 14 37
+889068600 3 24 11 50
+889066800 3 12 11 24
+889065000 3 9 10 23
+889063200 5 13 10 25
+889061400 3 29 8 58
+889059600 5 8 9 19
+889057800 5 10 11 46
+889056000 8 22 11 96
+889054200 6 39 13 96
+889052400 9 16 15 30
+889050600 6 16 9 57
+889048800 5 25 7 60
+889047000 7 5 14 14
+889045200 5 12 9 44
+889043400 5 0 10 2
+889041600 5 12 11 32
+889039800 3 0 10 1
+889038000 7 20 11 33
+889036200 4 3 13 12
+889034400 7 6 14 16
+889032600 5 8 10 21
+889030800 4 9 9 55
+889029000 4 23 5 41
+889027200 3 14 6 44
+889025400 4 3 7 16
+889023600 1 11 3 55
+889021800 2 11 6 52
+889020000 2 27 6 69
+889018200 2 8 6 52
+889016400 1 3 5 17
+889014600 4 0 9 2
+889012800 2 0 5 2
+889011000 2 10 5 39
+889009200 2 8 6 19
+889007400 3 14 7 42
+889005600 2 12 6 34
+889003800 4 0 6 19
+889002000 2 5 10 19
+889000200 6 9 11 55
+888998400 3 3 6 16
+888996600 2 40 6 86
+888994800 5 12 10 46
+888993000 6 18 12 53
+888991200 3 19 5 44
+888989400 3 4 6 15
+888987600 2 2 7 8
+888985800 3 5 6 15
+888984000 3 0 6 1
+888982200 4 0 8 1
+888980400 3 0 9 1
+888978600 5 2 13 12
+888976800 7 14 15 36
+888975000 4 7 7 30
+888973200 3 11 8 33
+888971400 6 6 8 27
+888969600 5 7 11 33
+888967800 4 15 7 38
+888966000 7 21 10 57
+888964200 6 21 10 46
+888962400 6 8 10 22
+888960600 4 14 8 33
+888958800 4 9 6 25
+888957000 5 20 10 57
+888955200 4 15 9 74
+888953400 3 14 11 42
+888951600 7 26 15 45
+888949800 4 12 9 67
+888948000 3 20 8 61
+888946200 4 26 7 88
+888944400 3 18 6 42
+888942600 4 15 7 38
+888940800 2 0 4 2
+888939000 0 0 5 3
+888937200 2 2 6 18
+888935400 1 0 5 3
+888933600 0 0 3 0
+888931800 0 8 4 39
+888930000 0 0 3 0
+888928200 0 0 3 1
+888926400 0 5 4 19
+888924600 0 0 4 3
+888922800 0 0 3 2
+888921000 1 0 5 17
+888919200 2 5 6 17
+888917400 3 11 8 58
+888915600 2 35 7 86
+888913800 1 32 7 54
+888912000 1 35 5 57
+888910200 1 5 5 18
+888908400 0 10 3 57
+888906600 2 30 6 60
+888904800 2 4 9 30
+888903000 3 13 10 27
+888901200 4 3 9 12
+888899400 2 0 8 5
+888897600 4 5 13 14
+888895800 2 9 7 35
+888894000 3 3 10 14
+888892200 4 0 13 6
+888890400 3 1 13 10
+888888600 3 4 5 17
+888886800 4 19 11 57
+888885000 5 38 9 95
+888883200 6 50 10 164
+888881400 4 93 10 164
+888879600 4 64 13 88
+888877800 5 88 14 136
+888876000 5 51 9 116
+888874200 4 57 7 120
+888872400 3 25 7 60
+888870600 3 6 10 19
+888868800 2 35 4 120
+888867000 6 55 15 103
+888865200 3 76 7 140
+888863400 2 51 7 119
+888861600 3 31 11 78
+888859800 2 39 11 84
+888858000 3 22 7 58
+888856200 2 42 7 124
+888854400 1 32 6 76
+888852600 2 33 10 74
+888850800 1 17 7 40
+888849000 1 0 3 1
+888847200 0 0 4 1
+888845400 1 10 6 63
+888843600 1 1 10 9
+888841800 1 0 10 1
+888840000 1 0 6 4
+888838200 0 19 6 66
+888836400 1 7 4 58
+888834600 1 15 5 58
+888832800 0 32 5 55
+888831000 1 2 5 15
+888829200 1 0 6 1
+888827400 2 1 6 13
+888825600 2 15 4 64
+888823800 2 29 5 65
+888822000 1 3 6 26
+888820200 7 7 30 31
+888818400 0 0 3 4
+888816600 2 0 9 2
+888814800 0 15 2 66
+888813000 1 12 4 31
+888811200 3 3 8 10
+888809400 2 10 10 29
+888807600 3 0 6 1
+888805800 1 0 8 1
+888804000 0 9 2 42
+888802200 3 0 6 1
+888800400 1 3 6 14
+888798600 3 9 6 26
+888796800 2 0 6 1
+888795000 1 13 5 45
+888793200 2 0 7 1
+888791400 2 0 6 3
+888789600 9 4 41 18
+888787800 0 0 0 4
+888786000 0 0 1 1
+888784200 1 1 1 1
+888782400 1 6 6 25
+888780600 1 7 7 35
+888778800 0 0 5 1
+888777000 1 0 4 3
+888775200 3 0 8 2
+888773400 2 45 5 112
+888771600 1 9 4 41
+888769800 1 35 4 107
+888768000 2 12 5 45
+888766200 0 0 2 1
+888764400 0 0 2 1
+888762600 0 0 2 1
+888760800 0 0 4 1
+888759000 0 10 5 39
+888757200 0 0 2 1
+888755400 0 0 2 2
+888753600 0 0 1 2
+888751800 0 0 3 1
+888750000 0 0 2 2
+888748200 2 2 9 15
+888746400 1 6 5 21
+888744600 1 0 4 1
+888742800 1 1 3 15
+888741000 2 0 4 1
+888739200 1 1 3 10
+888737400 2 1 5 6
+888735600 0 0 4 1
+888733800 1 0 6 1
+888732000 3 0 9 0
+888730200 1 2 3 16
+888728400 0 2 3 16
+888726600 1 0 6 2
+888724800 1 0 4 1
+888723000 1 0 3 1
+888721200 2 0 11 3
+888719400 1 13 4 41
+888717600 1 0 4 2
+888715800 1 0 3 2
+888714000 1 3 7 15
+888712200 2 1 7 16
+888710400 2 0 8 5
+888708600 1 0 5 2
+888706800 0 0 3 2
+888705000 2 2 5 17
+888703200 0 0 5 2
+888701400 1 0 5 4
+888699600 1 0 3 1
+888697800 1 0 3 6
+888696000 1 1 6 6
+888694200 0 0 4 2
+888692400 1 10 2 33
+888690600 1 0 5 3
+888688800 1 0 5 2
+888687000 0 0 3 2
+888685200 1 2 5 16
+888683400 1 2 5 14
+888681600 2 0 3 1
+888679800 0 0 3 1
+888678000 1 0 4 1
+888676200 0 4 3 16
+888674400 0 7 3 32
+888672600 0 10 2 32
+888670800 0 10 3 32
+888669000 0 3 2 20
+888667200 0 1 3 16
+888665400 1 7 4 17
+888663600 0 0 3 1
+888661800 0 0 4 2
+888660000 0 2 3 13
+888658200 0 0 3 1
+888656400 0 0 2 1
+888654600 1 0 6 1
+888652800 0 0 3 3
+888651000 2 0 4 3
+888649200 1 2 4 9
+888647400 1 12 4 15
+888645600 2 4 4 9
+888643800 1 6 5 14
+888642000 3 2 5 15
+888640200 1 3 4 15
+888638400 2 1 7 3
+888636600 2 8 6 15
+888634800 2 6 7 14
+888633000 2 39 7 157
+888631200 2 23 9 38
+888629400 6 37 9 57
+888627600 3 12 5 38
+888625800 1 6 6 27
+888624000 3 6 6 36
+888622200 3 5 8 18
+888620400 7 17 10 62
+888618600 4 25 7 60
+888616800 4 8 10 17
+888615000 5 6 8 33
+888613200 4 9 9 17
+888611400 3 7 6 16
+888609600 2 6 5 12
+888607800 4 3 7 12
+888606000 3 6 6 16
+888604200 8 3 13 12
+888602400 1 0 7 0
+888600600 3 0 8 2
+888598800 4 2 10 18
+888597000 4 0 8 0
+888595200 6 0 10 1
+888593400 2 0 6 1
+888591600 1 0 4 2
+888589800 2 0 4 1
+888588000 3 0 5 3
+888586200 2 3 5 48
+888584400 2 2 5 39
+888582600 1 0 2 1
+888580800 1 0 3 2
+888579000 1 0 4 2
+888577200 0 0 2 10
+888575400 2 7 5 16
+888573600 2 0 7 16
+888571800 2 7 4 50
+888570000 2 61 7 104
+888568200 0 5 2 8
+888566400 0 1 5 19
+888564600 1 0 7 3
+888562800 2 3 4 8
+888561000 2 0 8 2
+888559200 3 0 9 1
+888557400 2 1 7 4
+888555600 4 6 6 52
+888553800 1 0 5 1
+888552000 1 0 6 1
+888550200 2 0 5 3
+888548400 3 0 9 2
+888546600 2 6 4 40
+888544800 3 12 6 26
+888543000 4 0 6 1
+888541200 2 18 4 31
+888539400 4 43 10 148
+888537600 8 50 12 111
+888535800 3 35 5 58
+888534000 4 1 7 43
+888532200 3 42 7 85
+888530400 3 24 6 79
+888528600 5 38 11 75
+888526800 3 9 5 15
+888525000 3 77 6 108
+888523200 4 44 14 96
+888521400 6 11 9 73
+888519600 4 48 9 84
+888517800 5 21 9 47
+888516000 5 1 10 10
+888514200 2 0 7 3
+888512400 4 1 8 4
+888510600 4 2 7 5
+888508800 1 7 4 17
+888507000 3 0 10 2
+888505200 2 0 5 2
+888503400 4 0 7 1
+888501600 4 1 6 5
+888499800 2 7 5 53
+888498000 3 47 5 65
+888496200 0 5 2 11
+888494400 1 1 3 16
+888492600 0 0 4 18
+888490800 0 0 4 1
+888489000 1 0 5 1
+888487200 2 2 5 6
+888485400 1 0 3 1
+888483600 1 1 5 4
+888481800 2 11 7 17
+888480000 1 0 7 3
+888478200 5 8 8 25
+888476400 1 0 6 1
+888474600 5 0 9 4
+888472800 2 1 5 17
+888471000 2 3 5 16
+888469200 3 7 7 17
+888467400 1 0 5 1
+888465600 2 0 3 1
+888463800 4 13 7 37
+888462000 4 11 6 25
+888460200 3 0 6 2
+888458400 6 1 10 16
+888456600 5 15 9 33
+888454800 7 8 10 16
+888453000 3 23 7 34
+888451200 7 11 11 22
+888449400 3 4 5 20
+888447600 6 4 9 8
+888445800 3 10 5 18
+888444000 5 14 13 120
+888442200 5 69 11 117
+888440400 6 32 9 53
+888438600 3 0 8 1
+888436800 4 1 11 4
+888435000 4 2 8 8
+888433200 5 3 12 11
+888431400 4 6 8 18
+888429600 4 4 13 15
+888427800 5 1 10 3
+888426000 5 4 9 8
+888424200 3 0 5 1
+888422400 4 6 6 15
+888420600 4 2 8 5
+888418800 6 6 10 15
+888417000 4 3 6 19
+888415200 2 49 6 94
+888413400 1 7 5 17
+888411600 3 35 5 143
+888409800 3 23 5 87
+888408000 0 18 4 28
+888406200 2 0 4 1
+888404400 1 14 3 91
+888402600 3 82 6 138
+888400800 5 8 11 15
+888399000 2 0 4 6
+888397200 1 2 5 13
+888395400 2 2 5 8
+888393600 2 73 4 109
+888391800 3 4 7 15
+888390000 4 0 8 15
+888388200 3 0 8 4
+888386400 5 1 7 8
+888384600 3 49 7 149
+888382800 2 0 6 4
+888381000 2 2 5 16
+888379200 6 30 11 121
+888377400 4 0 8 1
+888375600 3 1 7 13
+888373800 5 4 10 16
+888372000 6 0 9 18
+888370200 6 6 11 30
+888368400 3 6 6 32
+888366600 5 0 11 1
+888364800 3 2 5 25
+888363000 3 36 9 150
+888361200 8 22 11 83
+888359400 2 27 13 57
+888357600 4 53 11 79
+888355800 4 0 8 1
+888354000 3 0 9 3
+888352200 3 2 7 13
+888350400 3 23 8 73
+888343200 4 39 12 145
+888336000 2 7 8 105
+888328800 1 3 9 46
+888321600 3 13 9 101
+888314400 1 15 6 78
+888307200 3 34 8 103
+888300000 2 2 7 15
+888292800 1 22 10 150
+888285600 3 5 10 58
+888278400 4 19 12 61
+888271200 4 6 14 31
+888264000 5 16 21 87
+888256800 4 22 13 149
+888249600 2 43 9 119
+888242400 0 13 4 70
+888235200 0 0 7 26
+888228000 1 5 5 24
+888220800 2 0 9 12
+888213600 0 0 5 12
+888206400 1 5 7 19
+888199200 2 4 9 44
+888192000 2 2 7 41
+888184800 3 12 8 106
+888177600 1 1 6 29
+888170400 1 0 7 14
+888163200 0 13 4 156
+888156000 0 0 4 37
+888148800 1 17 4 142
+888141600 0 2 7 26
+888134400 0 3 3 29
+888127200 0 5 5 52
+888120000 1 2 5 30
+888112800 2 4 10 108
+888105600 3 4 9 153
+888098400 2 14 20 165
+888091200 1 14 9 117
+888084000 1 3 7 16
+888076800 1 1 7 28
+888069600 0 0 3 58
+888062400 1 0 6 14
+888055200 1 0 5 3
+888048000 0 0 4 28
+888040800 0 1 6 19
+888033600 1 2 6 15
+888026400 3 8 10 39
+888019200 3 0 8 10
+888012000 3 7 8 71
+888004800 4 10 9 45
+887997600 4 12 11 89
+887990400 3 9 6 62
+887983200 1 43 7 156
+887976000 1 13 8 115
+887968800 3 19 9 115
+887961600 2 18 7 115
+887954400 3 8 8 51
+887947200 2 5 8 41
+887940000 5 16 13 81
+887932800 5 8 15 82
+887925600 4 43 12 135
+887918400 6 6 11 28
+887911200 3 3 9 23
+887904000 2 1 8 14
+887896800 1 1 6 33
+887889600 2 0 9 8
+887882400 2 8 11 41
+887875200 2 34 6 132
+887868000 2 2 7 21
+887860800 2 7 16 47
+887853600 3 1 11 16
+887846400 3 10 10 105
+887839200 5 17 15 76
+887832000 3 3 10 50
+887824800 2 8 11 46
+887817600 2 1 11 18
+887810400 2 1 9 44
+887803200 2 21 6 126
+887796000 1 12 28 83
+887788800 0 0 5 14
+887781600 1 4 7 30
+887774400 2 4 11 28
+887767200 3 1 9 35
+887760000 3 12 12 89
+887752800 3 34 7 111
+887745600 3 7 12 42
+887738400 3 0 6 32
+887731200 1 16 6 97
+887724000 0 16 9 86
+887716800 1 0 7 13
+887709600 0 0 7 13
+887702400 1 5 7 16
+887695200 1 0 6 16
+887688000 1 1 5 14
+887680800 2 1 12 16
+887673600 3 14 9 161
+887666400 3 2 10 15
+887659200 3 1 14 37
+887652000 3 0 8 12
+887644800 1 0 8 14
+887637600 1 0 5 36
+887630400 1 1 6 16
+887623200 1 1 6 14
+887616000 0 0 9 12
+887608800 1 3 6 12
+887601600 1 3 8 22
+887594400 2 2 7 19
+887587200 3 33 7 115
+887580000 1 11 7 89
+887572800 1 0 8 1
+887565600 3 0 5 0
+887558400 0 7 6 58
+887551200 0 4 4 67
+887544000 0 17 4 61
+887536800 1 1 5 55
+887529600 0 11 4 60
+887522400 0 5 4 28
+887515200 1 2 6 21
+887508000 0 1 6 14
+887500800 1 5 6 28
+887493600 0 0 7 8
+887486400 1 2 6 27
+887479200 0 2 4 14
+887472000 3 1 13 54
+887464800 0 0 4 1
+887457600 0 4 6 60
+887450400 1 0 8 0
+887443200 1 0 4 15
+887436000 2 15 10 92
+887428800 1 1 6 14
+887421600 2 7 10 31
+887414400 3 4 11 32
+887407200 6 9 12 83
+887400000 6 12 13 107
+887392800 5 14 18 47
+887385600 3 3 10 32
+887378400 2 3 5 15
+887371200 1 0 9 45
+887364000 1 4 5 34
+887356800 1 5 8 156
+887349600 2 20 6 51
+887342400 2 4 8 28
+887335200 4 2 14 29
+887328000 3 0 10 15
+887320800 5 3 15 49
+887313600 3 4 9 42
+887306400 3 2 10 14
+887299200 3 4 9 29
+887292000 2 9 7 87
+887284800 0 2 6 51
+887277600 1 6 10 56
+887270400 1 0 8 21
+887263200 1 0 5 13
+887256000 1 2 15 15
+887248800 1 5 9 24
+887241600 4 11 14 121
+887234400 4 0 21 14
+887227200 3 16 11 106
+887220000 3 8 9 140
+887212800 3 25 10 101
+887205600 2 57 8 145
+887198400 0 9 5 29
+887191200 0 4 4 18
+887184000 1 1 6 14
+887176800 1 63 7 163
+887169600 2 2 10 28
+887162400 3 4 8 87
+887155200 2 12 8 76
+887148000 4 27 12 114
+887140800 3 100 8 332
+887133600 3 16 9 63
+887126400 2 1 8 7
+887119200 2 0 12 4
+887112000 1 5 10 66
+887104800 0 24 5 102
+887097600 1 1 9 16
+887090400 1 11 7 93
+887083200 1 0 7 14
+887076000 3 0 8 15
+887068800 3 1 13 15
+887061600 2 1 9 13
+887054400 2 2 10 14
+887047200 2 8 7 85
+887040000 2 9 7 77
+887032800 1 3 7 33
+887025600 0 1 5 40
+887018400 2 0 7 7
+887011200 2 0 7 6
+887004000 0 0 6 7
+886996800 2 0 8 6
+886989600 1 1 6 13
+886982400 1 0 5 14
+886975200 2 0 6 13
+886968000 0 0 6 13
+886960800 0 0 4 1
+886953600 0 0 4 2
+886946400 0 8 7 119
+886939200 0 0 3 33
+886932000 0 0 5 13
+886924800 0 0 4 20
+886917600 0 0 8 2
+886910400 0 0 4 13
+886903200 1 0 7 15
+886896000 1 0 8 24
+886888800 2 0 7 14
+886881600 2 0 8 14
+886874400 2 0 9 14
+886867200 3 0 7 3
+886860000 0 5 4 91
+886852800 0 0 4 32
+886845600 0 0 5 2
+886838400 0 4 4 31
+886831200 1 1 7 44
+886824000 5 0 21 15
+886816800 2 5 10 47
+886809600 3 32 18 180
+886802400 3 20 19 121
+886795200 4 6 13 43
+886788000 6 15 19 66
+886780800 4 0 12 16
+886773600 3 3 15 19
+886766400 1 1 5 49
+886759200 1 9 6 91
+886752000 2 26 10 116
+886744800 1 4 7 30
+886737600 1 24 7 78
+886730400 1 14 11 103
+886723200 3 29 29 55
+886716000 7 17 26 45
+886708800 3 3 9 23
+886701600 3 1 14 20
+886694400 3 13 11 85
+886687200 4 7 25 119
+886680000 1 7 5 95
+886672800 1 5 8 34
+886665600 0 13 6 69
+886658400 3 20 9 95
+886651200 1 4 7 15
+886644000 1 7 9 21
+886636800 2 4 9 29
+886629600 3 4 9 46
+886622400 3 8 11 111
+886615200 2 4 10 37
+886608000 2 2 9 20
+886600800 3 0 9 3
+886593600 0 1 4 44
+886586400 1 1 5 17
+886579200 2 18 6 73
+886572000 1 9 5 39
+886564800 1 3 8 21
+886557600 7 0 32 13
+886550400 4 2 11 35
+886543200 5 3 14 22
+886536000 5 1 13 19
+886528800 2 15 13 74
+886521600 4 2 16 12
+886514400 2 12 9 96
+886507200 2 10 10 37
+886500000 2 1 8 13
+886492800 2 13 8 124
+886485600 1 14 9 64
+886478400 5 6 13 31
+886471200 1 4 7 25
+886464000 3 9 11 49
+886456800 4 5 9 86
+886449600 3 7 10 81
+886442400 6 14 28 150
+886435200 3 4 11 15
+886428000 1 10 7 70
+886420800 0 6 8 92
+886413600 1 0 6 5
+886406400 1 0 7 5
+886399200 1 6 6 52
+886392000 2 0 9 11
+886384800 2 0 9 5
+886377600 3 0 18 16
+886370400 3 29 12 116
+886363200 2 0 22 21
+886356000 0 0 6 5
+886348800 1 2 5 16
+886341600 0 0 2 8
+886334400 0 0 4 36
+886327200 0 0 4 2
+886320000 1 0 6 5
+886312800 0 0 4 10
+886305600 0 0 5 9
+886298400 1 11 6 75
+886291200 1 0 6 15
+886284000 0 0 5 16
+886276800 2 0 7 14
+886269600 1 0 8 1
+886262400 1 0 8 16
+886255200 0 0 4 1
+886248000 0 8 5 107
+886240800 0 0 5 14
+886233600 0 0 4 16
+886226400 1 2 8 20
+886219200 0 0 3 18
+886212000 1 6 8 47
+886204800 3 14 3 14
+886197600 3 14 3 14
+886190400 3 14 3 14
+886183200 3 14 3 14
+886176000 3 14 3 14
+886168800 3 14 3 14
+886161600 3 14 3 14
+886154400 3 14 3 14
+886147200 3 14 3 14
+886140000 3 14 3 14
+886132800 3 14 3 14
+886125600 3 14 3 14
+886118400 3 14 3 14
+886111200 3 14 3 14
+886104000 3 14 3 14
+886096800 3 14 3 14
+886089600 3 14 3 14
+886082400 3 14 3 14
+886075200 3 14 3 14
+886068000 3 14 3 14
+886060800 3 14 3 14
+886053600 3 9 8 14
+886046400 3 1 9 8
+886039200 2 9 8 39
+886032000 2 0 10 22
+886024800 6 12 15 169
+886017600 3 31 10 93
+886010400 4 20 10 97
+886003200 3 31 10 112
+885996000 3 0 7 15
+885988800 2 17 8 89
+885981600 2 26 7 98
+885974400 2 15 13 82
+885967200 2 2 12 24
+885960000 3 9 12 38
+885952800 3 10 9 78
+885945600 5 20 11 77
+885938400 4 34 11 122
+885931200 5 18 10 82
+885924000 4 16 12 61
+885916800 3 22 12 92
+885909600 1 19 8 83
+885902400 1 19 5 118
+885895200 2 2 16 31
+885888000 2 31 7 143
+885880800 2 0 7 27
+885873600 3 10 8 40
+885866400 3 0 10 23
+885859200 3 3 8 32
+885852000 4 6 13 36
+885844800 4 64 16 235
+885837600 3 25 12 69
+885830400 8 0 30 15
+885823200 3 1 7 16
+885816000 1 0 6 48
+885808800 1 15 5 69
+885801600 0 0 6 8
+885794400 1 0 6 11
+885787200 0 0 4 15
+885780000 1 0 6 1
+885772800 2 0 5 14
+885765600 0 0 8 15
+885758400 1 0 4 2
+885751200 1 1 11 15
+885744000 0 3 5 15
+885736800 0 1 5 50
+885729600 0 1 4 20
+885722400 0 0 4 15
+885715200 0 0 4 11
+885708000 0 0 4 15
+885700800 0 0 3 16
+885693600 1 2 4 16
+885686400 1 0 8 15
+885679200 1 0 9 16
+885672000 1 0 7 7
+885664800 0 0 5 10
+885657600 0 0 5 3
+885650400 0 12 3 118
+885643200 0 2 4 33
+885636000 0 0 5 15
+885628800 0 0 5 15
+885621600 0 1 5 30
+885614400 1 0 6 3
+885607200 2 0 10 15
+885600000 2 1 10 38
+885592800 2 1 10 13
+885585600 3 5 7 31
+885578400 3 0 10 16
+885571200 3 0 11 16
+885564000 4 0 19 12
+885556800 0 12 6 69
+885549600 1 17 6 90
+885542400 1 0 5 16
+885535200 2 0 8 13
+885528000 4 0 10 15
+885520800 5 1 12 18
+885513600 3 0 12 18
+885506400 3 5 8 42
+885499200 3 3 14 30
+885492000 5 20 12 60
+885484800 4 1 11 23
+885477600 4 7 17 70
+885470400 0 0 4 36
+885463200 0 0 7 2
+885456000 0 2 5 10
+885448800 1 0 6 17
+885441600 1 2 6 18
+885434400 1 5 7 41
+885427200 3 6 8 37
+885420000 3 0 12 17
+885412800 3 0 8 16
+885405600 4 3 16 21
+885398400 3 1 10 20
+885391200 4 0 16 2
+885384000 1 7 7 68
+885376800 2 11 6 47
+885369600 4 0 9 11
+885362400 1 18 6 101
+885355200 1 1 8 15
+885348000 1 5 9 27
+885340800 3 0 11 20
+885333600 2 2 7 63
+885326400 5 14 14 41
+885319200 5 13 13 43
+885312000 3 8 12 36
+885304800 1 0 9 3
+885297600 1 8 6 38
+885290400 2 9 7 66
+885283200 1 1 8 28
+885276000 2 2 7 20
+885268800 1 0 6 11
+885261600 2 2 8 32
+885254400 2 2 9 30
+885247200 1 0 7 10
+885240000 3 0 11 16
+885232800 1 0 10 19
+885225600 3 0 9 2
+885218400 1 0 12 14
+885211200 1 3 4 35
+885204000 1 0 8 2
+885196800 2 4 9 118
+885189600 0 12 4 56
+885182400 1 0 5 14
+885175200 1 0 4 20
+885168000 2 0 14 14
+885160800 4 2 11 14
+885153600 1 0 6 15
+885146400 1 3 8 22
+885139200 0 2 4 105
+885132000 0 14 6 47
+885124800 0 0 5 40
+885117600 0 0 4 2
+885110400 0 0 3 15
+885103200 0 0 3 24
+885096000 0 0 3 2
+885088800 0 1 4 10
+885081600 0 0 3 15
+885074400 0 3 4 21
+885067200 0 7 5 30
+885060000 1 2 4 15
+885052800 0 0 6 1
+885045600 0 2 3 86
+885038400 0 0 5 61
+885031200 0 1 10 29
+885024000 1 33 6 78
+885016800 2 24 7 116
+885009600 1 5 6 57
+885002400 1 4 7 13
+884995200 1 2 9 15
+884988000 2 1 8 22
+884980800 2 1 7 16
+884973600 3 8 11 31
+884966400 1 5 8 65
+884959200 1 7 6 96
+884952000 0 0 6 39
+884944800 1 4 9 18
+884937600 0 13 5 110
+884930400 1 0 6 8
+884923200 1 1 5 29
+884916000 3 4 9 30
+884908800 4 4 8 24
+884901600 3 2 10 16
+884894400 4 4 11 16
+884887200 2 14 9 109
+884880000 2 0 7 14
+884872800 1 0 6 40
+884865600 2 1 10 24
+884858400 2 0 7 28
+884851200 2 0 7 1
+884844000 2 20 7 117
+884836800 3 1 10 14
+884829600 4 4 17 28
+884822400 3 5 9 33
+884815200 3 7 20 31
+884808000 4 1 8 16
+884800800 2 13 7 93
+884793600 0 0 5 15
+884786400 1 10 10 68
+884779200 1 1 7 40
+884772000 1 0 8 4
+884764800 0 9 5 100
+884757600 1 1 5 14
+884750400 1 1 7 43
+884743200 2 15 6 58
+884736000 2 4 7 28
+884728800 4 9 12 42
+884721600 2 10 10 58
+884714400 3 14 13 38
+884707200 7 36 33 94
+884700000 0 20 6 88
+884692800 1 23 13 89
+884685600 0 6 6 37
+884678400 1 7 5 164
+884671200 0 28 5 150
+884664000 0 0 7 14
+884656800 1 4 7 40
+884649600 3 2 10 14
+884642400 3 17 11 91
+884635200 4 25 8 157
+884628000 4 12 10 90
+884620800 4 0 12 9
+884613600 2 1 10 15
+884606400 1 4 10 101
+884599200 2 0 15 10
+884592000 4 0 21 8
+884584800 0 14 5 132
+884577600 2 0 8 14
+884570400 2 13 10 148
+884563200 2 0 7 11
+884556000 2 45 5 181
+884548800 2 0 8 2
+884541600 1 0 7 2
+884534400 2 3 12 106
+884527200 0 1 5 18
+884520000 0 1 3 57
+884512800 0 0 4 3
+884505600 0 2 6 190
+884498400 2 14 10 68
+884491200 3 0 11 3
+884484000 0 0 3 1
+884476800 0 0 4 15
+884469600 1 12 5 64
+884462400 1 7 5 151
+884455200 1 15 5 63
+884448000 1 7 5 114
+884440800 1 2 6 59
+884433600 0 0 4 30
+884426400 0 0 4 30
+884419200 0 0 6 14
+884412000 0 0 4 15
+884404800 0 0 4 10
+884397600 2 0 12 3
+884390400 3 4 10 24
+884383200 3 0 10 13
+884376000 2 1 7 15
+884368800 4 4 11 24
+884361600 0 0 6 14
+884354400 1 35 7 382
+884347200 0 0 5 42
+884340000 5 0 25 9
+884332800 1 0 10 14
+884325600 0 0 5 16
+884318400 2 1 11 16
+884311200 1 19 7 103
+884304000 2 1 12 29
+884296800 4 6 14 25
+884289600 3 1 7 15
+884282400 2 4 8 45
+884275200 3 13 8 33
+884268000 1 8 7 75
+884260800 0 23 7 93
+884253600 0 0 5 13
+884246400 1 31 5 108
+884239200 1 0 6 1
+884232000 0 1 8 28
+884224800 1 0 6 23
+884217600 2 2 21 34
+884210400 3 3 6 22
+884203200 2 4 9 24
+884196000 2 6 7 24
+884188800 2 4 8 85
+884181600 0 0 7 20
+884174400 1 0 6 45
+884167200 1 2 5 18
+884160000 1 2 5 14
+884152800 0 0 4 15
+884145600 1 0 7 10
+884138400 2 1 7 15
+884131200 1 12 8 130
+884124000 3 62 12 268
+884116800 4 14 9 134
+884109600 3 13 8 71
+884102400 1 6 7 66
+884095200 2 9 5 68
+884088000 0 16 3 178
+884080800 1 18 7 96
+884073600 0 3 4 28
+884066400 1 79 6 694
+884059200 0 10 6 421
+884052000 1 22 8 90
+884044800 1 27 13 343
+884037600 0 0 9 17
+884030400 0 3 8 220
+883958400 0 5 10 143
+883872000 0 1 19 259
+883785600 0 1 9 123
+883699200 0 1 11 125
+883612800 0 1 10 144
+883526400 0 0 9 46
+883440000 0 0 12 50
+883353600 0 19 7 974
+883267200 0 0 6 16
+883180800 0 0 6 84
+883094400 0 31 9 666
+883008000 0 0 8 87
+882921600 0 0 12 58
+882835200 1 13 88 152
+882748800 0 0 13 196
+882662400 0 14 243 775
+882576000 0 0 8 0
+882489600 0 0 9 78
+882403200 0 8 11 187
+882316800 2 6 12 218
+882230400 1 6 35 193
+882144000 2 21 13 167
+882057600 0 12 14 215
+881971200 0 14 10 190
+881884800 1 6 16 185
+881798400 2 12 20 218
+881712000 2 4 13 168
+881625600 1 2 13 198
+881539200 3 1 12 116
+881452800 0 0 13 88
+881366400 0 14 13 642
+881280000 2 17 13 270
+881193600 1 10 10 162
+881107200 1 8 14 187
+881020800 2 4 18 91
+880934400 1 8 25 92
+880848000 0 2 10 105
+880761600 0 3 7 158
+880675200 0 10 11 190
+880588800 2 10 28 468
+880502400 3 9 14 121
+880416000 1 4 13 345
+880329600 2 16 13 163
+880243200 0 3 9 110
+880156800 0 0 11 123
+880070400 3 21 86 198
+879984000 0 4 13 111
+879897600 2 3 57 136
+879811200 2 12 14 155
+879724800 0 2 6 43
+879638400 0 0 0 0
+879552000 0 0 0 0
+879465600 0 0 0 0
+879379200 0 0 0 0
+879292800 0 0 0 0
+879206400 0 0 0 0
+879120000 0 0 0 0
+879033600 0 0 0 0
+878947200 0 0 0 0
+878860800 0 0 0 0
+878774400 0 0 0 0
+878688000 0 0 0 0
+878601600 0 0 0 0
+878515200 0 0 0 0
+878428800 0 0 0 0
+878342400 0 0 0 0
+878256000 0 0 0 0
+878169600 0 0 0 0
+878083200 0 0 0 0
+877996800 0 0 0 0
+877910400 0 0 0 0
+877824000 0 0 0 0
+877737600 0 0 0 0
+877651200 0 0 0 0
+877564800 0 0 0 0
+877478400 0 0 0 0
+877392000 0 0 0 0
+877305600 0 0 0 0
+877219200 0 0 0 0
+877132800 0 0 0 0
+877046400 0 0 0 0
+876960000 0 0 0 0
+876873600 0 0 0 0
+876787200 0 0 0 0
+876700800 0 0 0 0
+876614400 0 0 0 0
+876528000 0 0 0 0
+876441600 0 0 0 0
+876355200 0 0 0 0
+876268800 0 0 0 0
+876182400 0 0 0 0
+876096000 0 0 0 0
+876009600 0 0 0 0
+875923200 0 0 0 0
+875836800 0 0 0 0
+875750400 0 0 0 0
+875664000 0 0 0 0
+875577600 0 0 0 0
+875491200 0 0 0 0
+875404800 0 0 0 0
+875318400 0 0 0 0
+875232000 0 0 0 0
+875145600 0 0 0 0
+875059200 0 0 0 0
+874972800 0 0 0 0
+874886400 0 0 0 0
+874800000 0 0 0 0
+874713600 0 0 0 0
+874627200 0 0 0 0
+874540800 0 0 0 0
+874454400 0 0 0 0
+874368000 0 0 0 0
+874281600 0 0 0 0
+874195200 0 0 0 0
+874108800 0 0 0 0
+874022400 0 0 0 0
+873936000 0 0 0 0
+873849600 0 0 0 0
+873763200 0 0 0 0
+873676800 0 0 0 0
+873590400 0 0 0 0
+873504000 0 0 0 0
+873417600 0 0 0 0
+873331200 0 0 0 0
+873244800 0 0 0 0
+873158400 0 0 0 0
+873072000 0 0 0 0
+872985600 0 0 0 0
+872899200 0 0 0 0
+872812800 0 0 0 0
+872726400 0 0 0 0
+872640000 0 0 0 0
+872553600 0 0 0 0
+872467200 0 0 0 0
+872380800 0 0 0 0
+872294400 0 0 0 0
+872208000 0 0 0 0
+872121600 0 0 0 0
+872035200 0 0 0 0
+871948800 0 0 0 0
+871862400 0 0 0 0
+871776000 0 0 0 0
+871689600 0 0 0 0
+871603200 0 0 0 0
+871516800 0 0 0 0
+871430400 0 0 0 0
+871344000 0 0 0 0
+871257600 0 0 0 0
+871171200 0 0 0 0
+871084800 0 0 0 0
+870998400 0 0 0 0
+870912000 0 0 0 0
+870825600 0 0 0 0
+870739200 0 0 0 0
+870652800 0 0 0 0
+870566400 0 0 0 0
+870480000 0 0 0 0
+870393600 0 0 0 0
+870307200 0 0 0 0
+870220800 0 0 0 0
+870134400 0 0 0 0
+870048000 0 0 0 0
+869961600 0 0 0 0
+869875200 0 0 0 0
+869788800 0 0 0 0
+869702400 0 0 0 0
+869616000 0 0 0 0
+869529600 0 0 0 0
+869443200 0 0 0 0
+869356800 0 0 0 0
+869270400 0 0 0 0
+869184000 0 0 0 0
+869097600 0 0 0 0
+869011200 0 0 0 0
+868924800 0 0 0 0
+868838400 0 0 0 0
+868752000 0 0 0 0
+868665600 0 0 0 0
+868579200 0 0 0 0
+868492800 0 0 0 0
+868406400 0 0 0 0
+868320000 0 0 0 0
+868233600 0 0 0 0
+868147200 0 0 0 0
+868060800 0 0 0 0
+867974400 0 0 0 0
+867888000 0 0 0 0
+867801600 0 0 0 0
+867715200 0 0 0 0
+867628800 0 0 0 0
+867542400 0 0 0 0
+867456000 0 0 0 0
+867369600 0 0 0 0
+867283200 0 0 0 0
+867196800 0 0 0 0
+867110400 0 0 0 0
+867024000 0 0 0 0
+866937600 0 0 0 0
+866851200 0 0 0 0
+866764800 0 0 0 0
+866678400 0 0 0 0
+866592000 0 0 0 0
+866505600 0 0 0 0
+866419200 0 0 0 0
+866332800 0 0 0 0
+866246400 0 0 0 0
+866160000 0 0 0 0
+866073600 0 0 0 0
+865987200 0 0 0 0
+865900800 0 0 0 0
+865814400 0 0 0 0
+865728000 0 0 0 0
+865641600 0 0 0 0
+865555200 0 0 0 0
+865468800 0 0 0 0
+865382400 0 0 0 0
+865296000 0 0 0 0
+865209600 0 0 0 0
+865123200 0 0 0 0
+865036800 0 0 0 0
+864950400 0 0 0 0
+864864000 0 0 0 0
+864777600 0 0 0 0
+864691200 0 0 0 0
+864604800 0 0 0 0
+864518400 0 0 0 0
+864432000 0 0 0 0
+864345600 0 0 0 0
+864259200 0 0 0 0
+864172800 0 0 0 0
+864086400 0 0 0 0
+864000000 0 0 0 0
+863913600 0 0 0 0
+863827200 0 0 0 0
+863740800 0 0 0 0
+863654400 0 0 0 0
+863568000 0 0 0 0
+863481600 0 0 0 0
+863395200 0 0 0 0
+863308800 0 0 0 0
+863222400 0 0 0 0
+863136000 0 0 0 0
+863049600 0 0 0 0
+862963200 0 0 0 0
+862876800 0 0 0 0
+862790400 0 0 0 0
+862704000 0 0 0 0
+862617600 0 0 0 0
+862531200 0 0 0 0
+862444800 0 0 0 0
+862358400 0 0 0 0
+862272000 0 0 0 0
+862185600 0 0 0 0
+862099200 0 0 0 0
+862012800 0 0 0 0
+861926400 0 0 0 0
+861840000 0 0 0 0
+861753600 0 0 0 0
+861667200 0 0 0 0
+861580800 0 0 0 0
+861494400 0 0 0 0
+861408000 0 0 0 0
+861321600 0 0 0 0
+861235200 0 0 0 0
+861148800 0 0 0 0
+861062400 0 0 0 0
+860976000 0 0 0 0
+860889600 0 0 0 0
+860803200 0 0 0 0
+860716800 0 0 0 0
+860630400 0 0 0 0
+860544000 0 0 0 0
+860457600 0 0 0 0
+860371200 0 0 0 0
+860284800 0 0 0 0
+860198400 0 0 0 0
+860112000 0 0 0 0
+860025600 0 0 0 0
+859939200 0 0 0 0
+859852800 0 0 0 0
+859766400 0 0 0 0
+859680000 0 0 0 0
+859593600 0 0 0 0
+859507200 0 0 0 0
+859420800 0 0 0 0
+859334400 0 0 0 0
+859248000 0 0 0 0
+859161600 0 0 0 0
+859075200 0 0 0 0
+858988800 0 0 0 0
+858902400 0 0 0 0
+858816000 0 0 0 0
+858729600 0 0 0 0
+858643200 0 0 0 0
+858556800 0 0 0 0
+858470400 0 0 0 0
+858384000 0 0 0 0
+858297600 0 0 0 0
+858211200 0 0 0 0
+858124800 0 0 0 0
+858038400 0 0 0 0
+857952000 0 0 0 0
+857865600 0 0 0 0
+857779200 0 0 0 0
+857692800 0 0 0 0
+857606400 0 0 0 0
+857520000 0 0 0 0
+857433600 0 0 0 0
+857347200 0 0 0 0
+857260800 0 0 0 0
+857174400 0 0 0 0
+857088000 0 0 0 0
+857001600 0 0 0 0
+856915200 0 0 0 0
+856828800 0 0 0 0
+856742400 0 0 0 0
+856656000 0 0 0 0
+856569600 0 0 0 0
+856483200 0 0 0 0
+856396800 0 0 0 0
+856310400 0 0 0 0
+856224000 0 0 0 0
+856137600 0 0 0 0
+856051200 0 0 0 0
+855964800 0 0 0 0
+855878400 0 0 0 0
+855792000 0 0 0 0
+855705600 0 0 0 0
+855619200 0 0 0 0
+855532800 0 0 0 0
+855446400 0 0 0 0
+855360000 0 0 0 0
+855273600 0 0 0 0
+855187200 0 0 0 0
+855100800 0 0 0 0
+855014400 0 0 0 0
+854928000 0 0 0 0
+854841600 0 0 0 0
+854755200 0 0 0 0
+854668800 0 0 0 0
+854582400 0 0 0 0
+854496000 0 0 0 0
+854409600 0 0 0 0
+854323200 0 0 0 0
+854236800 0 0 0 0
+854150400 0 0 0 0
+854064000 0 0 0 0
+853977600 0 0 0 0
+853891200 0 0 0 0
+853804800 0 0 0 0
+853718400 0 0 0 0
+853632000 0 0 0 0
+853545600 0 0 0 0
+853459200 0 0 0 0
+853372800 0 0 0 0
+853286400 0 0 0 0
+853200000 0 0 0 0
+853113600 0 0 0 0
+853027200 0 0 0 0
+852940800 0 0 0 0
+852854400 0 0 0 0
+852768000 0 0 0 0
+852681600 0 0 0 0
+852595200 0 0 0 0
+852508800 0 0 0 0
+852422400 0 0 0 0
+852336000 0 0 0 0
+852249600 0 0 0 0
+852163200 0 0 0 0
+852076800 0 0 0 0
+851990400 0 0 0 0
+851904000 0 0 0 0
+851817600 0 0 0 0
+851731200 0 0 0 0
+851644800 0 0 0 0
+851558400 0 0 0 0
+851472000 0 0 0 0
+851385600 0 0 0 0
+851299200 0 0 0 0
+851212800 0 0 0 0
+851126400 0 0 0 0
+851040000 0 0 0 0
+850953600 0 0 0 0
+850867200 0 0 0 0
+850780800 0 0 0 0
+850694400 0 0 0 0
+850608000 0 0 0 0
+850521600 0 0 0 0
+850435200 0 0 0 0
+850348800 0 0 0 0
+850262400 0 0 0 0
+850176000 0 0 0 0
+850089600 0 0 0 0
+850003200 0 0 0 0
+849916800 0 0 0 0
+849830400 0 0 0 0
+849744000 0 0 0 0
+849657600 0 0 0 0
+849571200 0 0 0 0
+849484800 0 0 0 0
+849398400 0 0 0 0
+849312000 0 0 0 0
+849225600 0 0 0 0
+849139200 0 0 0 0
+849052800 0 0 0 0
+848966400 0 0 0 0
+848880000 0 0 0 0
+848793600 0 0 0 0
+848707200 0 0 0 0
+848620800 0 0 0 0
+848534400 0 0 0 0
+848448000 0 0 0 0
+848361600 0 0 0 0
+848275200 0 0 0 0
+848188800 0 0 0 0
+848102400 0 0 0 0
+848016000 0 0 0 0
+847929600 0 0 0 0
+847843200 0 0 0 0
+847756800 0 0 0 0
+847670400 0 0 0 0
+847584000 0 0 0 0
+847497600 0 0 0 0
+847411200 0 0 0 0
+847324800 0 0 0 0
+847238400 0 0 0 0
+847152000 0 0 0 0
+847065600 0 0 0 0
+846979200 0 0 0 0
+846892800 0 0 0 0
+846806400 0 0 0 0
+846720000 0 0 0 0
+846633600 0 0 0 0
+846547200 0 0 0 0
+846460800 0 0 0 0
+846374400 0 0 0 0
+846288000 0 0 0 0
+846201600 0 0 0 0
+846115200 0 0 0 0
+846028800 0 0 0 0
+845942400 0 0 0 0
+845856000 0 0 0 0
+845769600 0 0 0 0
+845683200 0 0 0 0
+845596800 0 0 0 0
+845510400 0 0 0 0
+845424000 0 0 0 0
+845337600 0 0 0 0
+845251200 0 0 0 0
+845164800 0 0 0 0
+845078400 0 0 0 0
+844992000 0 0 0 0
+844905600 0 0 0 0
+844819200 0 0 0 0
+844732800 0 0 0 0
+844646400 0 0 0 0
+844560000 0 0 0 0
+844473600 0 0 0 0
+844387200 0 0 0 0
+844300800 0 0 0 0
+844214400 0 0 0 0
+844128000 0 0 0 0
+844041600 0 0 0 0
+843955200 0 0 0 0
+843868800 0 0 0 0
+843782400 0 0 0 0
+843696000 0 0 0 0
+843609600 0 0 0 0
+843523200 0 0 0 0
+843436800 0 0 0 0
+843350400 0 0 0 0
+843264000 0 0 0 0
+843177600 0 0 0 0
+843091200 0 0 0 0
+843004800 0 0 0 0
+842918400 0 0 0 0
+842832000 0 0 0 0
+842745600 0 0 0 0
+842659200 0 0 0 0
+842572800 0 0 0 0
+842486400 0 0 0 0
+842400000 0 0 0 0
+842313600 0 0 0 0
+842227200 0 0 0 0
+842140800 0 0 0 0
+842054400 0 0 0 0
+841968000 0 0 0 0
+841881600 0 0 0 0
+841795200 0 0 0 0
+841708800 0 0 0 0
+841622400 0 0 0 0
+841536000 0 0 0 0
+841449600 0 0 0 0
+841363200 0 0 0 0
+841276800 0 0 0 0
+841190400 0 0 0 0
+841104000 0 0 0 0
+841017600 0 0 0 0
+840931200 0 0 0 0
+840844800 0 0 0 0
+840758400 0 0 0 0
+840672000 0 0 0 0
+840585600 0 0 0 0
+840499200 0 0 0 0
+840412800 0 0 0 0
+840326400 0 0 0 0
+840240000 0 0 0 0
+840153600 0 0 0 0
+840067200 0 0 0 0
+839980800 0 0 0 0
+839894400 0 0 0 0
+839808000 0 0 0 0
+839721600 0 0 0 0
+839635200 0 0 0 0
+839548800 0 0 0 0
+839462400 0 0 0 0
+839376000 0 0 0 0
+839289600 0 0 0 0
+839203200 0 0 0 0
+839116800 0 0 0 0
+839030400 0 0 0 0
+838944000 0 0 0 0
+838857600 0 0 0 0
+838771200 0 0 0 0
+838684800 0 0 0 0
+838598400 0 0 0 0
+838512000 0 0 0 0
+838425600 0 0 0 0
+838339200 0 0 0 0
+838252800 0 0 0 0
+838166400 0 0 0 0
+838080000 0 0 0 0
+837993600 0 0 0 0
+837907200 0 0 0 0
+837820800 0 0 0 0
+837734400 0 0 0 0
+837648000 0 0 0 0
+837561600 0 0 0 0
+837475200 0 0 0 0
+837388800 0 0 0 0
+837302400 0 0 0 0
+837216000 0 0 0 0
+837129600 0 0 0 0
+837043200 0 0 0 0
+836956800 0 0 0 0
+836870400 0 0 0 0
+836784000 0 0 0 0
+836697600 0 0 0 0
+836611200 0 0 0 0
+836524800 0 0 0 0
+836438400 0 0 0 0
+836352000 0 0 0 0
+836265600 0 0 0 0
+836179200 0 0 0 0
+836092800 0 0 0 0
+836006400 0 0 0 0
+835920000 0 0 0 0
+835833600 0 0 0 0
+835747200 0 0 0 0
+835660800 0 0 0 0
+835574400 0 0 0 0
+835488000 0 0 0 0
+835401600 0 0 0 0
+835315200 0 0 0 0
+835228800 0 0 0 0
+835142400 0 0 0 0
+835056000 0 0 0 0
+834969600 0 0 0 0
+834883200 0 0 0 0
+834796800 0 0 0 0
+834710400 0 0 0 0
+834624000 0 0 0 0
+834537600 0 0 0 0
+834451200 0 0 0 0
+834364800 0 0 0 0
+834278400 0 0 0 0
+834192000 0 0 0 0
+834105600 0 0 0 0
+834019200 0 0 0 0
+833932800 0 0 0 0
+833846400 0 0 0 0
+833760000 0 0 0 0
+833673600 0 0 0 0
+833587200 0 0 0 0
+833500800 0 0 0 0
+833414400 0 0 0 0
+833328000 0 0 0 0
+833241600 0 0 0 0
+833155200 0 0 0 0
+833068800 0 0 0 0
+832982400 0 0 0 0
+832896000 0 0 0 0
+832809600 0 0 0 0
+832723200 0 0 0 0
+832636800 0 0 0 0
+832550400 0 0 0 0
+832464000 0 0 0 0
+832377600 0 0 0 0
+832291200 0 0 0 0
+832204800 0 0 0 0
+832118400 0 0 0 0
+832032000 0 0 0 0
+831945600 0 0 0 0
+831859200 0 0 0 0
+831772800 0 0 0 0
+831686400 0 0 0 0
+831600000 0 0 0 0
+831513600 0 0 0 0
+831427200 0 0 0 0
+831340800 0 0 0 0
+831254400 0 0 0 0
+831168000 0 0 0 0
+831081600 0 0 0 0
+830995200 0 0 0 0
+830908800 0 0 0 0
+830822400 0 0 0 0
+830736000 0 0 0 0
+830649600 0 0 0 0
+830563200 0 0 0 0
+830476800 0 0 0 0
+830390400 0 0 0 0
+830304000 0 0 0 0
+830217600 0 0 0 0
+830131200 0 0 0 0
+830044800 0 0 0 0
+829958400 0 0 0 0
+829872000 0 0 0 0
+829785600 0 0 0 0
+829699200 0 0 0 0
+829612800 0 0 0 0
+829526400 0 0 0 0
+829440000 0 0 0 0
+829353600 0 0 0 0
+829267200 0 0 0 0
+829180800 0 0 0 0
+829094400 0 0 0 0
+829008000 0 0 0 0
+828921600 0 0 0 0
+828835200 0 0 0 0
+828748800 0 0 0 0
+828662400 0 0 0 0
+828576000 0 0 0 0
+828489600 0 0 0 0
+828403200 0 0 0 0
+828316800 0 0 0 0
+828230400 0 0 0 0
+828144000 0 0 0 0
+828057600 0 0 0 0
+827971200 0 0 0 0
+827884800 0 0 0 0
+827798400 0 0 0 0
+827712000 0 0 0 0
+827625600 0 0 0 0
+827539200 0 0 0 0
+827452800 0 0 0 0
+827366400 0 0 0 0
+827280000 0 0 0 0
+827193600 0 0 0 0
+827107200 0 0 0 0
+827020800 0 0 0 0
+826934400 0 0 0 0
+826848000 0 0 0 0
+826761600 0 0 0 0
+826675200 0 0 0 0
+826588800 0 0 0 0
+826502400 0 0 0 0
+826416000 0 0 0 0
+826329600 0 0 0 0
+826243200 0 0 0 0
+826156800 0 0 0 0
+826070400 0 0 0 0
+825984000 0 0 0 0
+825897600 0 0 0 0
+825811200 0 0 0 0
+825724800 0 0 0 0
+825638400 0 0 0 0
+825552000 0 0 0 0
+825465600 0 0 0 0
+825379200 0 0 0 0
+825292800 0 0 0 0
+825206400 0 0 0 0
+825120000 0 0 0 0
+825033600 0 0 0 0
+824947200 0 0 0 0
+824860800 0 0 0 0
+824774400 0 0 0 0
+824688000 0 0 0 0
+824601600 0 0 0 0
+824515200 0 0 0 0
+824428800 0 0 0 0
+824342400 0 0 0 0
+824256000 0 0 0 0
+824169600 0 0 0 0
+824083200 0 0 0 0
+823996800 0 0 0 0
+823910400 0 0 0 0
+823824000 0 0 0 0
+823737600 0 0 0 0
+823651200 0 0 0 0
+823564800 0 0 0 0
+823478400 0 0 0 0
+823392000 0 0 0 0
+823305600 0 0 0 0
+823219200 0 0 0 0
+823132800 0 0 0 0
+823046400 0 0 0 0
+822960000 0 0 0 0
+822873600 0 0 0 0
+822787200 0 0 0 0
+822700800 0 0 0 0
+822614400 0 0 0 0
+822528000 0 0 0 0
+822441600 0 0 0 0
+822355200 0 0 0 0
+822268800 0 0 0 0
+822182400 0 0 0 0
+822096000 0 0 0 0
+822009600 0 0 0 0
+821923200 0 0 0 0
+821836800 0 0 0 0
+821750400 0 0 0 0
+821664000 0 0 0 0
+821577600 0 0 0 0
+821491200 0 0 0 0
+821404800 0 0 0 0
+821318400 0 0 0 0
+821232000 0 0 0 0
+821145600 0 0 0 0
+821059200 0 0 0 0
+820972800 0 0 0 0
+820886400 0 0 0 0
+820800000 0 0 0 0
--- /dev/null
+#!/usr/local/bin/perl -w
+#
+# Author: Petter Reinholdtsen <pere@td.org.uit.no>
+# Date: 1997-07-09
+# The original was written by Rachel Polanskis <rachel@juno.virago.org.au>
+#
+# Fetches output from mailstats(1) either via TCP or via exec and
+# feeds changes on smtp to mrtg.
+#
+# Irix 6.x seems to lack mailstats
+#
+# Usage mailstats [host]
+# if host is missing, localhost is used
+
+use strict;
+use Socket;
+
+my($datafile, $source, $sourceport, @mailstatspaths,
+ $oldfrm, $oldto,
+ $newfrm, $newto, $uptime);
+
+# Adjust this to your own mailserver. Uses local `mailstats` if set
+# to 'localhost'
+$source = $ARGV[0] || "localhost";
+$sourceport = "7256";
+
+$datafile = "/tmp/mailstat-$source.old";
+@mailstatspaths = ( "/usr/sbin/mailstats", "/usr/bin/mailstats" );
+
+($oldfrm, $oldto) = getOldStats($datafile);
+
+($newfrm, $newto, $uptime) = getStats($source, $sourceport);
+
+putOldStats($datafile, $newfrm, $newto) || warn "$0: Unable to save stats to $datafile";
+
+print $newfrm-$oldfrm,"\n",$newto-$oldto,"\n","$uptime\n$source\n" if ($oldfrm);
+
+##
+# Returns first line of file given as param splittet on space
+sub getOldStats {
+ my($filename) = @_;
+ open(OLD, $filename) || warn "$0: Unable to open $filename for reading";
+ my($line) = <OLD>;
+ close(OLD);
+ return split(/ /, $line);
+}
+
+sub findFirstExecutable {
+ my($filename);
+ foreach $filename (@_) {
+ return $filename if ( -x $filename && ! -d $filename );
+ }
+}
+
+sub getStats {
+ my($source, $sourceport) = @_;
+ my(@output, $port, $proto, $iaddr, $paddr);
+ if ( $source eq "localhost" ) {
+ my($progpath) = findFirstExecutable(@mailstatspaths);
+ @output = `$progpath`;
+ chomp(@output);
+ } else {
+ $port = $sourceport;
+ $port = getservbyname ($sourceport, 'tcp') if ($sourceport =~ /\D/);
+ die "$0: Bad port \"$sourceport\"" unless ($port);
+ $proto = getprotobyname ('tcp') || die "$0: Bad prototype tcp";
+
+ $iaddr = inet_aton($source) or die "$0: no host \"$source\"";
+ $paddr = sockaddr_in($port, $iaddr);
+
+ socket (SOCK, PF_INET, SOCK_STREAM, $proto) or die "$0: socket error $!";
+ connect (SOCK, $paddr) or die "$0: connect error $!";
+
+ while (<SOCK>) {
+ push(@output,$_);
+ }
+ close(SOCK) || warn "$0: socket close error $!";
+ }
+ my($curfrm, $curto, $uptime);
+ foreach (@output) {
+ # Our sendmail reports smtp as uucp (stupid admin... :-)
+ ($curfrm, $curto) = (split(/ +/))[2,4] if (/uucp|e?smtp/);
+ ($uptime) = m/Statistics from (.*)/ if (/Stati/);
+ }
+ return ($curfrm, $curto, $uptime);
+}
+
+sub putOldStats {
+ my($filename, $frm, $to) = @_;
+ open(STAT, ">$filename") || return "";
+ print STAT "$frm $to\n";
+ close(STAT);
+ return "1";
+}
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>
+terror.hungry.com Sendmail MailQueue Statistics
+</TITLE>
+<META HTTP-EQUIV="Refresh" CONTENT=300 >
+<META HTTP-EQUIV="Expires" CONTENT="Wed, 11 Mar 1998 10:05:26 GMT">
+<!-- maxin d 0 -->
+<!-- maxout d 377 -->
+<!-- avin d 0 -->
+<!-- avout d 261 -->
+<!-- cuin d 0 -->
+<!-- cuout d 207 -->
+<!-- maxin w 0 -->
+<!-- maxout w 374 -->
+<!-- avin w 0 -->
+<!-- avout w 188 -->
+<!-- cuin w 0 -->
+<!-- cuout w 192 -->
+<!-- maxin m 0 -->
+<!-- maxout m 378 -->
+<!-- avin m 0 -->
+<!-- avout m 90 -->
+<!-- cuin m 0 -->
+<!-- cuout m 203 -->
+<!-- maxin y 0 -->
+<!-- maxout y 0 -->
+<!-- avin y 0 -->
+<!-- avout y 0 -->
+<!-- cuin y 0 -->
+<!-- cuout y -->
+
+</HEAD>
+<BODY bgcolor=#000000 text="#ffffff" link="#cfcfcf" alink="#00ff00" vlink="#9f9f9f">
+<H2>terror.hungry.com Sendmail MailQueue Statistics</H2><P>
+<HR>
+The statistics were last updated <B>Wednesday, 11 March 1998 at 2:00 </B>
+,<BR>
+at which time <B>'terror.hungry.com'</B> had been up for <B>1</B>.
+
+<HR>
+<B>`Daily' Graph (5 Minute Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mq-day.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>377.0 Mailq
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>261.0 Mailq
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>207.0 Mailq
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+<HR>
+<B>`Weekly' Graph (30 Minute Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mq-week.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>374.0 Mailq
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>188.0 Mailq
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>192.0 Mailq
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+<HR>
+<B>`Monthly' Graph (2 Hour Average)</B><BR>
+<IMG VSPACE=10 WIDTH=600 HEIGHT=163 ALIGN=TOP
+ SRC="mq-month.gif">
+ <TABLE CELLPADDING=0 CELLSPACING=0>
+
+ <TR>
+ <TD ALIGN=right><SMALL>Max<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>378.0 Mailq
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Average<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>90.0 Mailq
+ </SMALL></TD>
+ <TD WIDTH=5></TD>
+ <TD ALIGN=right><SMALL>Current<FONT COLOR=#0000ff> Mailq:</FONT></SMALL></TD>
+ <TD ALIGN=right><SMALL>203.0 Mailq
+ </SMALL></TD>
+ </TR>
+</TABLE>
+
+ <HR><P>
+ <TABLE WIDTH=500 BORDER=0 CELLPADDING=4 CELLSPACING=0>
+ <TR><TD ALIGN=RIGHT><FONT SIZE=-1 COLOR="#0000ff">
+ <B>BLUE ###</B></FONT></TD>
+ <TD><FONT SIZE=-1>Outgoing Traffic in Bytes per Second</FONT></TD></TR>
+ <TR><TD ALIGN=RIGHT><FONT SIZE=-1 COLOR="#ff00ff">
+ <B>MAGENTA###</B></FONT></TD>
+ <TD><FONT SIZE=-1>Maximal 5 Minute Outgoing Traffic</FONT></TD></TR> </TABLE><P><HR><P>
+
+<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
+ <TR>
+ <TD WIDTH=63><A ALT="MRTG"
+ HREF="http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-l.gif"></A></TD>
+ <TD WIDTH=25><A ALT=""
+ HREF="http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-m.gif"></A></TD>
+ <TD WIDTH=388><A ALT=""
+ HREF="http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html"><IMG
+ BORDER=0 SRC="mrtg-r.gif"></A></TD>
+ </TR>
+</TABLE>
+<SPACER TYPE=VERTICAL SIZE=4>
+<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
+ <TR VALIGN=top>
+ <TD WIDTH=88 ALIGN=RIGHT><FONT FACE="Arial,Helvetica" SIZE=2>
+ 2.5.1-1997/10/24</FONT></TD>
+ <TD WIDTH=388 ALIGN=RIGHT><FONT FACE="Arial,Helvetica" SIZE=2>
+ <A HREF="http://ee-staff.ethz.ch/~oetiker/">Tobias Oetiker</A>
+ <A HREF="mailto:oetiker@ee.ethz.ch"><oetiker@ee.ethz.ch></A>
+ and <A HREF="http://www.bungi.com">Dave Rand</A> <A HREF="mailto:dlr@bungi.com"><dlr@bungi.com></A></FONT>
+ </TD>
+</TR>
+</TABLE>
+</BODY>
+</HTML>
--- /dev/null
+889610409 0 208
+889610409 0 208 0 208
+889610107 0 203 0 203
+889610100 0 203 0 204
+889609800 0 203 0 204
+889609500 0 196 0 197
+889609200 0 193 0 194
+889608900 0 192 0 196
+889608600 0 195 0 196
+889608300 0 193 0 194
+889608000 0 192 0 194
+889607700 0 193 0 194
+889607400 0 192 0 192
+889607100 0 192 0 193
+889606800 0 193 0 193
+889606500 0 193 0 193
+889606200 0 193 0 193
+889605900 0 192 0 193
+889605600 0 192 0 193
+889605300 0 193 0 193
+889605000 0 192 0 193
+889604700 0 191 0 191
+889604400 0 191 0 192
+889604100 0 191 0 192
+889603800 0 191 0 193
+889603500 0 193 0 193
+889603200 0 193 0 193
+889602900 0 193 0 193
+889602600 0 193 0 194
+889602300 0 194 0 197
+889602000 0 197 0 199
+889601700 0 199 0 199
+889601400 0 199 0 199
+889601100 0 199 0 202
+889600800 0 201 0 202
+889600500 0 200 0 200
+889600200 0 200 0 204
+889599900 0 204 0 212
+889599600 0 212 0 212
+889599300 0 212 0 213
+889599000 0 212 0 213
+889598700 0 211 0 212
+889598400 0 212 0 212
+889598100 0 212 0 212
+889597800 0 211 0 212
+889597500 0 208 0 209
+889597200 0 204 0 205
+889596900 0 202 0 203
+889596600 0 202 0 202
+889596300 0 202 0 206
+889596000 0 206 0 206
+889595700 0 206 0 206
+889595400 0 206 0 207
+889595100 0 207 0 207
+889594800 0 207 0 207
+889594500 0 207 0 207
+889594200 0 207 0 213
+889593900 0 213 0 214
+889593600 0 213 0 214
+889593300 0 211 0 212
+889593000 0 210 0 210
+889592700 0 210 0 210
+889592400 0 210 0 212
+889592100 0 212 0 212
+889591800 0 212 0 214
+889591500 0 213 0 214
+889591200 0 210 0 210
+889590900 0 210 0 210
+889590600 0 210 0 212
+889590300 0 211 0 212
+889590000 0 210 0 210
+889589700 0 210 0 210
+889589400 0 210 0 210
+889589100 0 210 0 210
+889588800 0 210 0 210
+889588500 0 210 0 210
+889588200 0 210 0 210
+889587900 0 210 0 210
+889587600 0 210 0 212
+889587300 0 212 0 212
+889587000 0 212 0 212
+889586700 0 212 0 213
+889586400 0 212 0 213
+889586100 0 212 0 212
+889585800 0 212 0 212
+889585500 0 212 0 212
+889585200 0 212 0 212
+889584900 0 212 0 212
+889584600 0 212 0 212
+889584300 0 212 0 213
+889584000 0 212 0 213
+889583700 0 212 0 213
+889583400 0 212 0 213
+889583100 0 212 0 212
+889582800 0 212 0 212
+889582500 0 212 0 215
+889582200 0 215 0 215
+889581900 0 214 0 215
+889581600 0 214 0 214
+889581300 0 214 0 216
+889581000 0 215 0 216
+889580700 0 213 0 214
+889580400 0 214 0 231
+889580100 0 231 0 237
+889579800 0 237 0 237
+889579500 0 237 0 238
+889579200 0 238 0 238
+889578900 0 237 0 238
+889578600 0 237 0 238
+889578300 0 238 0 238
+889578000 0 238 0 239
+889577700 0 238 0 239
+889577400 0 238 0 238
+889577100 0 238 0 244
+889576800 0 243 0 244
+889576500 0 238 0 239
+889576200 0 237 0 237
+889575900 0 237 0 237
+889575600 0 237 0 237
+889575300 0 237 0 243
+889575000 0 243 0 246
+889574700 0 245 0 246
+889574400 0 243 0 243
+889574100 0 243 0 243
+889573800 0 243 0 244
+889573500 0 243 0 244
+889573200 0 243 0 243
+889572900 0 243 0 246
+889572600 0 245 0 246
+889572300 0 244 0 244
+889572000 0 244 0 246
+889571700 0 245 0 246
+889571400 0 244 0 244
+889571100 0 244 0 246
+889570800 0 246 0 246
+889570500 0 246 0 246
+889570200 0 246 0 249
+889569900 0 249 0 251
+889569600 0 250 0 251
+889569300 0 246 0 246
+889569000 0 246 0 249
+889568700 0 248 0 249
+889568400 0 246 0 248
+889568100 0 247 0 248
+889567800 0 245 0 246
+889567500 0 246 0 249
+889567200 0 248 0 249
+889566900 0 248 0 250
+889566600 0 250 0 251
+889566300 0 250 0 251
+889566000 0 249 0 250
+889565700 0 247 0 247
+889565400 0 246 0 247
+889565100 0 246 0 246
+889564800 0 245 0 246
+889564500 0 243 0 244
+889564200 0 241 0 242
+889563900 0 242 0 245
+889563600 0 244 0 245
+889563300 0 243 0 244
+889563000 0 242 0 243
+889562700 0 241 0 242
+889562400 0 241 0 250
+889562100 0 249 0 250
+889561800 0 247 0 252
+889561500 0 251 0 252
+889561200 0 242 0 242
+889560900 0 242 0 243
+889560600 0 242 0 243
+889560300 0 242 0 242
+889560000 0 242 0 243
+889559700 0 243 0 247
+889559400 0 246 0 247
+889559100 0 240 0 241
+889558800 0 239 0 244
+889558500 0 243 0 244
+889558200 0 241 0 242
+889557900 0 240 0 241
+889557600 0 237 0 239
+889557300 0 238 0 239
+889557000 0 237 0 237
+889556700 0 237 0 238
+889556400 0 238 0 238
+889556100 0 238 0 238
+889555800 0 238 0 238
+889555500 0 238 0 242
+889555200 0 241 0 242
+889554900 0 238 0 240
+889554600 0 239 0 240
+889554300 0 239 0 242
+889554000 0 241 0 242
+889553700 0 241 0 242
+889553400 0 242 0 242
+889553100 0 242 0 243
+889552800 0 243 0 245
+889552500 0 244 0 245
+889552200 0 243 0 243
+889551900 0 243 0 247
+889551600 0 246 0 247
+889551300 0 244 0 244
+889551000 0 244 0 245
+889550700 0 245 0 246
+889550400 0 246 0 248
+889550100 0 248 0 248
+889549800 0 248 0 249
+889549500 0 249 0 251
+889549200 0 250 0 251
+889548900 0 248 0 249
+889548600 0 248 0 248
+889548300 0 248 0 249
+889548000 0 248 0 249
+889547700 0 247 0 247
+889547400 0 247 0 247
+889547100 0 247 0 248
+889546800 0 248 0 248
+889546500 0 247 0 248
+889546200 0 247 0 247
+889545900 0 247 0 247
+889545600 0 247 0 248
+889545300 0 248 0 248
+889545000 0 248 0 248
+889544700 0 247 0 248
+889544400 0 246 0 247
+889544100 0 243 0 243
+889543800 0 243 0 246
+889543500 0 246 0 248
+889543200 0 247 0 248
+889542900 0 244 0 245
+889542600 0 242 0 242
+889542300 0 242 0 242
+889542000 0 242 0 242
+889541700 0 242 0 242
+889541400 0 241 0 242
+889541100 0 241 0 241
+889540800 0 241 0 241
+889540500 0 240 0 241
+889540200 0 239 0 240
+889539900 0 238 0 239
+889539600 0 237 0 238
+889539300 0 236 0 237
+889539000 0 233 0 233
+889538700 0 233 0 233
+889538400 0 233 0 233
+889538100 0 233 0 234
+889537800 0 233 0 234
+889537500 0 233 0 234
+889537200 0 233 0 234
+889536900 0 233 0 233
+889536600 0 233 0 233
+889536300 0 233 0 233
+889536000 0 233 0 233
+889535700 0 233 0 239
+889535400 0 239 0 243
+889535100 0 243 0 243
+889534800 0 242 0 243
+889534500 0 240 0 240
+889534200 0 240 0 240
+889533900 0 240 0 241
+889533600 0 241 0 242
+889533300 0 242 0 242
+889533000 0 242 0 243
+889532700 0 243 0 243
+889532400 0 243 0 243
+889532100 0 243 0 243
+889531800 0 243 0 243
+889531500 0 243 0 243
+889531200 0 243 0 243
+889530900 0 243 0 245
+889530600 0 245 0 245
+889530300 0 245 0 245
+889530000 0 245 0 247
+889529700 0 247 0 249
+889529400 0 248 0 249
+889529100 0 248 0 248
+889528800 0 247 0 248
+889528500 0 247 0 247
+889528200 0 247 0 248
+889527900 0 247 0 248
+889527600 0 246 0 247
+889527300 0 245 0 246
+889527000 0 241 0 242
+889526700 0 241 0 241
+889526400 0 241 0 241
+889526100 0 241 0 241
+889525800 0 241 0 241
+889525500 0 241 0 242
+889525200 0 241 0 242
+889524900 0 240 0 241
+889524600 0 241 0 241
+889524300 0 241 0 241
+889524000 0 240 0 241
+889523700 0 238 0 239
+889523400 0 237 0 238
+889523100 0 235 0 236
+889522800 0 232 0 233
+889522500 0 228 0 229
+889522200 0 225 0 226
+889521900 0 222 0 222
+889521600 0 222 0 223
+889521300 0 223 0 223
+889521000 0 223 0 223
+889520700 0 223 0 223
+889520400 0 223 0 223
+889520100 0 223 0 226
+889519800 0 225 0 226
+889519500 0 222 0 222
+889519200 0 221 0 222
+889518900 0 221 0 221
+889518600 0 221 0 221
+889518300 0 221 0 221
+889518000 0 221 0 233
+889517700 0 233 0 235
+889517400 0 235 0 237
+889517100 0 237 0 237
+889516800 0 237 0 237
+889516500 0 237 0 238
+889516200 0 238 0 240
+889515900 0 239 0 240
+889515600 0 234 0 235
+889515300 0 231 0 231
+889515000 0 231 0 231
+889514700 0 231 0 231
+889514400 0 231 0 231
+889514100 0 231 0 231
+889513800 0 231 0 231
+889513500 0 231 0 233
+889513200 0 232 0 233
+889512900 0 231 0 231
+889512600 0 231 0 231
+889512300 0 231 0 231
+889512000 0 231 0 231
+889511700 0 231 0 237
+889511400 0 236 0 237
+889511100 0 232 0 232
+889510800 0 232 0 250
+889510500 0 250 0 250
+889510200 0 250 0 250
+889509900 0 250 0 252
+889509600 0 251 0 252
+889509300 0 250 0 250
+889509000 0 250 0 250
+889508700 0 250 0 250
+889508400 0 250 0 250
+889508100 0 250 0 250
+889507800 0 250 0 250
+889507500 0 249 0 250
+889507200 0 249 0 249
+889506900 0 249 0 251
+889506600 0 250 0 251
+889506300 0 249 0 250
+889506000 0 249 0 250
+889505700 0 249 0 253
+889505400 0 252 0 253
+889505100 0 250 0 252
+889504800 0 251 0 252
+889504500 0 249 0 249
+889504200 0 249 0 249
+889503900 0 249 0 250
+889503600 0 249 0 250
+889503300 0 245 0 245
+889503000 0 244 0 245
+889502700 0 241 0 241
+889502400 0 241 0 241
+889502100 0 241 0 241
+889501800 0 241 0 242
+889501500 0 241 0 242
+889501200 0 241 0 241
+889500900 0 241 0 242
+889500600 0 242 0 244
+889500300 0 244 0 253
+889500000 0 253 0 257
+889499700 0 257 0 260
+889499400 0 260 0 262
+889499100 0 262 0 273
+889498800 0 273 0 274
+889498500 0 274 0 279
+889498200 0 279 0 282
+889497900 0 281 0 282
+889497600 0 278 0 288
+889497300 0 288 0 318
+889497000 0 318 0 318
+889496700 0 317 0 318
+889496400 0 317 0 323
+889496100 0 323 0 325
+889495800 0 325 0 335
+889495500 0 334 0 335
+889495200 0 330 0 340
+889494900 0 340 0 348
+889494600 0 348 0 352
+889494300 0 352 0 353
+889494000 0 353 0 357
+889493700 0 357 0 361
+889493400 0 361 0 363
+889493100 0 363 0 364
+889492800 0 364 0 364
+889492500 0 364 0 369
+889492200 0 369 0 372
+889491900 0 372 0 373
+889491600 0 373 0 373
+889491300 0 373 0 373
+889491000 0 373 0 373
+889490700 0 373 0 373
+889490400 0 373 0 373
+889490100 0 373 0 373
+889489800 0 373 0 376
+889489500 0 375 0 376
+889489200 0 373 0 373
+889488900 0 373 0 374
+889488600 0 374 0 375
+889488300 0 374 0 375
+889488000 0 371 0 374
+889487700 0 374 0 374
+889487400 0 374 0 376
+889487100 0 375 0 376
+889486800 0 373 0 374
+889486500 0 374 0 378
+889486200 0 377 0 378
+889485900 0 375 0 376
+889485600 0 376 0 376
+889485300 0 375 0 376
+889485000 0 373 0 374
+889484700 0 371 0 372
+889484400 0 368 0 369
+889484100 0 365 0 365
+889483800 0 365 0 372
+889483500 0 371 0 372
+889483200 0 366 0 367
+889482900 0 366 0 367
+889482600 0 365 0 366
+889482300 0 364 0 365
+889482000 0 363 0 363
+889481700 0 363 0 369
+889481400 0 368 0 369
+889481100 0 360 0 361
+889480800 0 360 0 361
+889480500 0 358 0 359
+889480200 0 355 0 356
+889479900 0 354 0 355
+889479600 0 350 0 351
+889479300 0 347 0 348
+889479000 0 338 0 340
+889478700 0 339 0 340
+889478400 0 337 0 338
+889478100 0 337 0 338
+889477800 0 332 0 337
+889477500 0 337 0 337
+889477200 0 337 0 339
+889476900 0 339 0 341
+889476600 0 341 0 341
+889476300 0 341 0 341
+889476000 0 341 0 342
+889475700 0 341 0 342
+889475400 0 341 0 341
+889475100 0 341 0 341
+889474800 0 341 0 342
+889474500 0 342 0 342
+889474200 0 342 0 342
+889473900 0 341 0 342
+889473600 0 340 0 341
+889473300 0 339 0 340
+889473000 0 339 0 339
+889472700 0 339 0 339
+889472400 0 339 0 339
+889472100 0 339 0 340
+889471800 0 339 0 340
+889471500 0 339 0 341
+889471200 0 340 0 341
+889470900 0 338 0 339
+889470600 0 337 0 338
+889470300 0 337 0 338
+889470000 0 336 0 337
+889469700 0 334 0 334
+889469400 0 334 0 335
+889469100 0 335 0 335
+889468800 0 335 0 336
+889468500 0 336 0 336
+889468200 0 335 0 336
+889467900 0 335 0 335
+889467600 0 335 0 335
+889467300 0 335 0 337
+889467000 0 337 0 337
+889466700 0 337 0 339
+889466400 0 338 0 339
+889466100 0 338 0 340
+889465800 0 340 0 342
+889465500 0 342 0 343
+889465200 0 343 0 345
+889464900 0 345 0 345
+889464600 0 345 0 345
+889464300 0 345 0 347
+889464000 0 346 0 347
+889463700 0 346 0 347
+889463400 0 346 0 347
+889463100 0 346 0 346
+889462800 0 346 0 348
+889462500 0 347 0 348
+889462200 0 346 0 348
+889461900 0 347 0 348
+889461600 0 342 0 343
+889461300 0 342 0 343
+889461000 0 342 0 345
+889460700 0 344 0 345
+889460400 0 330 0 331
+889460100 0 329 0 331
+889459800 0 331 0 332
+889459500 0 331 0 332
+889459200 0 331 0 332
+889458900 0 331 0 332
+889458600 0 328 0 328
+889458300 0 328 0 328
+889458000 0 328 0 330
+889457700 0 330 0 330
+889457400 0 330 0 331
+889457100 0 330 0 331
+889456800 0 326 0 326
+889456500 0 326 0 329
+889456200 0 328 0 329
+889455900 0 325 0 327
+889455600 0 327 0 330
+889455300 0 329 0 330
+889455000 0 327 0 328
+889454700 0 325 0 326
+889454400 0 323 0 325
+889454100 0 324 0 325
+889453800 0 324 0 325
+889453500 0 324 0 325
+889453200 0 322 0 323
+889452900 0 317 0 318
+889452600 0 317 0 318
+889452300 0 318 0 320
+889452000 0 320 0 320
+889451700 0 319 0 320
+889451400 0 317 0 318
+889451100 0 316 0 317
+889450800 0 315 0 316
+889450500 0 315 0 316
+889450200 0 311 0 312
+889449900 0 308 0 308
+889449600 0 307 0 308
+889449300 0 307 0 307
+889449000 0 307 0 308
+889448700 0 308 0 308
+889448400 0 307 0 308
+889448100 0 296 0 297
+889447800 0 295 0 296
+889447500 0 292 0 292
+889447200 0 292 0 292
+889446900 0 292 0 292
+889446600 0 292 0 293
+889446300 0 293 0 294
+889446000 0 294 0 295
+889445700 0 295 0 295
+889445400 0 294 0 295
+889445100 0 293 0 294
+889444800 0 291 0 292
+889444500 0 290 0 290
+889444200 0 289 0 290
+889443900 0 287 0 289
+889443600 0 225 0 225
+889443300 0 225 0 225
+889443000 0 225 0 225
+889442700 0 225 0 225
+889442400 0 225 0 225
+889442100 0 225 0 225
+889441800 0 225 0 225
+889441500 0 225 0 225
+889441200 0 225 0 225
+889440900 0 225 0 225
+889440600 0 225 0 225
+889440300 0 225 0 225
+889440000 0 225 0 225
+889439700 0 225 0 225
+889439400 0 225 0 225
+889439100 0 225 0 225
+889438800 0 225 0 225
+889438500 0 225 0 225
+889438200 0 225 0 225
+889437900 0 225 0 225
+889437600 0 225 0 225
+889437300 0 225 0 225
+889437000 0 225 0 225
+889436700 0 225 0 225
+889436400 0 225 0 225
+889436100 0 225 0 225
+889435800 0 225 0 225
+889435500 0 225 0 225
+889435200 0 225 0 225
+889434900 0 225 0 225
+889434600 0 225 0 225
+889434300 0 225 0 225
+889434000 0 225 0 225
+889433700 0 225 0 225
+889433400 0 225 0 225
+889433100 0 225 0 225
+889432800 0 225 0 225
+889432500 0 225 0 225
+889432200 0 225 0 225
+889431900 0 225 0 225
+889431600 0 225 0 225
+889431300 0 225 0 225
+889431000 0 225 0 225
+889430700 0 225 0 225
+889430400 0 225 0 225
+889428600 0 225 0 225
+889426800 0 225 0 225
+889425000 0 225 0 225
+889423200 0 225 0 225
+889421400 0 225 0 225
+889419600 0 225 0 225
+889417800 0 225 0 225
+889416000 0 225 0 225
+889414200 0 225 0 225
+889412400 0 225 0 225
+889410600 0 225 0 225
+889408800 0 225 0 225
+889407000 0 225 0 225
+889405200 0 225 0 225
+889403400 0 225 0 225
+889401600 0 225 0 225
+889399800 0 225 0 225
+889398000 0 225 0 225
+889396200 0 225 0 225
+889394400 0 225 0 225
+889392600 0 225 0 225
+889390800 0 225 0 225
+889389000 0 225 0 225
+889387200 0 225 0 225
+889385400 0 225 0 225
+889383600 0 225 0 225
+889381800 0 225 0 225
+889380000 0 225 0 225
+889378200 0 225 0 225
+889376400 0 225 0 225
+889374600 0 225 0 225
+889372800 0 225 0 225
+889371000 0 225 0 225
+889369200 0 225 0 225
+889367400 0 225 0 225
+889365600 0 225 0 225
+889363800 0 225 0 225
+889362000 0 225 0 225
+889360200 0 225 0 225
+889358400 0 225 0 225
+889356600 0 225 0 225
+889354800 0 225 0 225
+889353000 0 225 0 225
+889351200 0 225 0 225
+889349400 0 225 0 225
+889347600 0 225 0 225
+889345800 0 225 0 225
+889344000 0 225 0 225
+889342200 0 225 0 225
+889340400 0 225 0 225
+889338600 0 225 0 225
+889336800 0 225 0 225
+889335000 0 225 0 225
+889333200 0 225 0 225
+889331400 0 225 0 225
+889329600 0 225 0 225
+889327800 0 225 0 225
+889326000 0 225 0 225
+889324200 0 225 0 225
+889322400 0 225 0 225
+889320600 0 225 0 225
+889318800 0 225 0 225
+889317000 0 225 0 225
+889315200 0 225 0 225
+889313400 0 225 0 225
+889311600 0 225 0 225
+889309800 0 225 0 225
+889308000 0 225 0 225
+889306200 0 225 0 225
+889304400 0 225 0 225
+889302600 0 225 0 225
+889300800 0 225 0 225
+889299000 0 225 0 225
+889297200 0 225 0 225
+889295400 0 225 0 225
+889293600 0 225 0 225
+889291800 0 225 0 225
+889290000 0 225 0 225
+889288200 0 225 0 225
+889286400 0 225 0 225
+889284600 0 225 0 225
+889282800 0 225 0 225
+889281000 0 225 0 225
+889279200 0 225 0 225
+889277400 0 225 0 225
+889275600 0 225 0 225
+889273800 0 225 0 225
+889272000 0 225 0 225
+889270200 0 225 0 225
+889268400 0 225 0 225
+889266600 0 225 0 225
+889264800 0 225 0 225
+889263000 0 225 0 225
+889261200 0 225 0 225
+889259400 0 225 0 225
+889257600 0 225 0 225
+889255800 0 225 0 225
+889254000 0 225 0 225
+889252200 0 225 0 225
+889250400 0 225 0 225
+889248600 0 225 0 225
+889246800 0 225 0 225
+889245000 0 225 0 225
+889243200 0 225 0 225
+889241400 0 225 0 225
+889239600 0 225 0 225
+889237800 0 225 0 225
+889236000 0 225 0 225
+889234200 0 225 0 225
+889232400 0 225 0 225
+889230600 0 225 0 225
+889228800 0 225 0 225
+889227000 0 225 0 225
+889225200 0 225 0 225
+889223400 0 225 0 225
+889221600 0 225 0 225
+889219800 0 225 0 225
+889218000 0 225 0 225
+889216200 0 225 0 225
+889214400 0 225 0 225
+889212600 0 225 0 225
+889210800 0 225 0 225
+889209000 0 225 0 225
+889207200 0 225 0 225
+889205400 0 225 0 225
+889203600 0 225 0 225
+889201800 0 225 0 225
+889200000 0 225 0 225
+889198200 0 225 0 225
+889196400 0 225 0 225
+889194600 0 225 0 225
+889192800 0 225 0 225
+889191000 0 225 0 225
+889189200 0 225 0 225
+889187400 0 225 0 225
+889185600 0 225 0 225
+889183800 0 225 0 225
+889182000 0 225 0 225
+889180200 0 225 0 225
+889178400 0 225 0 225
+889176600 0 225 0 225
+889174800 0 225 0 225
+889173000 0 225 0 225
+889171200 0 225 0 225
+889169400 0 225 0 225
+889167600 0 225 0 225
+889165800 0 225 0 225
+889164000 0 225 0 225
+889162200 0 225 0 225
+889160400 0 225 0 225
+889158600 0 225 0 225
+889156800 0 225 0 225
+889155000 0 225 0 225
+889153200 0 225 0 225
+889151400 0 225 0 225
+889149600 0 225 0 225
+889147800 0 225 0 225
+889146000 0 225 0 225
+889144200 0 225 0 225
+889142400 0 225 0 225
+889140600 0 225 0 225
+889138800 0 225 0 225
+889137000 0 225 0 225
+889135200 0 225 0 225
+889133400 0 225 0 225
+889131600 0 225 0 225
+889129800 0 225 0 225
+889128000 0 225 0 225
+889126200 0 225 0 225
+889124400 0 225 0 225
+889122600 0 224 0 225
+889120800 0 223 0 225
+889119000 0 221 0 225
+889117200 0 218 0 220
+889115400 0 213 0 218
+889113600 0 211 0 213
+889111800 0 209 0 210
+889110000 0 209 0 212
+889108200 0 208 0 210
+889106400 0 209 0 209
+889104600 0 209 0 212
+889102800 0 207 0 208
+889101000 0 206 0 208
+889099200 0 207 0 208
+889097400 0 208 0 208
+889095600 0 207 0 208
+889093800 0 207 0 210
+889092000 0 206 0 208
+889090200 0 204 0 205
+889088400 0 200 0 203
+889086600 0 187 0 196
+889084800 0 169 0 174
+889083000 0 166 0 169
+889081200 0 157 0 161
+889079400 0 156 0 159
+889077600 0 154 0 154
+889075800 0 154 0 155
+889074000 0 155 0 156
+889072200 0 154 0 157
+889070400 0 153 0 154
+889068600 0 154 0 156
+889066800 0 154 0 157
+889065000 0 154 0 158
+889063200 0 155 0 158
+889061400 0 154 0 156
+889059600 0 155 0 160
+889057800 0 154 0 159
+889056000 0 156 0 164
+889054200 0 158 0 166
+889052400 0 158 0 166
+889050600 0 154 0 158
+889048800 0 155 0 159
+889047000 0 152 0 154
+889045200 0 152 0 156
+889043400 0 151 0 153
+889041600 0 151 0 155
+889039800 0 150 0 151
+889038000 0 151 0 154
+889036200 0 150 0 152
+889034400 0 151 0 153
+889032600 0 150 0 153
+889030800 0 148 0 149
+889029000 0 148 0 149
+889027200 0 142 0 147
+889025400 0 141 0 141
+889023600 0 141 0 141
+889021800 0 141 0 144
+889020000 0 139 0 144
+889018200 0 134 0 137
+889016400 0 133 0 137
+889014600 0 133 0 134
+889012800 0 133 0 133
+889011000 0 136 0 139
+889009200 0 138 0 140
+889007400 0 139 0 142
+889005600 0 140 0 144
+889003800 0 144 0 144
+889002000 0 143 0 144
+889000200 0 143 0 143
+888998400 0 145 0 146
+888996600 0 144 0 147
+888994800 0 134 0 139
+888993000 0 133 0 138
+888991200 0 134 0 139
+888989400 0 131 0 136
+888987600 0 135 0 137
+888985800 0 135 0 136
+888984000 0 135 0 137
+888982200 0 135 0 135
+888980400 0 135 0 136
+888978600 0 136 0 141
+888976800 0 137 0 141
+888975000 0 133 0 139
+888973200 0 137 0 139
+888971400 0 135 0 138
+888969600 0 137 0 138
+888967800 0 139 0 144
+888966000 0 143 0 152
+888964200 0 156 0 165
+888962400 0 158 0 162
+888960600 0 159 0 164
+888958800 0 165 0 169
+888957000 0 169 0 173
+888955200 0 172 0 173
+888953400 0 176 0 179
+888951600 0 176 0 178
+888949800 0 171 0 177
+888948000 0 176 0 179
+888946200 0 170 0 175
+888944400 0 166 0 168
+888942600 0 159 0 165
+888940800 0 157 0 157
+888939000 0 157 0 160
+888937200 0 160 0 162
+888935400 0 160 0 160
+888933600 0 160 0 160
+888931800 0 160 0 163
+888930000 0 158 0 158
+888928200 0 158 0 158
+888926400 0 158 0 158
+888924600 0 158 0 159
+888922800 0 159 0 160
+888921000 0 160 0 162
+888919200 0 160 0 163
+888917400 0 158 0 161
+888915600 0 160 0 161
+888913800 0 155 0 161
+888912000 0 148 0 154
+888910200 0 145 0 147
+888908400 0 147 0 148
+888906600 0 145 0 149
+888904800 0 138 0 143
+888903000 0 138 0 141
+888901200 0 138 0 140
+888899400 0 138 0 142
+888897600 0 140 0 143
+888895800 0 138 0 141
+888894000 0 134 0 139
+888892200 0 132 0 133
+888890400 0 134 0 141
+888888600 0 141 0 144
+888886800 0 141 0 144
+888885000 0 141 0 149
+888883200 0 143 0 150
+888881400 0 132 0 140
+888879600 0 123 0 131
+888877800 0 116 0 121
+888876000 0 107 0 113
+888874200 0 96 0 104
+888872400 0 83 0 90
+888870600 0 79 0 84
+888868800 0 84 0 85
+888867000 0 84 0 88
+888865200 0 76 0 86
+888863400 0 65 0 69
+888861600 0 62 0 68
+888859800 0 55 0 61
+888858000 0 51 0 71
+888856200 0 74 0 116
+888854400 0 116 0 120
+888852600 0 113 0 117
+888850800 0 107 0 111
+888849000 0 103 0 104
+888847200 0 103 0 103
+888845400 0 103 0 107
+888843600 0 100 0 104
+888841800 0 100 0 102
+888840000 0 101 0 106
+888838200 0 111 0 132
+888836400 0 132 0 133
+888834600 0 132 0 137
+888832800 0 127 0 133
+888831000 0 121 0 125
+888829200 0 123 0 124
+888827400 0 123 0 129
+888825600 0 136 0 148
+888823800 0 143 0 148
+888822000 0 137 0 140
+888820200 0 130 0 134
+888818400 0 130 0 132
+888816600 0 131 0 132
+888814800 0 127 0 132
+888813000 0 114 0 122
+888811200 0 111 0 114
+888809400 0 106 0 110
+888807600 0 102 0 104
+888805800 0 102 0 103
+888804000 0 103 0 104
+888802200 0 99 0 100
+888800400 0 99 0 102
+888798600 0 102 0 106
+888796800 0 98 0 99
+888795000 0 95 0 103
+888793200 0 90 0 92
+888791400 0 90 0 96
+888789600 0 96 0 100
+888787800 0 93 0 95
+888786000 0 93 0 94
+888784200 0 93 0 93
+888782400 0 90 0 93
+888780600 0 87 0 92
+888778800 0 86 0 88
+888777000 0 86 0 87
+888775200 0 86 0 87
+888773400 0 85 0 88
+888771600 0 79 0 82
+888769800 0 79 0 80
+888768000 0 71 0 75
+888766200 0 70 0 71
+888764400 0 69 0 70
+888762600 0 70 0 70
+888760800 0 70 0 72
+888759000 0 70 0 72
+888757200 0 69 0 70
+888755400 0 69 0 70
+888753600 0 69 0 70
+888751800 0 69 0 69
+888750000 0 69 0 69
+888748200 0 69 0 71
+888746400 0 66 0 70
+888744600 0 64 0 65
+888742800 0 63 0 65
+888741000 0 63 0 65
+888739200 0 63 0 64
+888737400 0 62 0 65
+888735600 0 62 0 63
+888733800 0 62 0 63
+888732000 0 63 0 63
+888730200 0 62 0 63
+888728400 0 60 0 62
+888726600 0 60 0 60
+888724800 0 60 0 61
+888723000 0 60 0 61
+888721200 0 60 0 61
+888719400 0 59 0 61
+888717600 0 58 0 59
+888715800 0 59 0 60
+888714000 0 58 0 59
+888712200 0 58 0 59
+888710400 0 57 0 58
+888708600 0 57 0 59
+888706800 0 57 0 58
+888705000 0 57 0 58
+888703200 0 56 0 57
+888701400 0 56 0 57
+888699600 0 57 0 57
+888697800 0 56 0 57
+888696000 0 56 0 57
+888694200 0 57 0 57
+888692400 0 56 0 60
+888690600 0 55 0 56
+888688800 0 55 0 56
+888687000 0 55 0 56
+888685200 0 54 0 56
+888683400 0 54 0 57
+888681600 0 54 0 54
+888679800 0 53 0 54
+888678000 0 53 0 54
+888676200 0 52 0 54
+888674400 0 49 0 52
+888672600 0 48 0 52
+888670800 0 47 0 51
+888669000 0 46 0 47
+888667200 0 45 0 47
+888665400 0 43 0 45
+888663600 0 42 0 42
+888661800 0 42 0 44
+888660000 0 41 0 42
+888658200 0 41 0 41
+888656400 0 41 0 42
+888654600 0 41 0 41
+888652800 0 40 0 41
+888651000 0 40 0 40
+888649200 0 39 0 41
+888647400 0 39 0 40
+888645600 0 38 0 40
+888643800 0 36 0 38
+888642000 0 35 0 37
+888640200 0 34 0 35
+888638400 0 33 0 33
+888636600 0 31 0 33
+888634800 0 29 0 31
+888633000 0 30 0 33
+888631200 0 28 0 31
+888629400 0 28 0 30
+888627600 0 27 0 30
+888625800 0 27 0 30
+888624000 0 27 0 29
+888622200 0 27 0 28
+888620400 0 27 0 35
+888618600 0 28 0 30
+888616800 0 26 0 26
+888615000 0 25 0 27
+888613200 0 24 0 28
+888611400 0 23 0 24
+888609600 0 24 0 26
+888607800 0 26 0 29
+888606000 0 25 0 28
+888604200 0 23 0 26
+888602400 0 23 0 24
+888600600 0 23 0 24
+888598800 0 23 0 23
+888597000 0 23 0 24
+888595200 0 24 0 25
+888593400 0 25 0 25
+888591600 0 24 0 25
+888589800 0 23 0 25
+888588000 0 24 0 28
+888586200 0 27 0 30
+888584400 0 23 0 27
+888582600 0 22 0 23
+888580800 0 23 0 25
+888579000 0 24 0 25
+888577200 0 25 0 27
+888575400 0 24 0 25
+888573600 0 25 0 29
+888571800 0 25 0 27
+888570000 0 24 0 26
+888568200 0 23 0 25
+888566400 0 23 0 28
+888564600 0 28 0 30
+888562800 0 28 0 29
+888561000 0 28 0 29
+888559200 0 28 0 30
+888557400 0 30 0 34
+888555600 0 33 0 36
+888553800 0 32 0 33
+888552000 0 32 0 33
+888550200 0 32 0 33
+888548400 0 32 0 33
+888546600 0 31 0 35
+888544800 0 30 0 34
+888543000 0 28 0 29
+888541200 0 26 0 29
+888539400 0 25 0 30
+888537600 0 21 0 26
+888535800 0 22 0 25
+888534000 0 17 0 22
+888532200 0 21 0 24
+888530400 0 18 0 21
+888528600 0 17 0 20
+888526800 0 16 0 20
+888525000 0 18 0 21
+888523200 0 14 0 16
+888521400 0 14 0 16
+888519600 0 15 0 19
+888517800 0 10 0 12
+888516000 0 11 0 12
+888514200 0 11 0 12
+888512400 0 12 0 15
+888510600 0 13 0 15
+888508800 0 14 0 15
+888507000 0 14 0 15
+888505200 0 14 0 15
+888503400 0 14 0 15
+888501600 0 16 0 20
+888499800 0 19 0 20
+888498000 0 18 0 21
+888496200 0 11 0 14
+888494400 0 9 0 9
+888492600 0 9 0 9
+888490800 0 9 0 9
+888489000 0 9 0 9
+888487200 0 9 0 11
+888485400 0 8 0 10
+888483600 0 9 0 10
+888481800 0 8 0 9
+888480000 0 9 0 11
+888478200 0 10 0 11
+888476400 0 11 0 11
+888474600 0 11 0 12
+888472800 0 11 0 11
+888471000 0 10 0 12
+888469200 0 11 0 12
+888467400 0 10 0 11
+888465600 0 10 0 11
+888463800 0 11 0 13
+888462000 0 10 0 13
+888460200 0 10 0 10
+888458400 0 10 0 11
+888456600 0 10 0 11
+888454800 0 10 0 13
+888453000 0 10 0 11
+888451200 0 10 0 11
+888449400 0 10 0 11
+888447600 0 11 0 14
+888445800 0 9 0 11
+888444000 0 12 0 27
+888442200 0 18 0 22
+888440400 0 12 0 15
+888438600 0 6 0 6
+888436800 0 6 0 8
+888435000 0 6 0 8
+888433200 0 6 0 10
+888431400 0 7 0 9
+888429600 0 7 0 8
+888427800 0 6 0 7
+888426000 0 6 0 7
+888424200 0 7 0 7
+888422400 0 7 0 11
+888420600 0 9 0 10
+888418800 0 10 0 12
+888417000 0 12 0 14
+888415200 0 13 0 15
+888413400 0 10 0 15
+888411600 0 16 0 24
+888409800 0 18 0 21
+888408000 0 15 0 17
+888406200 0 16 0 17
+888404400 0 16 0 18
+888402600 0 17 0 20
+888400800 0 9 0 11
+888399000 0 10 0 11
+888397200 0 10 0 15
+888395400 0 10 0 12
+888393600 0 10 0 13
+888391800 0 5 0 7
+888390000 0 5 0 6
+888388200 0 5 0 6
+888386400 0 5 0 7
+888384600 0 8 0 11
+888382800 0 6 0 7
+888381000 0 6 0 7
+888379200 0 7 0 11
+888377400 0 6 0 6
+888375600 0 6 0 10
+888373800 0 9 0 10
+888372000 0 11 0 27
+888370200 0 26 0 28
+888368400 0 22 0 24
+888366600 0 20 0 21
+888364800 0 20 0 23
+888363000 0 22 0 26
+888361200 0 20 0 25
+888359400 0 21 0 24
+888357600 0 19 0 21
+888355800 0 18 0 18
+888354000 0 18 0 20
+888352200 0 19 0 20
+888350400 0 20 0 26
+888343200 0 18 0 26
+888336000 0 8 0 13
+888328800 0 5 0 9
+888321600 0 10 0 17
+888314400 0 19 0 28
+888307200 0 11 0 25
+888300000 0 2 0 5
+888292800 0 4 0 10
+888285600 0 2 0 8
+888278400 0 1 0 8
+888271200 0 0 0 5
+888264000 0 3 0 8
+888256800 0 55 0 81
+888249600 0 66 0 81
+888242400 0 51 0 64
+888235200 0 39 0 43
+888228000 0 38 0 42
+888220800 0 38 0 42
+888213600 0 35 0 39
+888206400 0 29 0 36
+888199200 0 24 0 29
+888192000 0 20 0 25
+888184800 0 14 0 22
+888177600 0 8 0 11
+888170400 0 10 0 14
+888163200 0 11 0 14
+888156000 0 7 0 13
+888148800 0 5 0 13
+888141600 0 6 0 9
+888134400 0 5 0 8
+888127200 0 5 0 9
+888120000 0 5 0 6
+888112800 0 4 0 7
+888105600 0 5 0 9
+888098400 0 13 0 252
+888091200 0 24 0 106
+888084000 0 1 0 2
+888076800 0 0 0 1
+888069600 0 0 0 5
+888062400 0 0 0 3
+888055200 0 1 0 4
+888048000 0 4 0 7
+888040800 0 5 0 8
+888033600 0 4 0 6
+888026400 0 3 0 8
+888019200 0 2 0 4
+888012000 0 4 0 9
+888004800 0 3 0 9
+887997600 0 5 0 10
+887990400 0 5 0 12
+887983200 0 7 0 14
+887976000 0 6 0 11
+887968800 0 6 0 10
+887961600 0 3 0 10
+887954400 0 2 0 5
+887947200 0 2 0 6
+887940000 0 1 0 4
+887932800 0 2 0 23
+887925600 0 18 0 25
+887918400 0 13 0 16
+887911200 0 14 0 18
+887904000 0 15 0 20
+887896800 0 17 0 21
+887889600 0 21 0 28
+887882400 0 22 0 36
+887875200 0 17 0 25
+887868000 0 17 0 21
+887860800 0 19 0 26
+887853600 0 18 0 24
+887846400 0 19 0 26
+887839200 0 27 0 42
+887832000 0 34 0 40
+887824800 0 29 0 36
+887817600 0 18 0 25
+887810400 0 21 0 27
+887803200 0 19 0 27
+887796000 0 12 0 16
+887788800 0 9 0 11
+887781600 0 8 0 13
+887774400 0 14 0 23
+887767200 0 21 0 26
+887760000 0 25 0 32
+887752800 0 27 0 35
+887745600 0 18 0 24
+887738400 0 17 0 52
+887731200 0 57 0 64
+887724000 0 52 0 60
+887716800 0 49 0 55
+887709600 0 49 0 51
+887702400 0 45 0 50
+887695200 0 43 0 44
+887688000 0 37 0 42
+887680800 0 38 0 45
+887673600 0 35 0 74
+887666400 0 82 0 90
+887659200 0 80 0 113
+887652000 0 146 0 151
+887644800 0 133 0 138
+887637600 0 134 0 138
+887630400 0 125 0 134
+887623200 0 114 0 120
+887616000 0 110 0 113
+887608800 0 103 0 107
+887601600 0 95 0 104
+887594400 0 73 0 82
+887587200 0 60 0 71
+887580000 0 38 0 47
+887572800 0 30 0 33
+887565600 0 27 0 28
+887558400 0 25 0 28
+887551200 0 22 0 26
+887544000 0 16 0 23
+887536800 0 13 0 18
+887529600 0 7 0 19
+887522400 0 3 0 5
+887515200 0 3 0 6
+887508000 0 3 0 3
+887500800 0 3 0 6
+887493600 0 3 0 5
+887486400 0 3 0 6
+887479200 0 5 0 11
+887472000 0 8 0 12
+887464800 0 11 0 13
+887457600 0 11 0 18
+887450400 0 12 0 14
+887443200 0 12 0 13
+887436000 0 12 0 18
+887428800 0 10 0 11
+887421600 0 10 0 13
+887414400 0 10 0 12
+887407200 0 10 0 18
+887400000 0 11 0 16
+887392800 0 9 0 14
+887385600 0 9 0 12
+887378400 0 12 0 14
+887371200 0 12 0 16
+887364000 0 13 0 15
+887356800 0 14 0 18
+887349600 0 12 0 16
+887342400 0 12 0 13
+887335200 0 12 0 16
+887328000 0 12 0 13
+887320800 0 12 0 18
+887313600 0 12 0 18
+887306400 0 12 0 17
+887299200 0 13 0 17
+887292000 0 13 0 18
+887284800 0 13 0 17
+887277600 0 13 0 16
+887270400 0 12 0 15
+887263200 0 13 0 15
+887256000 0 13 0 21
+887248800 0 14 0 19
+887241600 0 19 0 25
+887234400 0 26 0 36
+887227200 0 37 0 45
+887220000 0 38 0 53
+887212800 0 50 0 56
+887205600 0 49 0 57
+887198400 0 33 0 39
+887191200 0 34 0 47
+887184000 0 46 0 51
+887176800 0 49 0 57
+887169600 0 51 0 56
+887162400 0 57 0 79
+887155200 0 66 0 80
+887148000 0 71 0 85
+887140800 0 78 0 86
+887133600 0 64 0 72
+887126400 0 62 0 69
+887119200 0 70 0 78
+887112000 0 79 0 89
+887104800 0 80 0 88
+887097600 0 77 0 85
+887090400 0 83 0 87
+887083200 0 82 0 83
+887076000 0 82 0 83
+887068800 0 82 0 85
+887061600 0 82 0 85
+887054400 0 86 0 96
+887047200 0 109 0 133
+887040000 0 123 0 128
+887032800 0 113 0 118
+887025600 0 112 0 118
+887018400 0 111 0 114
+887011200 0 111 0 112
+887004000 0 111 0 112
+886996800 0 112 0 113
+886989600 0 109 0 112
+886982400 0 106 0 110
+886975200 0 95 0 109
+886968000 0 87 0 89
+886960800 0 88 0 95
+886953600 0 95 0 97
+886946400 0 93 0 99
+886939200 0 97 0 103
+886932000 0 96 0 98
+886924800 0 96 0 101
+886917600 0 100 0 102
+886910400 0 97 0 101
+886903200 0 96 0 98
+886896000 0 96 0 100
+886888800 0 97 0 106
+886881600 0 106 0 110
+886874400 0 111 0 118
+886867200 0 117 0 119
+886860000 0 119 0 122
+886852800 0 122 0 129
+886845600 0 125 0 127
+886838400 0 128 0 131
+886831200 0 132 0 135
+886824000 0 135 0 136
+886816800 0 136 0 139
+886809600 0 133 0 144
+886802400 0 122 0 133
+886795200 0 115 0 129
+886788000 0 122 0 128
+886780800 0 114 0 118
+886773600 0 117 0 123
+886766400 0 122 0 128
+886759200 0 126 0 133
+886752000 0 115 0 128
+886744800 0 107 0 111
+886737600 0 103 0 112
+886730400 0 93 0 98
+886723200 0 96 0 122
+886716000 0 103 0 114
+886708800 0 85 0 90
+886701600 0 86 0 91
+886694400 0 85 0 91
+886687200 0 79 0 86
+886680000 0 78 0 86
+886672800 0 79 0 86
+886665600 0 81 0 87
+886658400 0 75 0 79
+886651200 0 76 0 84
+886644000 0 83 0 87
+886636800 0 83 0 86
+886629600 0 85 0 92
+886622400 0 90 0 98
+886615200 0 91 0 98
+886608000 0 96 0 102
+886600800 0 101 0 102
+886593600 0 101 0 106
+886586400 0 101 0 105
+886579200 0 101 0 110
+886572000 0 104 0 111
+886564800 0 102 0 106
+886557600 0 101 0 103
+886550400 0 103 0 110
+886543200 0 105 0 107
+886536000 0 107 0 121
+886528800 0 148 0 177
+886521600 0 138 0 144
+886514400 0 139 0 146
+886507200 0 126 0 137
+886500000 0 121 0 126
+886492800 0 122 0 128
+886485600 0 115 0 123
+886478400 0 109 0 112
+886471200 0 100 0 107
+886464000 0 89 0 98
+886456800 0 77 0 83
+886449600 0 79 0 89
+886442400 0 78 0 92
+886435200 0 76 0 89
+886428000 0 85 0 91
+886420800 0 79 0 86
+886413600 0 82 0 89
+886406400 0 91 0 96
+886399200 0 93 0 101
+886392000 0 89 0 92
+886384800 0 90 0 94
+886377600 0 93 0 97
+886370400 0 91 0 100
+886363200 0 94 0 103
+886356000 0 101 0 104
+886348800 0 103 0 108
+886341600 0 105 0 108
+886334400 0 104 0 108
+886327200 0 104 0 106
+886320000 0 105 0 109
+886312800 0 109 0 111
+886305600 0 111 0 113
+886298400 0 108 0 115
+886291200 0 102 0 103
+886284000 0 102 0 118
+886276800 0 115 0 118
+886269600 0 116 0 118
+886262400 0 116 0 119
+886255200 0 115 0 116
+886248000 0 112 0 119
+886240800 0 102 0 108
+886233600 0 104 0 104
+886226400 0 104 0 110
+886219200 0 104 0 116
+886212000 0 111 0 120
+886204800 0 120 0 120
+886197600 0 120 0 120
+886190400 0 120 0 120
+886183200 0 120 0 120
+886176000 0 120 0 120
+886168800 0 120 0 120
+886161600 0 120 0 120
+886154400 0 120 0 120
+886147200 0 120 0 120
+886140000 0 120 0 120
+886132800 0 120 0 120
+886125600 0 120 0 120
+886118400 0 120 0 120
+886111200 0 120 0 120
+886104000 0 120 0 120
+886096800 0 120 0 120
+886089600 0 120 0 120
+886082400 0 120 0 120
+886075200 0 120 0 120
+886068000 0 120 0 120
+886060800 0 120 0 120
+886053600 0 121 0 126
+886046400 0 123 0 126
+886039200 0 126 0 136
+886032000 0 130 0 135
+886024800 0 130 0 143
+886017600 0 113 0 121
+886010400 0 101 0 106
+886003200 0 88 0 99
+885996000 0 80 0 83
+885988800 0 81 0 86
+885981600 0 88 0 100
+885974400 0 77 0 88
+885967200 0 75 0 77
+885960000 0 75 0 79
+885952800 0 74 0 79
+885945600 0 71 0 77
+885938400 0 68 0 79
+885931200 0 59 0 67
+885924000 0 53 0 62
+885916800 0 48 0 56
+885909600 0 41 0 48
+885902400 0 44 0 50
+885895200 0 34 0 37
+885888000 0 32 0 40
+885880800 0 21 0 26
+885873600 0 21 0 25
+885866400 0 21 0 25
+885859200 0 21 0 25
+885852000 0 21 0 27
+885844800 0 19 0 32
+885837600 0 13 0 24
+885830400 0 10 0 13
+885823200 0 11 0 12
+885816000 0 10 0 13
+885808800 0 11 0 17
+885801600 0 8 0 9
+885794400 0 10 0 11
+885787200 0 10 0 11
+885780000 0 10 0 10
+885772800 0 10 0 12
+885765600 0 10 0 11
+885758400 0 10 0 10
+885751200 0 10 0 11
+885744000 0 11 0 14
+885736800 0 12 0 17
+885729600 0 10 0 14
+885722400 0 10 0 14
+885715200 0 12 0 14
+885708000 0 12 0 12
+885700800 0 12 0 12
+885693600 0 12 0 13
+885686400 0 12 0 12
+885679200 0 12 0 13
+885672000 0 12 0 14
+885664800 0 12 0 22
+885657600 0 22 0 26
+885650400 0 22 0 30
+885643200 0 13 0 19
+885636000 0 12 0 14
+885628800 0 12 0 14
+885621600 0 14 0 18
+885614400 0 14 0 14
+885607200 0 14 0 15
+885600000 0 16 0 25
+885592800 0 21 0 23
+885585600 0 24 0 29
+885578400 0 26 0 27
+885571200 0 26 0 28
+885564000 0 28 0 30
+885556800 0 27 0 33
+885549600 0 23 0 31
+885542400 0 20 0 21
+885535200 0 20 0 22
+885528000 0 21 0 23
+885520800 0 20 0 21
+885513600 0 20 0 23
+885506400 0 19 0 23
+885499200 0 19 0 21
+885492000 0 20 0 25
+885484800 0 20 0 22
+885477600 0 22 0 35
+885470400 0 20 0 24
+885463200 0 20 0 22
+885456000 0 17 0 20
+885448800 0 16 0 17
+885441600 0 16 0 19
+885434400 0 16 0 21
+885427200 0 16 0 19
+885420000 0 16 0 18
+885412800 0 16 0 17
+885405600 0 16 0 19
+885398400 0 16 0 21
+885391200 0 22 0 25
+885384000 0 25 0 32
+885376800 0 22 0 27
+885369600 0 20 0 23
+885362400 0 20 0 28
+885355200 0 19 0 21
+885348000 0 39 0 116
+885340800 0 113 0 117
+885333600 0 103 0 108
+885326400 0 87 0 101
+885319200 0 64 0 75
+885312000 0 54 0 63
+885304800 0 47 0 50
+885297600 0 41 0 48
+885290400 0 36 0 43
+885283200 0 30 0 33
+885276000 0 22 0 26
+885268800 0 20 0 23
+885261600 0 22 0 23
+885254400 0 22 0 25
+885247200 0 23 0 24
+885240000 0 23 0 26
+885232800 0 28 0 39
+885225600 0 39 0 41
+885218400 0 39 0 43
+885211200 0 42 0 51
+885204000 0 42 0 44
+885196800 0 44 0 47
+885189600 0 40 0 44
+885182400 0 37 0 40
+885175200 0 35 0 37
+885168000 0 34 0 37
+885160800 0 34 0 36
+885153600 0 34 0 35
+885146400 0 33 0 36
+885139200 0 37 0 40
+885132000 0 34 0 39
+885124800 0 37 0 41
+885117600 0 40 0 42
+885110400 0 40 0 42
+885103200 0 43 0 47
+885096000 0 46 0 47
+885088800 0 46 0 49
+885081600 0 46 0 47
+885074400 0 46 0 50
+885067200 0 50 0 54
+885060000 0 52 0 55
+885052800 0 54 0 55
+885045600 0 54 0 59
+885038400 0 54 0 57
+885031200 0 56 0 62
+885024000 0 57 0 66
+885016800 0 59 0 70
+885009600 0 58 0 59
+885002400 0 58 0 64
+884995200 0 60 0 65
+884988000 0 63 0 67
+884980800 0 66 0 69
+884973600 0 68 0 102
+884966400 0 101 0 107
+884959200 0 98 0 106
+884952000 0 96 0 100
+884944800 0 100 0 104
+884937600 0 99 0 107
+884930400 0 95 0 97
+884923200 0 95 0 97
+884916000 0 102 0 110
+884908800 0 107 0 110
+884901600 0 107 0 112
+884894400 0 109 0 114
+884887200 0 108 0 114
+884880000 0 105 0 109
+884872800 0 107 0 111
+884865600 0 107 0 111
+884858400 0 109 0 113
+884851200 0 112 0 114
+884844000 0 111 0 117
+884836800 0 105 0 106
+884829600 0 105 0 108
+884822400 0 105 0 109
+884815200 0 105 0 110
+884808000 0 107 0 110
+884800800 0 104 0 112
+884793600 0 100 0 104
+884786400 0 99 0 104
+884779200 0 90 0 95
+884772000 0 90 0 94
+884764800 0 88 0 95
+884757600 0 87 0 88
+884750400 0 87 0 89
+884743200 0 87 0 90
+884736000 0 88 0 91
+884728800 0 90 0 98
+884721600 0 91 0 96
+884714400 0 85 0 94
+884707200 0 84 0 90
+884700000 0 78 0 87
+884692800 0 65 0 70
+884685600 0 60 0 65
+884678400 0 59 0 62
+884671200 0 54 0 63
+884664000 0 50 0 51
+884656800 0 50 0 52
+884649600 0 50 0 53
+884642400 0 51 0 58
+884635200 0 47 0 53
+884628000 0 42 0 49
+884620800 0 44 0 55
+884613600 0 54 0 56
+884606400 0 52 0 60
+884599200 0 49 0 53
+884592000 0 60 0 63
+884584800 0 59 0 68
+884577600 0 56 0 57
+884570400 0 56 0 63
+884563200 0 55 0 66
+884556000 0 56 0 69
+884548800 0 51 0 54
+884541600 0 55 0 57
+884534400 0 54 0 61
+884527200 0 47 0 56
+884520000 0 45 0 49
+884512800 0 46 0 51
+884505600 0 48 0 50
+884498400 0 42 0 47
+884491200 0 42 0 43
+884484000 0 42 0 43
+884476800 0 43 0 46
+884469600 0 45 0 50
+884462400 0 50 0 55
+884455200 0 46 0 54
+884448000 0 43 0 49
+884440800 0 36 0 38
+884433600 0 35 0 40
+884426400 0 35 0 37
+884419200 0 34 0 35
+884412000 0 34 0 35
+884404800 0 35 0 36
+884397600 0 35 0 40
+884390400 0 35 0 40
+884383200 0 36 0 41
+884376000 0 38 0 39
+884368800 0 37 0 41
+884361600 0 37 0 39
+884354400 0 40 0 72
+884347200 0 37 0 42
+884340000 0 38 0 41
+884332800 0 38 0 39
+884325600 0 38 0 39
+884318400 0 38 0 39
+884311200 0 38 0 43
+884304000 0 36 0 41
+884296800 0 36 0 42
+884289600 0 40 0 45
+884282400 0 41 0 47
+884275200 0 42 0 45
+884268000 0 43 0 51
+884260800 0 53 0 69
+884253600 0 69 0 77
+884246400 0 68 0 76
+884239200 0 65 0 66
+884232000 0 65 0 69
+884224800 0 83 0 121
+884217600 0 116 0 121
+884210400 0 110 0 113
+884203200 0 108 0 114
+884196000 0 104 0 108
+884188800 0 100 0 109
+884181600 0 94 0 97
+884174400 0 93 0 97
+884167200 0 93 0 96
+884160000 0 90 0 93
+884152800 0 89 0 91
+884145600 0 89 0 91
+884138400 0 90 0 92
+884131200 0 93 0 103
+884124000 0 88 0 94
+884116800 0 64 0 73
+884109600 0 56 0 62
+884102400 0 52 0 56
+884095200 0 51 0 69
+884088000 0 70 0 76
+884080800 0 59 0 65
+884073600 0 59 0 103
+884066400 0 111 0 137
+884059200 0 121 0 166
+884052000 0 92 0 97
+884044800 0 78 0 113
+884037600 0 60 0 65
+884030400 0 63 0 77
+883958400 0 48 0 70
+883872000 0 21 0 45
+883785600 0 23 0 32
+883699200 0 16 0 27
+883612800 0 11 0 19
+883526400 0 8 0 25
+883440000 0 10 0 25
+883353600 0 16 0 47
+883267200 0 22 0 24
+883180800 0 20 0 28
+883094400 0 26 0 98
+883008000 0 30 0 38
+882921600 0 27 0 35
+882835200 0 28 0 69
+882748800 0 52 0 271
+882662400 0 36 0 103
+882576000 0 73 0 80
+882489600 0 65 0 73
+882403200 0 45 0 59
+882316800 0 45 0 66
+882230400 0 50 0 64
+882144000 0 52 0 66
+882057600 0 46 0 61
+881971200 0 51 0 66
+881884800 0 58 0 74
+881798400 0 47 0 70
+881712000 0 38 0 63
+881625600 0 45 0 76
+881539200 0 54 0 90
+881452800 0 82 0 101
+881366400 0 74 0 131
+881280000 0 90 0 151
+881193600 0 73 0 98
+881107200 0 79 0 92
+881020800 0 24 0 42
+880934400 0 33 0 49
+880848000 0 45 0 55
+880761600 0 45 0 56
+880675200 0 47 0 84
+880588800 0 55 0 134
+880502400 0 54 0 67
+880416000 0 51 0 67
+880329600 0 48 0 61
+880243200 0 25 0 32
+880156800 0 23 0 33
+880070400 0 34 0 87
+879984000 0 47 0 60
+879897600 0 19 0 36
+879811200 0 28 0 57
+879724800 0 16 0 56
+879638400 0 0 0 0
+879552000 0 0 0 0
+879465600 0 0 0 0
+879379200 0 0 0 0
+879292800 0 0 0 0
+879206400 0 0 0 0
+879120000 0 0 0 0
+879033600 0 0 0 0
+878947200 0 0 0 0
+878860800 0 0 0 0
+878774400 0 0 0 0
+878688000 0 0 0 0
+878601600 0 0 0 0
+878515200 0 0 0 0
+878428800 0 0 0 0
+878342400 0 0 0 0
+878256000 0 0 0 0
+878169600 0 0 0 0
+878083200 0 0 0 0
+877996800 0 0 0 0
+877910400 0 0 0 0
+877824000 0 0 0 0
+877737600 0 0 0 0
+877651200 0 0 0 0
+877564800 0 0 0 0
+877478400 0 0 0 0
+877392000 0 0 0 0
+877305600 0 0 0 0
+877219200 0 0 0 0
+877132800 0 0 0 0
+877046400 0 0 0 0
+876960000 0 0 0 0
+876873600 0 0 0 0
+876787200 0 0 0 0
+876700800 0 0 0 0
+876614400 0 0 0 0
+876528000 0 0 0 0
+876441600 0 0 0 0
+876355200 0 0 0 0
+876268800 0 0 0 0
+876182400 0 0 0 0
+876096000 0 0 0 0
+876009600 0 0 0 0
+875923200 0 0 0 0
+875836800 0 0 0 0
+875750400 0 0 0 0
+875664000 0 0 0 0
+875577600 0 0 0 0
+875491200 0 0 0 0
+875404800 0 0 0 0
+875318400 0 0 0 0
+875232000 0 0 0 0
+875145600 0 0 0 0
+875059200 0 0 0 0
+874972800 0 0 0 0
+874886400 0 0 0 0
+874800000 0 0 0 0
+874713600 0 0 0 0
+874627200 0 0 0 0
+874540800 0 0 0 0
+874454400 0 0 0 0
+874368000 0 0 0 0
+874281600 0 0 0 0
+874195200 0 0 0 0
+874108800 0 0 0 0
+874022400 0 0 0 0
+873936000 0 0 0 0
+873849600 0 0 0 0
+873763200 0 0 0 0
+873676800 0 0 0 0
+873590400 0 0 0 0
+873504000 0 0 0 0
+873417600 0 0 0 0
+873331200 0 0 0 0
+873244800 0 0 0 0
+873158400 0 0 0 0
+873072000 0 0 0 0
+872985600 0 0 0 0
+872899200 0 0 0 0
+872812800 0 0 0 0
+872726400 0 0 0 0
+872640000 0 0 0 0
+872553600 0 0 0 0
+872467200 0 0 0 0
+872380800 0 0 0 0
+872294400 0 0 0 0
+872208000 0 0 0 0
+872121600 0 0 0 0
+872035200 0 0 0 0
+871948800 0 0 0 0
+871862400 0 0 0 0
+871776000 0 0 0 0
+871689600 0 0 0 0
+871603200 0 0 0 0
+871516800 0 0 0 0
+871430400 0 0 0 0
+871344000 0 0 0 0
+871257600 0 0 0 0
+871171200 0 0 0 0
+871084800 0 0 0 0
+870998400 0 0 0 0
+870912000 0 0 0 0
+870825600 0 0 0 0
+870739200 0 0 0 0
+870652800 0 0 0 0
+870566400 0 0 0 0
+870480000 0 0 0 0
+870393600 0 0 0 0
+870307200 0 0 0 0
+870220800 0 0 0 0
+870134400 0 0 0 0
+870048000 0 0 0 0
+869961600 0 0 0 0
+869875200 0 0 0 0
+869788800 0 0 0 0
+869702400 0 0 0 0
+869616000 0 0 0 0
+869529600 0 0 0 0
+869443200 0 0 0 0
+869356800 0 0 0 0
+869270400 0 0 0 0
+869184000 0 0 0 0
+869097600 0 0 0 0
+869011200 0 0 0 0
+868924800 0 0 0 0
+868838400 0 0 0 0
+868752000 0 0 0 0
+868665600 0 0 0 0
+868579200 0 0 0 0
+868492800 0 0 0 0
+868406400 0 0 0 0
+868320000 0 0 0 0
+868233600 0 0 0 0
+868147200 0 0 0 0
+868060800 0 0 0 0
+867974400 0 0 0 0
+867888000 0 0 0 0
+867801600 0 0 0 0
+867715200 0 0 0 0
+867628800 0 0 0 0
+867542400 0 0 0 0
+867456000 0 0 0 0
+867369600 0 0 0 0
+867283200 0 0 0 0
+867196800 0 0 0 0
+867110400 0 0 0 0
+867024000 0 0 0 0
+866937600 0 0 0 0
+866851200 0 0 0 0
+866764800 0 0 0 0
+866678400 0 0 0 0
+866592000 0 0 0 0
+866505600 0 0 0 0
+866419200 0 0 0 0
+866332800 0 0 0 0
+866246400 0 0 0 0
+866160000 0 0 0 0
+866073600 0 0 0 0
+865987200 0 0 0 0
+865900800 0 0 0 0
+865814400 0 0 0 0
+865728000 0 0 0 0
+865641600 0 0 0 0
+865555200 0 0 0 0
+865468800 0 0 0 0
+865382400 0 0 0 0
+865296000 0 0 0 0
+865209600 0 0 0 0
+865123200 0 0 0 0
+865036800 0 0 0 0
+864950400 0 0 0 0
+864864000 0 0 0 0
+864777600 0 0 0 0
+864691200 0 0 0 0
+864604800 0 0 0 0
+864518400 0 0 0 0
+864432000 0 0 0 0
+864345600 0 0 0 0
+864259200 0 0 0 0
+864172800 0 0 0 0
+864086400 0 0 0 0
+864000000 0 0 0 0
+863913600 0 0 0 0
+863827200 0 0 0 0
+863740800 0 0 0 0
+863654400 0 0 0 0
+863568000 0 0 0 0
+863481600 0 0 0 0
+863395200 0 0 0 0
+863308800 0 0 0 0
+863222400 0 0 0 0
+863136000 0 0 0 0
+863049600 0 0 0 0
+862963200 0 0 0 0
+862876800 0 0 0 0
+862790400 0 0 0 0
+862704000 0 0 0 0
+862617600 0 0 0 0
+862531200 0 0 0 0
+862444800 0 0 0 0
+862358400 0 0 0 0
+862272000 0 0 0 0
+862185600 0 0 0 0
+862099200 0 0 0 0
+862012800 0 0 0 0
+861926400 0 0 0 0
+861840000 0 0 0 0
+861753600 0 0 0 0
+861667200 0 0 0 0
+861580800 0 0 0 0
+861494400 0 0 0 0
+861408000 0 0 0 0
+861321600 0 0 0 0
+861235200 0 0 0 0
+861148800 0 0 0 0
+861062400 0 0 0 0
+860976000 0 0 0 0
+860889600 0 0 0 0
+860803200 0 0 0 0
+860716800 0 0 0 0
+860630400 0 0 0 0
+860544000 0 0 0 0
+860457600 0 0 0 0
+860371200 0 0 0 0
+860284800 0 0 0 0
+860198400 0 0 0 0
+860112000 0 0 0 0
+860025600 0 0 0 0
+859939200 0 0 0 0
+859852800 0 0 0 0
+859766400 0 0 0 0
+859680000 0 0 0 0
+859593600 0 0 0 0
+859507200 0 0 0 0
+859420800 0 0 0 0
+859334400 0 0 0 0
+859248000 0 0 0 0
+859161600 0 0 0 0
+859075200 0 0 0 0
+858988800 0 0 0 0
+858902400 0 0 0 0
+858816000 0 0 0 0
+858729600 0 0 0 0
+858643200 0 0 0 0
+858556800 0 0 0 0
+858470400 0 0 0 0
+858384000 0 0 0 0
+858297600 0 0 0 0
+858211200 0 0 0 0
+858124800 0 0 0 0
+858038400 0 0 0 0
+857952000 0 0 0 0
+857865600 0 0 0 0
+857779200 0 0 0 0
+857692800 0 0 0 0
+857606400 0 0 0 0
+857520000 0 0 0 0
+857433600 0 0 0 0
+857347200 0 0 0 0
+857260800 0 0 0 0
+857174400 0 0 0 0
+857088000 0 0 0 0
+857001600 0 0 0 0
+856915200 0 0 0 0
+856828800 0 0 0 0
+856742400 0 0 0 0
+856656000 0 0 0 0
+856569600 0 0 0 0
+856483200 0 0 0 0
+856396800 0 0 0 0
+856310400 0 0 0 0
+856224000 0 0 0 0
+856137600 0 0 0 0
+856051200 0 0 0 0
+855964800 0 0 0 0
+855878400 0 0 0 0
+855792000 0 0 0 0
+855705600 0 0 0 0
+855619200 0 0 0 0
+855532800 0 0 0 0
+855446400 0 0 0 0
+855360000 0 0 0 0
+855273600 0 0 0 0
+855187200 0 0 0 0
+855100800 0 0 0 0
+855014400 0 0 0 0
+854928000 0 0 0 0
+854841600 0 0 0 0
+854755200 0 0 0 0
+854668800 0 0 0 0
+854582400 0 0 0 0
+854496000 0 0 0 0
+854409600 0 0 0 0
+854323200 0 0 0 0
+854236800 0 0 0 0
+854150400 0 0 0 0
+854064000 0 0 0 0
+853977600 0 0 0 0
+853891200 0 0 0 0
+853804800 0 0 0 0
+853718400 0 0 0 0
+853632000 0 0 0 0
+853545600 0 0 0 0
+853459200 0 0 0 0
+853372800 0 0 0 0
+853286400 0 0 0 0
+853200000 0 0 0 0
+853113600 0 0 0 0
+853027200 0 0 0 0
+852940800 0 0 0 0
+852854400 0 0 0 0
+852768000 0 0 0 0
+852681600 0 0 0 0
+852595200 0 0 0 0
+852508800 0 0 0 0
+852422400 0 0 0 0
+852336000 0 0 0 0
+852249600 0 0 0 0
+852163200 0 0 0 0
+852076800 0 0 0 0
+851990400 0 0 0 0
+851904000 0 0 0 0
+851817600 0 0 0 0
+851731200 0 0 0 0
+851644800 0 0 0 0
+851558400 0 0 0 0
+851472000 0 0 0 0
+851385600 0 0 0 0
+851299200 0 0 0 0
+851212800 0 0 0 0
+851126400 0 0 0 0
+851040000 0 0 0 0
+850953600 0 0 0 0
+850867200 0 0 0 0
+850780800 0 0 0 0
+850694400 0 0 0 0
+850608000 0 0 0 0
+850521600 0 0 0 0
+850435200 0 0 0 0
+850348800 0 0 0 0
+850262400 0 0 0 0
+850176000 0 0 0 0
+850089600 0 0 0 0
+850003200 0 0 0 0
+849916800 0 0 0 0
+849830400 0 0 0 0
+849744000 0 0 0 0
+849657600 0 0 0 0
+849571200 0 0 0 0
+849484800 0 0 0 0
+849398400 0 0 0 0
+849312000 0 0 0 0
+849225600 0 0 0 0
+849139200 0 0 0 0
+849052800 0 0 0 0
+848966400 0 0 0 0
+848880000 0 0 0 0
+848793600 0 0 0 0
+848707200 0 0 0 0
+848620800 0 0 0 0
+848534400 0 0 0 0
+848448000 0 0 0 0
+848361600 0 0 0 0
+848275200 0 0 0 0
+848188800 0 0 0 0
+848102400 0 0 0 0
+848016000 0 0 0 0
+847929600 0 0 0 0
+847843200 0 0 0 0
+847756800 0 0 0 0
+847670400 0 0 0 0
+847584000 0 0 0 0
+847497600 0 0 0 0
+847411200 0 0 0 0
+847324800 0 0 0 0
+847238400 0 0 0 0
+847152000 0 0 0 0
+847065600 0 0 0 0
+846979200 0 0 0 0
+846892800 0 0 0 0
+846806400 0 0 0 0
+846720000 0 0 0 0
+846633600 0 0 0 0
+846547200 0 0 0 0
+846460800 0 0 0 0
+846374400 0 0 0 0
+846288000 0 0 0 0
+846201600 0 0 0 0
+846115200 0 0 0 0
+846028800 0 0 0 0
+845942400 0 0 0 0
+845856000 0 0 0 0
+845769600 0 0 0 0
+845683200 0 0 0 0
+845596800 0 0 0 0
+845510400 0 0 0 0
+845424000 0 0 0 0
+845337600 0 0 0 0
+845251200 0 0 0 0
+845164800 0 0 0 0
+845078400 0 0 0 0
+844992000 0 0 0 0
+844905600 0 0 0 0
+844819200 0 0 0 0
+844732800 0 0 0 0
+844646400 0 0 0 0
+844560000 0 0 0 0
+844473600 0 0 0 0
+844387200 0 0 0 0
+844300800 0 0 0 0
+844214400 0 0 0 0
+844128000 0 0 0 0
+844041600 0 0 0 0
+843955200 0 0 0 0
+843868800 0 0 0 0
+843782400 0 0 0 0
+843696000 0 0 0 0
+843609600 0 0 0 0
+843523200 0 0 0 0
+843436800 0 0 0 0
+843350400 0 0 0 0
+843264000 0 0 0 0
+843177600 0 0 0 0
+843091200 0 0 0 0
+843004800 0 0 0 0
+842918400 0 0 0 0
+842832000 0 0 0 0
+842745600 0 0 0 0
+842659200 0 0 0 0
+842572800 0 0 0 0
+842486400 0 0 0 0
+842400000 0 0 0 0
+842313600 0 0 0 0
+842227200 0 0 0 0
+842140800 0 0 0 0
+842054400 0 0 0 0
+841968000 0 0 0 0
+841881600 0 0 0 0
+841795200 0 0 0 0
+841708800 0 0 0 0
+841622400 0 0 0 0
+841536000 0 0 0 0
+841449600 0 0 0 0
+841363200 0 0 0 0
+841276800 0 0 0 0
+841190400 0 0 0 0
+841104000 0 0 0 0
+841017600 0 0 0 0
+840931200 0 0 0 0
+840844800 0 0 0 0
+840758400 0 0 0 0
+840672000 0 0 0 0
+840585600 0 0 0 0
+840499200 0 0 0 0
+840412800 0 0 0 0
+840326400 0 0 0 0
+840240000 0 0 0 0
+840153600 0 0 0 0
+840067200 0 0 0 0
+839980800 0 0 0 0
+839894400 0 0 0 0
+839808000 0 0 0 0
+839721600 0 0 0 0
+839635200 0 0 0 0
+839548800 0 0 0 0
+839462400 0 0 0 0
+839376000 0 0 0 0
+839289600 0 0 0 0
+839203200 0 0 0 0
+839116800 0 0 0 0
+839030400 0 0 0 0
+838944000 0 0 0 0
+838857600 0 0 0 0
+838771200 0 0 0 0
+838684800 0 0 0 0
+838598400 0 0 0 0
+838512000 0 0 0 0
+838425600 0 0 0 0
+838339200 0 0 0 0
+838252800 0 0 0 0
+838166400 0 0 0 0
+838080000 0 0 0 0
+837993600 0 0 0 0
+837907200 0 0 0 0
+837820800 0 0 0 0
+837734400 0 0 0 0
+837648000 0 0 0 0
+837561600 0 0 0 0
+837475200 0 0 0 0
+837388800 0 0 0 0
+837302400 0 0 0 0
+837216000 0 0 0 0
+837129600 0 0 0 0
+837043200 0 0 0 0
+836956800 0 0 0 0
+836870400 0 0 0 0
+836784000 0 0 0 0
+836697600 0 0 0 0
+836611200 0 0 0 0
+836524800 0 0 0 0
+836438400 0 0 0 0
+836352000 0 0 0 0
+836265600 0 0 0 0
+836179200 0 0 0 0
+836092800 0 0 0 0
+836006400 0 0 0 0
+835920000 0 0 0 0
+835833600 0 0 0 0
+835747200 0 0 0 0
+835660800 0 0 0 0
+835574400 0 0 0 0
+835488000 0 0 0 0
+835401600 0 0 0 0
+835315200 0 0 0 0
+835228800 0 0 0 0
+835142400 0 0 0 0
+835056000 0 0 0 0
+834969600 0 0 0 0
+834883200 0 0 0 0
+834796800 0 0 0 0
+834710400 0 0 0 0
+834624000 0 0 0 0
+834537600 0 0 0 0
+834451200 0 0 0 0
+834364800 0 0 0 0
+834278400 0 0 0 0
+834192000 0 0 0 0
+834105600 0 0 0 0
+834019200 0 0 0 0
+833932800 0 0 0 0
+833846400 0 0 0 0
+833760000 0 0 0 0
+833673600 0 0 0 0
+833587200 0 0 0 0
+833500800 0 0 0 0
+833414400 0 0 0 0
+833328000 0 0 0 0
+833241600 0 0 0 0
+833155200 0 0 0 0
+833068800 0 0 0 0
+832982400 0 0 0 0
+832896000 0 0 0 0
+832809600 0 0 0 0
+832723200 0 0 0 0
+832636800 0 0 0 0
+832550400 0 0 0 0
+832464000 0 0 0 0
+832377600 0 0 0 0
+832291200 0 0 0 0
+832204800 0 0 0 0
+832118400 0 0 0 0
+832032000 0 0 0 0
+831945600 0 0 0 0
+831859200 0 0 0 0
+831772800 0 0 0 0
+831686400 0 0 0 0
+831600000 0 0 0 0
+831513600 0 0 0 0
+831427200 0 0 0 0
+831340800 0 0 0 0
+831254400 0 0 0 0
+831168000 0 0 0 0
+831081600 0 0 0 0
+830995200 0 0 0 0
+830908800 0 0 0 0
+830822400 0 0 0 0
+830736000 0 0 0 0
+830649600 0 0 0 0
+830563200 0 0 0 0
+830476800 0 0 0 0
+830390400 0 0 0 0
+830304000 0 0 0 0
+830217600 0 0 0 0
+830131200 0 0 0 0
+830044800 0 0 0 0
+829958400 0 0 0 0
+829872000 0 0 0 0
+829785600 0 0 0 0
+829699200 0 0 0 0
+829612800 0 0 0 0
+829526400 0 0 0 0
+829440000 0 0 0 0
+829353600 0 0 0 0
+829267200 0 0 0 0
+829180800 0 0 0 0
+829094400 0 0 0 0
+829008000 0 0 0 0
+828921600 0 0 0 0
+828835200 0 0 0 0
+828748800 0 0 0 0
+828662400 0 0 0 0
+828576000 0 0 0 0
+828489600 0 0 0 0
+828403200 0 0 0 0
+828316800 0 0 0 0
+828230400 0 0 0 0
+828144000 0 0 0 0
+828057600 0 0 0 0
+827971200 0 0 0 0
+827884800 0 0 0 0
+827798400 0 0 0 0
+827712000 0 0 0 0
+827625600 0 0 0 0
+827539200 0 0 0 0
+827452800 0 0 0 0
+827366400 0 0 0 0
+827280000 0 0 0 0
+827193600 0 0 0 0
+827107200 0 0 0 0
+827020800 0 0 0 0
+826934400 0 0 0 0
+826848000 0 0 0 0
+826761600 0 0 0 0
+826675200 0 0 0 0
+826588800 0 0 0 0
+826502400 0 0 0 0
+826416000 0 0 0 0
+826329600 0 0 0 0
+826243200 0 0 0 0
+826156800 0 0 0 0
+826070400 0 0 0 0
+825984000 0 0 0 0
+825897600 0 0 0 0
+825811200 0 0 0 0
+825724800 0 0 0 0
+825638400 0 0 0 0
+825552000 0 0 0 0
+825465600 0 0 0 0
+825379200 0 0 0 0
+825292800 0 0 0 0
+825206400 0 0 0 0
+825120000 0 0 0 0
+825033600 0 0 0 0
+824947200 0 0 0 0
+824860800 0 0 0 0
+824774400 0 0 0 0
+824688000 0 0 0 0
+824601600 0 0 0 0
+824515200 0 0 0 0
+824428800 0 0 0 0
+824342400 0 0 0 0
+824256000 0 0 0 0
+824169600 0 0 0 0
+824083200 0 0 0 0
+823996800 0 0 0 0
+823910400 0 0 0 0
+823824000 0 0 0 0
+823737600 0 0 0 0
+823651200 0 0 0 0
+823564800 0 0 0 0
+823478400 0 0 0 0
+823392000 0 0 0 0
+823305600 0 0 0 0
+823219200 0 0 0 0
+823132800 0 0 0 0
+823046400 0 0 0 0
+822960000 0 0 0 0
+822873600 0 0 0 0
+822787200 0 0 0 0
+822700800 0 0 0 0
+822614400 0 0 0 0
+822528000 0 0 0 0
+822441600 0 0 0 0
+822355200 0 0 0 0
+822268800 0 0 0 0
+822182400 0 0 0 0
+822096000 0 0 0 0
+822009600 0 0 0 0
+821923200 0 0 0 0
+821836800 0 0 0 0
+821750400 0 0 0 0
+821664000 0 0 0 0
+821577600 0 0 0 0
+821491200 0 0 0 0
+821404800 0 0 0 0
+821318400 0 0 0 0
+821232000 0 0 0 0
+821145600 0 0 0 0
+821059200 0 0 0 0
+820972800 0 0 0 0
+820886400 0 0 0 0
+820800000 0 0 0 0
--- /dev/null
+#!/usr/local/bin/perl
+# simple mqueue done with find2perl
+
+$hostname = "terror.hungry.com";
+
+require "find.pl";
+# Traverse desired filesystems
+$counter = 0;
+&find('/var/spool/mqueue/');
+sub wanted {
+ /^qf.*$/ &&
+$counter++;
+}
+chomp $counter;
+print "0\n$counter\n1\n$hostname\n";
--- /dev/null
+#
+# Mail.cfg: Mailstats plotting with MRTG
+#
+WorkDir: /u/pere/public_html/mrtg
+Interval: 5
+#---------------------------------------------------------------
+Target[mail]: `/u/pere/public_html/mrtg/mailstats`
+MaxBytes[mail]: 150
+AbsMax[mail]: 1800
+#Unscaled[mail]: dwmy
+Options[mail]: growright,gauge, nopercent
+Title[mail]: terror.hungry.com Sendmail send/receive Statistics
+PageTop[mail]: terror.hungry.com Sendmail Statistics</H1>
+XSize[mail]: 500
+#Supress[mail]: my
+YSize[mail]: 128
+WithPeak[mail]: dwmy
+YLegend[mail]: No. of messages
+ShortLegend[mail]: messages
+LegendI[mail]: Incoming:
+LegendO[mail]: Outgoing:
+# Interval: 5
+#---------------------------------------------------------------
+Target[mq]: `/u/pere/public_html/mrtg/mqueue`
+MaxBytes[mq]: 32000
+AbsMax[mq]: 64000
+Options[mq]: growright,gauge, nopercent
+Title[mq]: terror.hungry.com Sendmail MailQueue Statistics
+PageTop[mq]: <H2>terror.hungry.com Sendmail MailQueue Statistics</H2>
+XSize[mq]: 500
+Supress[mq]: y
+YSize[mq]: 128
+WithPeak[mq]: my
+YLegend[mq]: No. of messages in mailq
+ShortLegend[mq]: Mailq
+LegendO[mq]: Mailq:
+LegendI[mq]:
--- /dev/null
+ Mark Andrews
+INTERNET DRAFT CSIRO
+Expires: September 1996 May 1996
+Updates RFC-1035
+
+ ASCII Encoding for Domain Names
+
+ draft-andrews-dns-ascii-01.txt
+
+1. Status of This Memo
+
+ This document is an Internet Draft. Internet Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its Areas,
+ and its Working Groups. Note that other groups may also distribute
+ working documents as Internet Drafts.
+
+ Internet Drafts are draft documents valid for a maximum of six
+ months. Internet Drafts may be updated, replaced, or obsoleted by
+ other documents at any time. It is not appropriate to use Internet
+ Drafts as reference material or to cite them other than as a "working
+ draft" or "work in progress."
+
+ Please check the 1id-abstracts.txt listing contained in the internet-
+ drafts Shadow Directories to learn the current status of any Internet
+ Draft.
+
+2. Abstract
+
+ [RFC 1035 Section 5.1] describes how to encode domain names as
+ character strings. It however allows non printable characters to be
+ used. It also allows for encodings of text files which would not
+ survive intact ftp ASCII mode transfers, different end of line
+ conventions. This document addresses these problems by stating where
+ octal escapes MUST be used.
+
+ While a applications MUST continue to read the full range as
+ expressed by [RFC 1035 5.1]. They MUST emit only this selected
+ subset.
+
+3. Encoding
+
+ Octets within the follow ranges are encoded as backslash followed by
+ three octal digits, 0x00 - 0x20, 0x7f - 0xff.
+
+ e.g.
+ 0x00, \000
+ 0x1f, \177
+ 0xff, \377
+
+
+
+Andrews [Page 1]
+\f
+Internet Draft draft-andrews-dns-ascii-01.txt May 1996
+
+
+ Period (".") when NOT used as a domain separator is encoded as the
+ sequence backslash period, e.g. "\.". Un-escaped periods indicate
+ label separators.
+
+ Backslash ("\") is encoded as two consecutive backslashes, e.g. "\\".
+
+ Double quotes ('"') should always be represented as backslash quote
+ as a common nameserver implementation mis-parses strings containing
+ quotes, e.g. '\"'.
+
+ Semi-colon (";") should always be encoded as backslash semi-colon
+ otherwise it will be interpreted as a comment. e.g. "\;".
+
+ Space may be a literal space when the string is enclosed by double
+ quotes.
+
+ All other characters represent their literal ASCII encoding eighth
+ bit not set.
+
+4. Security
+
+ This draft introduces no known security problems. It may however
+ remove some latent security problems in applications where the
+ encoding is NOT reversible leading to unexpected changes in domain
+ names.
+
+4. References
+
+ [RFC-1035]
+ P. Mockapetris, ``DOMAIN NAMES - IMPLEMENTATION AND
+ SPECIFICATION'', RFC-1035, ISI, November 1987.
+
+6. Author's Address
+
+ Mark Andrews
+ CSIRO
+ Division of Mathematics and Statistics
+ Locked Bag 17
+ North Ryde NSW 2113
+ AUSTRALIA
+
+ Mark.Andrews@dms.csiro.au [MA88]
+
+
+
+
+
+
+
+
+
+Andrews [Page 2]
+\f
--- /dev/null
+
+Applications Area Arnt Gulbrandsen
+INTERNET-DRAFT Troll Technologies
+<draft-gulbrandsen-dns-rr-srvcs-03.txt> Paul Vixie
+ Vixie Enterprises
+ March 1996
+
+Category: Experimental
+Updates: RFC 1035, RFC 1183
+
+
+ A DNS RR for specifying the location of services (DNS SRV)
+
+
+Abstract
+
+ This document describes a DNS RR which specifies the location of the
+ server(s) for a specific protocol and domain (like a more general
+ form of MX).
+
+Status of this memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ To learn the current status of any Internet-Draft, please check the
+ ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+Overview and rationale
+
+ Currently, one must either know the exact address of a server to
+ contact it, or broadcast a question. This has led to e.g.
+ ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
+ level broadcasts to locate servers.
+
+ The SRV RR allows administrators to use several servers for a single
+ domain, to move services from host to host with little fuss, and to
+ designate some hosts as primary servers for a service and others as
+ backups.
+
+
+
+Gulbrandsen and Vixie [Page 1]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ Clients ask for a specific service/protocol for a specific domain
+ (the word domain is used here in the strict RFC 1034 sense), and get
+ back the names of any available servers.
+
+
+Introductory example
+
+ When a SRV-cognizant web-browser wants to retrieve
+
+ http://www.asdf.com/
+
+ it does a lookup of
+
+ _http._tcp.www.asdf.com
+
+ and retrieves the document from one of the servers in the reply. The
+ example zone file near the end of the draft contains answering RRs
+ for this query.
+
+
+The format of the SRV RR
+
+ Here is the format of the SRV RR, whose DNS type code is 33:
+
+ _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+
+ (There is an example near the end of this document.)
+
+ Service
+ The symbolic name of the desired service, as defined in Assigned
+ Numbers or locally. An underscore (_) is prepended to the
+ service identifier to avoid collisions with DNS labels that
+ occur in nature.
+
+ Some widely used services, notably POP, don't have a single
+ universal name. If Assigned Numbers names the service
+ indicated, that name is the only name which is legal for SRV
+ lookups. Only locally defined services may be named locally.
+ The Service is case insensitive.
+
+ Proto
+ The symbolic name of the desired protocol, with an underscore
+ (_) prepended to prevent collisions with DNS labels that occur
+ in nature. _TCP and _UDP are at present the most useful values
+ for this field, though any name defined by Assigned Numbers or
+ locally may be used (as for Service). The Proto is case
+ insensitive.
+
+
+
+
+Gulbrandsen and Vixie [Page 2]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ Name
+ The domain this RR refers to. The SRV RR is unique in that the
+ name one searches for is not this name; the example near the end
+ shows this clearly.
+
+ TTL
+ Standard DNS meaning.
+
+ Class
+ Standard DNS meaning.
+
+ Priority
+ As for MX, the priority of this target host. A client MUST
+ attempt to contact the target host with the lowest-numbered
+ priority it can reach; target hosts with the same priority
+ SHOULD be tried in pseudorandom order. The range is 0-65535.
+
+ Weight
+ Load balancing mechanism. When selecting a target host among
+ the those that have the same priority, the chance of trying this
+ one first SHOULD be proportional to its weight. The range of
+ this number is 1-65535. Domain administrators are urged to use
+ Weight 0 when there isn't any load balancing to do, to make the
+ RR easier to read for humans (less noisy).
+
+ Port
+ The port on this target host of this service. The range is
+ 0-65535. This is often as specified in Assigned Numbers but
+ need not be.
+
+ Target
+ As for MX, the domain name of the target host. There MUST be
+ one or more A records for this name. Implementors are urged, but
+ not required, to return the A record(s) in the Additional Data
+ section. Name compression is to be used for this field.
+
+ A Target of ``.'' means that the service is decidedly not
+ available at this domain.
+
+
+Domain administrator advice
+
+ Asking everyone to update their telnet (for example) clients when the
+ first internet site adds a SRV RR for Telnet/TCP is futile (even if
+ desirable). Therefore SRV will have to coexist with A record lookups
+ for a long time, and DNS administrators should try to provide A
+ records to support old clients:
+
+
+
+
+Gulbrandsen and Vixie [Page 3]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ - Where the services for a single domain are spread over several
+ hosts, it seems advisable to have a list of A RRs at the same
+ DNS node as the SRV RR, listing reasonable (if perhaps
+ suboptimal) fallback hosts for Telnet, NNTP and other protocols
+ likely to be used with this name. Note that some programs only
+ try the first address they get back from e.g. gethostbyname(),
+ and we don't know how widespread this behaviour is.
+
+ - Where one service is provided by several hosts, one can either
+ provide A records for all the hosts (in which case the round-
+ robin mechanism, where available, will share the load equally)
+ or just for one (presumably the fastest).
+
+ - If a host is intended to provide a service only when the main
+ server(s) is/are down, it probably shouldn't be listed in A
+ records.
+
+ - Hosts that are referenced by backup A records must use the port
+ number specified in Assigned Numbers for the service.
+
+ Currently there's a practical limit of 512 bytes for DNS replies.
+ Until all resolvers can handle larger responses, domain
+ administrators are strongly advised to keep their SRV replies below
+ 512 bytes.
+
+ All round numbers, wrote Dr. Johnson, are false, and these numbers
+ are very round: A reply packet has a 30-byte overhead plus the name
+ of the service (``_telnet._tcp.asdf.com'' for instance); each SRV RR
+ adds 20 bytes plus the name of the target host; each NS RR in the NS
+ section is 15 bytes plus the name of the name server host; and
+ finally each A RR in the additional data section is 20 bytes or so,
+ and there are A's for each SRV and NS RR mentioned in the answer.
+ This size estimate is extremely crude, but shouldn't underestimate
+ the actual answer size by much. If an answer may be close to the
+ limit, using e.g. ``dig'' to look at the actual answer is a good
+ idea.
+
+
+The ``Weight'' field
+
+ Weight, the load balancing field, is not quite satisfactory, but the
+ actual load on typical servers changes much too quickly to be kept
+ around in DNS caches. It seems to the authors that offering
+ administrators a way to say ``this machine is three times as fast as
+ that one'' is the best that can practically be done.
+
+
+
+
+
+
+Gulbrandsen and Vixie [Page 4]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ The only way the authors can see of getting a ``better'' load figure
+ is asking a separate server when the client selects a server and
+ contacts it. For short-lived services like SMTP an extra step in the
+ connection establishment seems too expensive, and for long-lived
+ services like telnet, the load figure may well be thrown off a minute
+ after the connection is established when someone else starts or
+ finishes a heavy job.
+
+
+The Port number
+
+ Currently, the translation from service name to port number happens
+ at the client, often using a file such as /etc/services.
+
+ Moving this information to the DNS makes it less necessary to update
+ these files on every single computer of the net every time a new
+ service is added, and makes it possible to move standard services out
+ of the ``root-only'' port range on unix.
+
+
+Usage rules
+
+ A SRV-cognizant client SHOULD use this procedure to locate a list of
+ servers and connect to the preferred one:
+
+ Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
+ QTYPE=SRV.
+
+ If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
+ RR which specifies the requested Service and Protocol in the
+ reply:
+
+ If there is precisely one SRV RR, and its Target is ``.''
+ (the root domain), abort.
+
+ Else, for all such RR's, build a list of (Priority, Weight,
+ Target) tuples
+
+ Sort the list by priority (lowest number first)
+
+ Create a new empty list
+
+ For each distinct priority level
+ While there are still elements left at this priority
+ level
+ Select an element randomly, with probability
+ Weight, and move it to the tail of the new list
+
+
+
+
+Gulbrandsen and Vixie [Page 5]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ For each element in the new list
+
+ query the DNS for A RR's for the Target or use any
+ RR's found in the Additional Data secion of the
+ earlier SRV query.
+
+ for each A RR found, try to connect to the (protocol,
+ address, service).
+
+ else if the service desired is SMTP
+
+ skip to RFC 974 (MX).
+
+ else
+
+ Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
+
+ for each A RR found, try to connect to the (protocol,
+ address, service)
+
+ Notes:
+
+ - Port numbers SHOULD NOT be used in place of the symbolic service
+ or protocol names (for the same reason why variant names cannot
+ be allowed: Applications would have to do two or more lookups).
+
+ - If a truncated response comes back from an SRV query, and the
+ Additional Data section has at least one complete RR in it, the
+ answer MUST be considered complete and the client resolver
+ SHOULD NOT retry the query using TCP, but use normal UDP queries
+ for A RR's missing from the Additional Data section.
+
+ - A client MAY use means other than Weight to choose among target
+ hosts with equal Priority.
+
+ - A client MUST parse all of the RR's in the reply.
+
+ - If the Additional Data section doesn't contain A RR's for all
+ the SRV RR's and the client may want to connect to the target
+ host(s) involved, the client MUST look up the A RR(s). (This
+ happens quite often when the A RR has shorter TTL than the SRV
+ or NS RR's.)
+
+ - A future standard could specify that a SRV RR whose Protocol was
+ _TCP and whose Service was _SMTP would override RFC 974's rules
+ with regard to the use of an MX RR. This would allow firewalled
+ organizations with several SMTP relays to control the load
+ distribution using the Weight field.
+
+
+
+Gulbrandsen and Vixie [Page 6]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ - Future protocols could be designed to use SRV RR lookups as the
+ means by which clients locate their servers.
+
+
+Fictional example
+
+ This is (part of) the zone file for asdf.com, a still-unused domain:
+
+ $ORIGIN asdf.com.
+ @ SOA server.asdf.com. root.asdf.com. (
+ 1995032001 3600 3600 604800 86400 )
+ NS server.asdf.com.
+ NS ns1.ip-provider.net.
+ NS ns2.ip-provider.net.
+ _ftp._tcp SRV 0 0 21 server.asdf.com.
+ _finger._tcp SRV 0 0 79 server.asdf.com.
+ ; telnet - use old-slow-box or new-fast-box if either is
+ ; available, make three quarters of the logins go to
+ ; new-fast-box.
+ _telnet._tcp SRV 0 1 23 old-slow-box.asdf.com.
+ SRV 0 3 23 new-fast-box.asdf.com.
+ ; if neither old-slow-box or new-fast-box is up, switch to
+ ; using the sysdmin's box and the server
+ SRV 1 0 23 sysadmins-box.asdf.com.
+ SRV 1 0 23 server.asdf.com.
+ ; HTTP - server is the main server, new-fast-box is the backup
+ ; (On new-fast-box, the HTTP daemon runs on port 8000)
+ _http._tcp SRV 0 0 80 server.asdf.com.
+ SRV 10 0 8000 new-fast-box.asdf.com.
+ ; since we want to support both http://asdf.com/ and
+ ; http://www.asdf.com/ we need the next two RRs as well
+ _http._tcp.www SRV 0 0 80 server.asdf.com.
+ SRV 10 0 8000 new-fast-box.asdf.com.
+ ; SMTP - mail goes to the server, and to the IP provider if
+ ; the net is down
+ _smtp._tcp SRV 0 0 25 server.asdf.com.
+ SRV 1 0 25 mailhost.ip-provider.net.
+ @ MX 0 server.asdf.com.
+ MX 1 mailhost.ip-provider.net.
+ ; NNTP - use the IP providers's NNTP server
+ _nntp._tcp SRV 0 0 119 nntphost.ip-provider.net.
+ ; IDB is an locally defined protocol
+ _idb._tcp SRV 0 0 2025 new-fast-box.asdf.com.
+ ; addresses
+ server A 172.30.79.10
+ old-slow-box A 172.30.79.11
+ sysadmins-box A 172.30.79.12
+ new-fast-box A 172.30.79.13
+
+
+
+Gulbrandsen and Vixie [Page 7]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ ; backup A records - new-fast-box and old-slow-box are
+ ; included, naturally, and server is too, but might go
+ ; if the load got too bad
+ @ A 172.30.79.10
+ A 172.30.79.11
+ A 172.30.79.13
+ ; backup A RR for www.asdf.com
+ www A 172.30.79.10
+ ; NO other services are supported
+ *._tcp SRV 0 0 0 .
+ *._udp SRV 0 0 0 .
+
+ In this example, a telnet connection to ``asdf.com.'' needs an SRV
+ lookup of ``_telnet._tcp.asdf.com.'' and possibly A lookups of ``new-
+ fast-box.asdf.com.'' and/or the other hosts named. The size of the
+ SRV reply is approximately 365 bytes:
+
+ 30 bytes general overhead
+ 20 bytes for the query string, ``_telnet._tcp.asdf.com.''
+ 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of ``new-
+ fast-box'', ``old-slow-box'', ``server'' and ``sysadmins-box'' -
+ ``asdf.com'' in the query section is quoted here and doesn't
+ need to be counted again.
+ 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
+ ``server'', ``ns1.ip-provider.net.'' and ``ns2'' - again, ``ip-
+ provider.net.'' is quoted and only needs to be counted once.
+ 120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
+
+
+Refererences
+
+ RFC 1918: Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E.
+ Lear, ``Address Allocation for Private Internets'', 02/29/1996.
+
+ RFC 1916 H. Berkowitz, P. Ferguson, W. Leland, P. Nesser,
+ ``Enterprise Renumbering: Experience and Information
+ Solicitation'', 02/28/1996.
+
+ RFC 1912 D. Barr, ``Common DNS Operational and Configuration
+ Errors'', 02/28/1996.
+
+ RFC 1900: B. Carpenter, Y. Rekhter, ``Renumbering Needs Work'',
+ 02/28/1996.
+
+ RFC 1880: J. Postel, ``INTERNET OFFICIAL PROTOCOL STANDARDS'',
+ 11/29/1995.
+
+ RFC 1814: E. Gerich, ``Unique Addresses are Good'', 06/22/1995.
+
+
+
+Gulbrandsen and Vixie [Page 8]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ RFC 1794: T. Brisco, ``DNS Support for Load Balancing'', 04/20/1995.
+
+ RFC 1713: A. Romao, ``Tools for DNS debugging'', 11/03/1994.
+
+ RFC 1712: C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, ``DNS
+ Encoding of Geographical Location'', 11/01/1994.
+
+ RFC 1706: B. Manning, R. Colella, ``DNS NSAP Resource Records'',
+ 10/26/1994.
+
+ RFC 1700: J. Reynolds, J. Postel, ``ASSIGNED NUMBERS'', 10/20/1994.
+
+ RFC 1183: R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, ``New
+ DNS RR Definitions'', 10/08/1990.
+
+ RFC 1101: P. Mockapetris, ``DNS encoding of network names and other
+ types'', 04/01/1989.
+
+ RFC 1035: P. Mockapetris, ``Domain names - implementation and
+ specification'', 11/01/1987.
+
+ RFC 1034: P. Mockapetris, ``Domain names - concepts and facilities'',
+ 11/01/1987.
+
+ RFC 1033: M. Lottor, ``Domain administrators operations guide'',
+ 11/01/1987.
+
+ RFC 1032: M. Stahl, ``Domain administrators guide'', 11/01/1987.
+
+ RFC 974: C. Partridge, ``Mail routing and the domain system'',
+ 01/01/1986.
+
+
+Security Considerations
+
+ The authors believes this RR to not cause any new security problems.
+ Some problems become more visible, though.
+
+ - The ability to specify ports on a fine-grained basis obviously
+ changes how a router can filter packets. It becomes impossible
+ to block internal clients from accessing specific external
+ services, slightly harder to block internal users from running
+ unautorised services, and more important for the router
+ operations and DNS operations personnel to cooperate.
+
+ - There is no way a site can keep its hosts from being referenced
+ as servers (as, indeed, some sites become unwilling secondary
+ MXes today). This could lead to denial of service.
+
+
+
+Gulbrandsen and Vixie [Page 9]
+\f
+Expires October 1996 DNS SRV RR March 1996
+
+
+ - With SRV, DNS spoofers can supply false port numbers, as well as
+ host names and addresses. The authors do not see any practical
+ effect of this.
+
+ We assume that as the DNS-security people invent new features, DNS
+ servers will return the relevant RRs in the Additional Data section
+ when answering an SRV query.
+
+
+Authors' Addresses
+
+ Arnt Gulbrandsen
+ Troll Tech
+ Postboks 6133 Etterstad
+ N-0602 Oslo
+ Norway
+
+ Phone: +47 22646966
+
+ Mail: agulbra@troll.no
+
+ Paul Vixie
+ Vixie Enterprises
+ Star Route 159A
+ Woodside, CA 94062
+
+ Phone: (415) 747-0204
+
+ Mail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen and Vixie [Page 10]
+\f
+
--- /dev/null
+
+
+Network Working Group Robert Elz
+Internet Draft University of Melbourne
+Expiration Date: November 1996
+ Randy Bush
+ RGnet, Inc.
+
+ May 1996
+
+
+ Clarifications to the DNS Specification
+
+
+ draft-ietf-dnsind-clarify-01.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ To learn the current status of any Internet-Draft, please check the
+ "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+1. Abstract
+
+ This draft considers some areas that have been identified as problems
+ with the specification of the Domain Name System, and proposes
+ remedies for the defects identified. Two separate issues are
+ considered, IP packet header address usage from multi-homed servers,
+ and TTLs in sets of records with the same name, class, and type.
+
+
+
+
+
+
+
+
+
+
+
+
+kre/randy [Page 1]
+\f
+Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
+
+
+2. Introduction
+
+ Several problem areas in the Domain Name System specification
+ [RFC1034, RFC1035] have been noted through the years [RFC1123]. This
+ draft addresses two additional problem areas. The two issues here
+ are independent. Those issues are the question of which source
+ address a multi-homed DNS server should use when replying to a query,
+ and the issue of differing TTLs for DNS records with the same label,
+ class and type.
+
+ Suggestions for clarifications to the DNS specification to avoid
+ these problems are made in this memo. The solutions proposed herein
+ are intended to stimulate discussion. It is possible that the sense
+ of either may be reversed before the next iteration of this draft,
+ but less likely now than it was before the previous version.
+
+3. Server Reply Source Address Selection
+
+ Most, if not all, DNS clients, whether servers acting as clients for
+ the purposes of recursive query resolution, or resolvers, expect the
+ address from which a reply is received to be the same address as that
+ to which the query eliciting the reply was sent. This, along with
+ the identifier (ID) in the reply is used for disambiguating replies,
+ and filtering spurious responses. This may, or may not, have been
+ intended when the DNS was designed, but is now a fact of life.
+
+ Some multi-homed hosts running DNS servers fail to anticipate this
+ usage, and consequently send replies from the "wrong" source address,
+ causing the reply to be discarded by the client.
+
+3.1. UDP Source Address Selection
+
+ To avoid these problems, servers when responding to queries using UDP
+ must cause the reply to be sent with the source address field in the
+ IP header set to the address that was in the destination address
+ field of the IP header of the packet containing the query causing the
+ response. If this would cause the response to be sent from an IP
+ address which is not permitted for this purpose, then the response
+ may be sent from any legal IP address allocated to the server. That
+ address should be chosen to maximise the possibility that the client
+ will be able to use it for further queries. Servers configured in
+ such a way that not all their addresses are equally reachable from
+ all potential clients need take particular care when responding to
+ queries sent to anycast, multicast, or similar, addresses.
+
+
+
+
+
+
+
+kre/randy [Page 2]
+\f
+Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
+
+
+3.2. Port Number Selection
+
+ Replies to all queries must be directed to the port from which they
+ were sent. With queries received via TCP this is an inherent part of
+ the transport protocol, for queries received by UDP the server must
+ take note of the source port and use that as the destination port in
+ the response. Replies should always be sent from the port to which
+ they were directed. Except in extraordinary circumstances, this will
+ be the well known port assigned for DNS queries [RFC1700].
+
+4. Resource Record Sets
+
+ Each DNS Resource Record (RR) each has a label, class, type, and
+ data. While it is meaningless for two records to ever have label,
+ class, type and data all equal (servers should suppress such
+ duplicates if encountered), it is possible for many record types to
+ exist with the same label class and type, but with different data.
+ Such a group of records is hereby defined to be a Resource Record Set
+ (RRSet).
+
+4.1. Sending RRs from an RRSet
+
+ A query for a specific (or non-specific) label, class, and type, will
+ always return all records in the associated RRSet - whether that be
+ one or more RRs, or the response shall be marked as "truncated" if
+ the entire RRSet will not fit in the response.
+
+4.2. TTLs of RRs in an RRSet
+
+ Resource Records also have a time to live (TTL). It is possible for
+ the RRs in an RRSet to have different TTLs, however no uses for this
+ have been found which cannot be better accomplished in other ways.
+ This can, however, cause partial replies (not marked "truncated")
+ from a caching server, where the TTLs for some but not all of the RRs
+ in the RRSet have expired.
+
+ Consequently the use of differing TTLs in an RRSet is hereby
+ deprecated, the TTLs of all RRs in an RRSet must be the same.
+
+ Should a client receive a response containing RRs from an RRSet with
+ differing TTLs, it should treat the RRs for all purposes as if all
+ TTLs in the RRSet had been set to the value of the lowest TTL in the
+ RRSet.
+
+
+
+
+
+
+
+
+kre/randy [Page 3]
+\f
+Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
+
+
+4.3. Receiving RRSets
+
+ Servers never merge RRs from a response with RRs in their cache to
+ form an RRSet. If a response contains data which would form an RRSet
+ with data in a server's cache the server must either ignore the RRs
+ in the response, or use those to replace the existing RRSet in the
+ cache, as appropriate. Consequently the issue of TTLs varying
+ between the cache and a response does not cause concern, one will be
+ ignored.
+
+4.3.1. Ranking data
+
+ When considering whether to accept an RRSet in a reply, or retain an
+ RRSet already in its cache instead, a server should consider the
+ relative likely trustworthiness of the various data. That is, an
+ authoritative answer from a reply should replace cached data that had
+ been obtained from additional information in an earlier reply, but
+ additional information from a reply will be ignored if the cache
+ contains data from an authoritative answer or a zone file.
+
+ The accuracy of data available is assumed from its source.
+ Trustworthiness shall be, in order from most to least:
+
+ + Data from a primary zone file, other than glue data,
+ + Data from a zone transfer, other than glue,
+ + That from the answer section of an authoritative reply,
+ + Glue from a primary zone, or glue from a zone transfer,
+ + Data from the authority section of an authoritative answer,
+ + Data from the answer section of a non-authoritative answer,
+ + Additional information from an authoritative answer,
+ + Data from the authority section of a non-authoritative answer,
+ + Additional information from non-authoritative answers.
+
+ Where authenticated data has been received it shall be considered
+ more trustworthy than unauthenticated data of the same type.
+
+ "Glue" above includes any record in a zone file that is not properly
+ part of that zone, including nameserver records of delegated sub-
+ zones (NS records), address records that accompany those NS records
+ (A, AAAA, etc), and any other stray data that might appear.
+
+4.4. Sending RRSets (reprise)
+
+ A Resource Record Set should only be included once in any DNS reply.
+ It may occur in any of the Answer, Authority, or Additional
+ Information sections, as required, however should not be repeated in
+ the same, or any other, section, except where explicitly required by
+ a specification. For example, an AXFR response requires the SOA
+
+
+
+kre/randy [Page 4]
+\f
+Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
+
+
+ record (always an RRSet containing a single RR) be both the first and
+ last record of the reply. Where duplicates are required this way,
+ the TTL transmitted in each case must be the same.
+
+5. Security Considerations
+
+ This document does not consider security.
+
+ In particular, nothing in section 3 is any way related to, or useful
+ for, any security related purposes.
+
+ Section 4.3.1 is also not related to security. Security of DNS data
+ will be obtained by the Secure DNS [DNSSEC], which is orthogonal to
+ this memo.
+
+ It is not believed that anything in this document adds to any
+ security issues that may exist with the DNS, nor does it do anything
+ to lessen them.
+
+6. References
+
+ [RFC1034] Domain Names - Concepts and Facilities, (STD 13)
+ P. Mockapetris, ISI, November 1987.
+
+ [RFC1035] Domain Names - Implementation and Specification (STD 13)
+ P. Mockapetris, ISI, November 1987
+
+ [RFC1123] Requirements for Internet hosts - application and support,
+ (STD 3) R. Braden, January 1989
+
+ [RFC1700] Assigned Numbers (STD 2)
+ J. Reynolds, J. Postel, October 1994.
+
+ [DNSSEC] Domain Name System Security Extensions,
+ D. E. Eastlake, 3rd, C. W. Kaufman,
+ Work in Progress (Internet Draft), January 1996.
+
+7. Acknowledgements
+
+ This memo arose from discussions in the DNSIND working group of the
+ IETF in 1995 and 1996, the members of that working group are largely
+ responsible for the ideas captured herein.
+
+
+
+
+
+
+
+
+
+kre/randy [Page 5]
+\f
+Internet Draft draft-ietf-dnsind-clarify-01.txt May 1996
+
+
+8. Authors' addresses
+
+ Robert Elz
+ Computer Science
+ University of Melbourne
+ Parkville, Victoria, 3052
+ Australia.
+
+ EMail: kre@munnari.OZ.AU
+
+
+ Randy Bush
+ RGnet, Inc.
+ 9501 SW Westhaven
+ Portland, Oregon, 97225
+ United States.
+
+ EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+kre/randy [Page 6]
--- /dev/null
+
+Network Working Group Robert Elz
+Internet Draft University of Melbourne
+Expiration Date: October 1996
+ Randy Bush
+ RGnet, Inc.
+
+ April 1996
+
+
+ Serial Number Arithmetic
+
+ draft-ietf-dnsind-serial-03.txt
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ To learn the current status of any Internet-Draft, please check the
+ "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+2. Abstract
+
+ This draft defines serial number arithmetic, as used in the Domain
+ Name System. The DNS has long relied upon serial number arithmetic,
+ a concept which has never really been defined, certainly not in an
+ IETF document, though which has been widely understood. This draft
+ supplies the missing definition. It is intended to update RFC1034
+ and RFC1035.
+
+
+
+
+
+
+
+
+
+
+
+kre/randy [Page 1]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+3. Introduction
+
+ The serial number field of the SOA resource record is defined in
+ RFC1035 as
+
+ SERIAL The unsigned 32 bit version number of the original copy of
+ the zone. Zone transfers preserve this value. This value
+ wraps and should be compared using sequence space
+ arithmetic.
+
+ RFC1034 uses the same terminology when defining secondary server zone
+ consistency procedures.
+
+ Unfortunately the term "sequence space arithmetic" is not defined in
+ either RFC1034 or RFC1035, nor do any of their references provide
+ further information.
+
+ This phrase seems to have been intending to specify arithmetic as
+ used in TCP sequence numbers [RFC793], and defined in [IEN-74].
+
+ Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
+ the purposes of the DNS, as no general comparison operator is
+ defined.
+
+ To avoid further problems with this simple field, this document
+ defines the field and the operations available upon it. This
+ definition is intended merely to clarify the intent of RFC1034 and
+ RFC1035, and is believed to generally agree with current
+ implementations. However, older, superseded, implementations are
+ known to have treated the serial number as a simple unsigned integer,
+ with no attempt to implement any kind of "sequence space arithmetic",
+ however that may have been interpreted, and further, ignoring the
+ requirement that the value wraps. Nothing can be done with these
+ implementations, beyond extermination.
+
+4. Serial Number Arithmetic
+
+ Serial numbers are formed from non-negative integers from a finite
+ subset of the range of all integer values. The lowest integer in
+ every subset used for this purpose is zero, the maximum is always one
+ less than a power of two.
+
+ When considered as serial numbers however no value has any particular
+ significance, there is no minimum or maximum serial number, every
+ value has a successor and predecessor.
+
+ To define a serial number to be used in this way, the size of the
+ serial number space must be given. This value, called "SERIAL_BITS",
+
+
+
+kre/randy [Page 2]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+ gives the power of two which results in one larger than the largest
+ integer corresponding to a serial number value. This also specifies
+ the number of bits required to hold every possible value of a serial
+ number of the defined type. The operations permitted upon serial
+ numbers are defined in the following section.
+
+5. Operations upon the serial number
+
+ Only two operations are defined upon serial numbers, addition of a
+ positive integer of limited range, and comparison with another serial
+ number.
+
+5.1. Addition
+
+ Serial numbers may be incremented by the addition of a positive
+ integer n, where n is taken from the range of integers
+ [0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the
+ result of such an addition, s', is defined as
+
+ s' = (s + n) modulo (2 ^ SERIAL_BITS)
+
+ where the addition and modulus operations here act upon values that
+ are non-negative values of unbounded size in the usual ways of
+ integer arithmetic.
+
+ Addition of a value outside the range
+ [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
+
+5.2. Comparison
+
+ Any two serial numbers, s1 and s2, may be compared. The definition
+ of the result of this comparison is as follows.
+
+ For the purposes of this definition, consider two integers, i1 and
+ i2, from the unbounded set of non-negative integers, such that i1 and
+ s1 have the same numeric value, as do i2 and s2. Arithmetic and
+ comparisons applied to i1 and i2 use ordinary unbounded integer
+ arithmetic.
+
+ Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
+ in all other cases, s1 is not equal to s2.
+
+ s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
+ and
+
+ (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
+ (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
+
+
+
+
+kre/randy [Page 3]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+ s1 is said to be greater than s2 if, and only if, s1 is not equal to
+ s2, and
+
+ (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
+ (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
+
+ Note that there are some pairs of values s1 and s2 for which s1 is
+ not equal to s2, but for which s1 is neither greater than, nor less
+ than, s2. An attempt to use these ordering operators on such pairs
+ of values produces an undefined result.
+
+ The reason for this is that those pairs of values are such that any
+ simple definition that were to define s1 to be less than s2 where
+ (s1, s2) is such a pair, would also usually cause s2 to be less than
+ s1, when the pair is (s2, s1). This would mean that the particular
+ order selected for a test could cause the result to differ, leading
+ to unpredictable implementations.
+
+ While it would be possible to define the test in such a way that the
+ inequality would not have this surprising property, while being
+ defined for all pairs of values, such a definition would be
+ unnecessarily burdensome to implement, and difficult to understand,
+ and would still allow cases where
+
+ s1 < s2 and (s1 + 1) > (s2 + 1)
+
+ which is just as non-intuitive.
+
+ Thus the problem case is left undefined, implementations are free to
+ return either result, or to flag an error, and users must take care
+ not to depend on any particular outcome. Usually this will mean
+ avoiding allowing those particular pairs of numbers to co-exist.
+
+ The relationships greater than or equal to, and less than or equal
+ to, follow in the natural way from the above definitions.
+
+6. Corollaries
+
+ These definitions give rise to some results of note
+
+6.1. Corollary 1
+
+ For any sequence number s and any integer n such that addition of n
+ to s is well defined, (s + n) >= s. Further (s + n) == s only when
+ n == 0, in all other defined cases, (s + n) > s.
+
+
+
+
+
+
+kre/randy [Page 4]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+6.2. Corollary 2
+
+ If s' is the result of adding the integer n to the sequence number s,
+ and m is another integer from the range defined as able to be added
+ to a sequence number, and s" is the result of adding m to s', then it
+ is undefined whether s" is greater than, or less than s, though it is
+ known that s" is not equal to s.
+
+6.3. Corollary 3
+
+ If s" from the previous corollary is further incremented, then there
+ is no longer any known relationship between the result and s.
+
+6.4. Corollary 4
+
+ If in corollary 2 the value (n + m) is such that addition of the sum
+ to sequence number s would produce a defined result, then corollary 1
+ applies, and s" is known to be greater than s.
+
+7. Examples
+
+7.1. A trivial example
+
+ The simplest meaningful serial number space has SERIAL_BITS == 2. In
+ this space, the integers that make up the serial number space are 0,
+ 1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1.
+
+ In this space, the largest integer that it is meaningful to add to a
+ sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
+
+ Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
+ Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether
+ 2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
+
+7.2. A slightly larger example
+
+ Consider the case where SERIAL_BITS == 8. In this space the integers
+ that make up the serial number space are 0, 1, 2, ... 254, 255.
+ 255 == 2^SERIAL_BITS - 1.
+
+ In this space, the largest integer that it is meaningful to add to a
+ sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
+
+ Addition is as expected in this space, for example: 255+1 == 0,
+ 100+100 == 200, and 200+100 == 44.
+
+ Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
+ 200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
+
+
+
+kre/randy [Page 5]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+ Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing
+ a serial number can cause it to become "smaller". Of course,
+ incrementing by a smaller number will allow many more increments to
+ be made before this occurs. However this is always something to be
+ aware of, it can cause surprising errors, or be useful as it is the
+ only defined way to actually cause a serial number to decrease.
+
+ The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
+ 255 are not equal, but in each pair, neither number is defined as
+ being greater than, or less than, the other.
+
+ It could be defined (arbitrarily) that 128 > 0, 129 > 1,
+ 130 > 2, ..., 255 > 127, by changing the comparison operator
+ definitions, as mentioned above. However note that that would cause
+ 255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a
+ definition, apart from being arbitrary, would also be more costly to
+ implement.
+
+8. Citation
+
+ As this defined arithmetic may be useful for purposes other than for
+ the DNS serial number, it may be referenced as Serial Number
+ Arithmetic from RFCXXXX. Any such reference shall be taken as
+ implying that the rules of sections 4 to 7 of this document apply to
+ the stated values.
+
+9. The DNS SOA serial number
+
+ The serial number in the DNS SOA Resource Record is a Serial Number
+ as defined above, with SERIAL_BITS being 32. That is, the serial
+ number is a non negative integer with values taken from the range
+ [0 .. 4294967295]. That is, a 32 bit unsigned integer.
+
+ The maximum defined increment is 2147483647 (2^31 - 1).
+
+ Care should be taken that the serial number not be incremented, in
+ one or more steps, by more than this maximum within the period given
+ by the value of SOA.expire. Doing so may leave some secondary
+ servers with out of date copies of the zone, but with a serial number
+ "greater" than that of the primary server. Of course, special
+ circumstances may require this rule be set aside, for example, when
+ the serial number needs to be set lower for some reason. If this
+ must be done, then take special care to verify that ALL servers have
+ correctly succeeded in following the primary server's serial number
+ changes, at each step.
+
+ Note that each, and every, increment to the serial number must be
+ treated as the start of a new sequence of increments for this
+
+
+
+kre/randy [Page 6]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+ purpose, as well as being the continuation of all previous sequences
+ started within the period specified by SOA.expire.
+
+ Caution should also be exercised before causing the serial number to
+ be set to the value zero. While this value is not in any way special
+ in serial number arithmetic, or to the DNS SOA serial number, many
+ DNS implementations have incorrectly treated zero as a special case,
+ with special properties, and unusual behaviour may be expected if
+ zero is used as a DNS SOA serial number.
+
+10. Document Updates
+
+ RFC1034 and RFC1035 are to be treated as if the references to
+ "sequence space arithmetic" therein are replaced by references to
+ serial number arithmetic, as defined in this document.
+
+11. Security Considerations
+
+ This document does not consider security.
+
+ It is not believed that anything in this document adds to any
+ security issues that may exist with the DNS, nor does it do anything
+ to lessen them.
+
+12. References
+
+[RFC1034] Domain Names - Concepts and Facilities,
+ P. Mockapetris, ISI, November 1987.
+
+[RFC1035] Domain Names - Implementation and Specification
+ P. Mockapetris, ISI, November 1987
+
+[RFC793] Transmission Control protocol
+ Information Sciences Institute, USC, September 1981
+
+[IEN-74] Sequence Number Arithmetic
+ William W. Plummer, BB&N Inc, September 1978
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+kre/randy [Page 7]
+\f
+Internet Draft draft-ietf-dnsind-serial-03.txt April 1996
+
+
+13. Acknowledgements
+
+ Thanks to Rob Austein for suggesting clarification of the undefined
+ comparison operators, and to Michael Patton for attempting to locate
+ another reference for this procedure. Thanks also to members of the
+ IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
+
+14. Authors' Addresses
+
+ Robert Elz
+ Computer Science
+ University of Melbourne
+ Parkville, Vic, 3052
+ Australia.
+
+ Randy Bush
+ RGnet, Inc.
+ 9501 SW Westhaven
+ Portland, Oregon, 97225
+ United States.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+kre/randy [Page 8]
--- /dev/null
+
+INTERNET-DRAFT John Klensin, Editor
+Expires in six months MCI
+ May 21, 1996
+
+ Simple Mail Transfer Protocol
+
+ draft-ietf-drums-smtpupd-02.txt
+
+ Status of this Memo
+
+This document is an Internet-Draft. Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas, and
+its working groups. Note that other groups may also distribute working
+documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months.
+Internet-Drafts may be updated, replaced, or obsoleted by other
+documents at any time. It is not appropriate to use Internet-Drafts as
+reference material or to cite them other than as a "working draft" or
+"work in progress".
+
+To learn the current status of any Internet-Draft, please check the
+1id-abstracts.txt listing contained in the Internet-Drafts Shadow
+Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
+ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
+
+If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed as a Proposed
+Standard for mail transport.
+
+[[Sections marked with doubled brackets (e.g., "<<") are explicit
+placeholders or known major loose ends. The marking ## is a note in
+the draft to recheck a section number and should be ignored.]]
+
+
+
+ TABLE OF CONTENTS
+ 0. ABSTRACT
+
+ 1. INTRODUCTION
+
+ 2. THE SMTP MODEL
+
+ 2.1 Basic structure
+ 2.2 The extension model
+ 2.3 Other terminology
+ 2.4 Syntax Principles
+
+
+ 3. THE SMTP PROCEDURES: AN OVERVIEW
+
+ 3.1 Session initiation
+ 3.2 Client initiation
+ 3.3 Mail transactions
+ 3.4 Forwarding for Address Correction or Updating
+ 3.5 Verifying and Expanding
+ 3.6 Domains
+ 3.7 Relaying
+ 3.8 Terminating sessions and connections
+
+ 4. THE SMTP SPECIFICATIONS
+
+ 4.1. SMTP Commands
+ 4.1.1. Command Semantics and Syntax
+ 4.1.2. Lower-level Syntax
+ 4.1.3 Order of commands
+ 4.1.4 Private-use commands
+ 4.2. SMTP Replies
+ 4.2.1. Reply Codes by Function Group
+ 4.2.2. Reply Codes in Numeric Order
+ 4.2.3. Reply code 502
+ 4.2.4 Reply codes after DATA and the subsequent CRLF.CRLF.
+ 4.3. Sequencing of Commands and Replies
+ 4.4 Trace information
+ 4.5. State Diagrams
+ 4.6. Details
+ 4.6.1. Minimum Implementation
+ 4.6.2. Transparency
+ 4.6.3. Sizes and Timeouts
+ 4.6.4 Queuing Strategies
+
+ 5. Address resolution and mail handling
+
+ 6. Problem detection and handling
+ 6.1 Replies by email
+ 6.2 Loop detection
+
+ 7. Security Considerations
+
+ 8. References
+
+ 9. Editor's addresses
+
+ 10. Acknowledgements
+
+ APPENDIX A: TCP
+ APPENDIX B: Generating SMTP commands from RFC 822 headers
+ APPENDIX E: Theory of Reply Codes
+ APPENDIX F: Scenarios
+ APPENDIX G: Other gateway issues.
+ APPENDIX H: Glossary
+ APPENDIX I: Deprecated features of RFC 821
+ APPENDIX X: Change summary and Loose ends (temporary)
+
+\f
+
+
+0. Abstract
+
+This document is a self-contained specification of the basic protocol
+for the Internet electronic mail transport, consolodating and
+updating
+
+ * the original SMTP specification of RFC 821 [RFC-821],
+ * Domain name system requirements and implications for mail
+ transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974],
+ * the clarifications and applicability statements in
+ RFC 1123 [RFC-1123], and
+ * material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It is intended to replace RFC 821, RFC 974, and the mail transport
+materials of RFC 1123. However, RFC 821 specifies some features that
+are not in significant use in the Internet of the mid-1990s and, in
+appendices, some additional transport models. Those sections are
+omitted in this document in the interest of clarity and brevity;
+readers needing them should refer to RFC 821.
+
+It also includes some additional material from RFC 1123 that appeared
+to need amplification. These have been identified in multiple ways,
+mostly by tracking flaming on the header-people list [HEADER-PEOPLE]
+and problems of unusual readings or interpretations that have turned
+up as the SMTP extensions have been deployed. It is important to
+note that everything here is in response to some identified confusion
+or bad behavior, not just paranoia.
+
+Where this specification moves beyond consolodation and actually
+differs from earlier documents, it supersedes them technically as
+well as textually.
+
+Although SMTP was designed as a mail transport and delivery protocol,
+this specification also contains information that is important to its
+use as a "mail posting" protocol, as recommended for POP [RFC-POP2,
+RFC-POP3] and IMAP [RFC-IMAP4].
+
+Except when the historical terminology is necessary for clarity, this
+document uses the current "client" and "server" terminology to
+identify the sending and receiving SMTP processes, respectively.
+
+A companion document discusses mail bodies and formats: RFC 822,
+MIME, and their relationship.
+
+1. INTRODUCTION
+
+The objective of the Simple Mail Transfer Protocol (SMTP) is to
+transfer mail reliably and efficiently.
+
+SMTP is independent of the particular transmission subsystem and
+requires only a reliable ordered data stream channel. While this
+document specifically discusses transport over TCP, other
+transports are possible. Appendices to RFC 821 describe some of
+them. A Glossary provides the definitions of terms as used in this
+document.
+
+An important feature of SMTP is its capability to transport mail
+across transport service environments, usually referred to as "mail
+gatewaying". A transport service environment might consist of the
+mutually-TCP-accessible hosts on the public internet, a
+firewall-isolated private TCP/IP LAN, or a LAN or WAN environment
+utilizing an entirely different transport-level protocol. It is
+important to realize that transport systems are not one-to-one with
+usual definitions of "networks". A process can communicate directly
+with another process, and mail communicated, through any mutually
+known transport layer. Conversely, mail can be relayed (actually
+gatewayed) between hosts on different transport systems by a host on
+both transport systems. The Mail eXchanger mechanisms of the domain
+name system [RFC-DNS, RFC974] usually permit relaying and gatewaying
+to occur invisibly to the user.
+
+
+2. THE SMTP MODEL
+
+2.1 Basic structure
+
+The SMTP design is based on the following model of communication: as
+the result of a user mail request (or transfer from a mail user agent
+(see section ##2.3)), the SMTP client establishes a two-way
+transmission channel to an SMTP server. Fully-capable client SMTPs
+determine the host address supporting the server SMTP function by
+resolving the domain name in the user request to it into either an
+intermediate mail exchanger host or a final target host. In other
+cases, common with clients associated with implementations of the POP
+[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the
+client is inside an isolated transport service enviroment, the SMTP
+client may send all of its traffic to a single SMTP server which, in
+turn, relays the mail to final (or other intermediate) destinations.
+Those destinations in turn support all of the queuing, retrying, and
+alternate address functions discussed in this specification. The SMTP
+server may be either the ultimate destination or an intermediate
+(i.e., may assume the role of an SMTP client after receiving the
+message). SMTP commands are generated by the SMTP client and sent to
+the SMTP server. SMTP replies are sent from the SMTP server to the
+SMTP client in response to the commands.
+
+Once the transmission channel is established and initial handshaking
+completed, the SMTP-client normally initiates a mail transaction.
+Such a transaction consists of a series of commands to specify the
+originator and destination of the mail and transmission of the
+message body (including any headers or other structure) itself. When
+the same message is sent to multiple recipients the SMTP encourages
+the transmission of only one copy of the data for all the recipients
+at the same destination (or intermediate relay) host.
+
+The server responds to each command with a reply; replies may
+indicate that the command was accepted, that additional commands are
+expected, or that a temporary or permanent error condition exists.
+Commands that specify the sender or recipients may include
+server-permitted SMTP service extension requests as discussed in
+section ##2.2. The dialog is purposely lock-step, one-at-a-time
+although this can be modified by mutually-agreed extension requests.
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+transactions.
+
+ -------------------------------------------------------------
+
+
+ +----------+ +----------+
+ +------+ | | | |
+ | User |<-->| | SMTP | |
+ +------+ | Sender- |Commands/Replies| Receiver-|
+ +------+ | SMTP |<-------------->| SMTP | +------+
+ | File |<-->| | and Mail | |<-->| File |
+ |System| | | | | |System|
+ +------+ +----------+ +----------+ +------+
+
+
+ SMTP client SMTP server
+
+ Model for SMTP Use
+
+ Figure 1
+
+ -------------------------------------------------------------
+
+Less commonly, the SMTP protocol and connection may be used by the
+client to request ancillary services of the server such as
+verification of addresses or exhibiting the contents of mailing
+lists.
+
+As suggested above, the SMTP provides mechanisms for the transmission
+of mail. This transmission occurs directly from the sending user's
+host to the receiving user's host when the two hosts are connected to
+the same transport service. When they are not connected to the same
+transport service, transmission occurs via one or more relay
+SMTP-servers. An intermediate host that will act as either an SMTP
+relay or as a gateway into some other transmission environment may
+also be selected through the use of the domain name service (DNS)
+Mail eXchanger mechanism.
+
+To be able to provide the relay capability the server SMTP is
+supplied with the name of the ultimate destination host as well as
+the destination mailbox name. Usually, intermediate hosts are
+determined via the DNS MX record, not by explicit "source" routing
+(see Appendix I).
+
+
+
+2.2 The Extension Model
+
+2.2.1 Background
+
+In an effort that started in 1990, approximately a decade after RFC
+821 was completed, the protocol was modified with a "service
+extensions" model that permits the client and server to agree to
+utilize shared functionality that goes beyond the original basic SMTP
+requirements. Contemporary SMTP implementations MUST support the
+basic extension mechanisms (see below for details), i.e., servers
+MUST support the EHLO command even if they do not implement any
+specific extensions and clients MUST preferentially utilize EHLO
+rather than HELO. However, for compatibility with older
+implementations (which are expected to persist for some years), SMTP
+clients and servers MUST support the original HELO mechanisms as a
+fallback.
+
+Although SMTP is widely and robustly deployed, some parts of the
+Internet community might wish to extend the SMTP service. The SMTP
+extension mechanism defines a means whereby an extended SMTP client
+and server may recognize each other as such and the server can inform
+the client as to the service extensions that it supports.
+
+It must be emphasized that any extension to the SMTP service should
+not be considered lightly. SMTP's strength comes primarily from its
+simplicity. Experience with many protocols has shown that:
+
+ protocols with few options tend towards ubiquity, whilst
+ protocols with many options tend towards obscurity.
+
+This means that each and every extension, regardless of its benefits,
+must be carefully scrutinized with respect to its implementation,
+deployment, and interoperability costs. In many cases, the cost of
+extending the SMTP service will likely outweigh the benefit.
+
+Given this environment, the extension framework consists of:
+
+ (1) The SMTP command EHLO, superseding the earlier HELO,
+
+ (2) a registry of SMTP service extensions, and
+
+ (3) additional parameters to the SMTP MAIL FROM and RCPT TO
+ commands.
+
+
+2.2.2 Definition and Registration of Extensions
+
+The IANA maintains a registry of SMTP service extensions.
+Associated with each such extension is a corresponding EHLO
+keyword value. Each service extension registered with the IANA
+must be defined in an RFC. Such RFCs must either be on the
+standards-track or must define an IESG-approved experimental
+protocol. The definition must include:
+
+ (1) the textual name of the SMTP service extension;
+
+ (2) the EHLO keyword value associated with the extension;
+
+ (3) the syntax and possible values of parameters associated
+ with the EHLO keyword value;
+
+ (4) any additional SMTP verbs associated with the extension
+ (additional verbs will usually be, but are not required
+ to be, the same as the EHLO keyword value);
+
+ (5) any new parameters the extension associates with the
+ MAIL FROM or RCPT TO verbs;
+
+ (6) how support for the extension affects the behavior of a
+ server and client SMTP; and,
+
+ (7) the increment by which the extension is increasing the
+ maximum length of the commands MAIL FROM, RCPT TO, or
+ both, over that specified in RFC 821.
+
+In addition, any EHLO keyword value that starts with an upper
+or lower case "X" refers to a local SMTP service extension,
+which is used through bilateral, rather than standardized,
+agreement. Keywords beginning with "X" may not be used in a
+registered service extension.
+
+Any keyword values presented in the EHLO response that do not begin
+with "X" must correspond to a standard, standards-track, or
+IESG-approved experimental SMTP service extension registered with
+IANA. A conforming server must not offer non-"X"-prefixed keyword
+values that are not described in a registered extension.
+
+Additional verbs are bound by the same rules as EHLO keywords;
+specifically, verbs begining with "X" are local extensions
+that may not be registered or standardized and verbs not
+beginning with "X" must always be registered.
+
+
+2.3 Terminology
+
+A glossary of terms appears at the end of this document. However,
+the following terms and concepts are used in special ways here, or
+represent differences in terminology between RFC 821 and this
+document, and should be understood before reading further.
+
+2.3.1 Mail objects
+
+SMTP relays a mail object containing an envelope and a content.
+
+ (1) The SMTP envelope is straightforward, and is sent as a
+ series of SMTP protocol units (described in section ##3): it
+ consists of an originator address (to which error reports
+ should be directed); a delivery mode (e.g., deliver to
+ recipient mailboxes); and, one or more recipient addresses.
+
+ (2) The SMTP content is sent in the SMTP DATA protocol unit
+ and has two parts: the headers and the body. The
+ headers form a collection of field/value pairs
+ structured according to RFC 822 [RFC822], whilst the body,
+ if structured, is defined according to MIME [3]. The
+ content is textual in nature, expressed using the US
+ ASCII repertoire (ANSI X3.4-1986). Although extensions
+ (such as MIME) may relax this restriction for the
+ content body, the content headers are always encoded
+ using the US ASCII repertoire. The algorithm defined in
+ [4] is used to represent header values outside the US
+ ASCII repertoire, whilst still encoding them using the
+ US ASCII repertoire.
+
+2.3.2. Sender and receivers
+
+In RFC 821, the two hosts participating in an SMTP transaction were
+described as the "SMTP-sender" and "SMTP-receiver". This document
+has been changed to reflect current industry terminology and hence
+refers to them as the "SMTP client" (or sometimes just "the client")
+and "SMTP server" (or just "the server") respectively. Since a given
+host may act both as server and client in a relay situation,
+"receiver" and "sender" terminology is still used where needed for
+clarity.
+
+2.3.3. Mail agents
+
+Other mail system terminology became common after RFC 821 was
+published and, where convenient, is used in this specification. In
+particular, SMTP servers and clients provide a mail transport service
+and therefore act as Mail Transfer Agents (MTAs). Mail User Agents
+(MUAs or UAs) are normally thought of as the sources and targets of
+mail. At the source, an MUA might collect mail to be transmitted
+from a user and hand it off to an MTA; the final ("delivery") MTA
+would be thought of as handing the mail off to an MUA (or at least
+transferring responsibility to it). However, while these terms are
+used with at least the appearance of great precision in other
+environments, the implied boundaries between MUAs and MTAs often do
+not accurately match common, and conforming, practices with Internet
+mail. Hence, the reader should be cautious about inferring the strong
+relationships and responsibilities that might be implied if these
+terms were used elsewhere.
+
+2.3.4 host
+
+<<placeholder>>
+
+2.3.5 domain
+
+<<placeholder>>
+
+2.3.6 buffer
+
+2.3.7 state table
+
+<<placeholder -- see "outstanding issues" list>>
+
+
+2.4 Syntax Principles
+
+
+2.4.1 General syntax and transaction model
+
+The mail commands and replies have a rigid syntax. Replies also have
+a numeric code. In the following, examples appear which use actual
+commands and replies. The complete lists of commands and replies
+appears in Section ##4 on specifications.
+
+Commands and replies are not case sensitive. That is, a command or
+reply word MAY be upper case, lower case, or any mixture of upper and
+lower case. Note that this is not true of mailbox user names. For
+some hosts the user name is case sensitive (this practice impedes
+interoperability and is discouraged), and SMTP implementations
+MUST take care to preserve the case of user names as they appear in
+mailbox arguments. Domain names are not case sensitive.
+
+Commands and replies are composed of characters from the ASCII
+character set [1]. When the transport service provides an 8-bit byte
+(octet) transmission channel, each 7-bit character is transmitted
+right justified in an octet with the high order bit cleared to zero.
+More specifically, the unextended SMTP service provides seven bit
+transport only. SMTP clients MUST NOT transmit messages with
+information in the high-order bit of octets. If such messages are
+transmitted in violation of this rule, receiving SMTP servers MAY
+clear the high-order bit or reject the message as invalid. Eight-bit
+transmission MAY be requested of the server by the client using
+extended SMTP facilities.
+
+The metalinguistic notation used in this document corresponds to the
+"Augmented BNF" used in other Internet mail system documents. The
+reader who is not familiar with that syntax should consult [ABNF].
+
+
+2.4.2 Command and reply syntax
+
+The commands consist of a command code followed by an argument field.
+Command codes are four alphabetic characters. Upper and lower case
+alphabetic characters are to be treated identically. Thus, any of
+the following may represent the mail command:
+
+ MAIL Mail mail MaIl mAIl
+
+This also applies to any symbols representing parameter values, such
+as "TO" or "to" for the forward-path. Command codes and the argument
+fields are separated by one or more spaces. However, within the
+reverse-path and forward-path arguments case is important. In
+particular, in some hosts the user "smith" is different from the user
+"Smith".
+
+The argument field consists of a variable length character string
+ending with the character sequence <CRLF>. The receiver is to take
+no action until this sequence is received.
+
+The syntax for each command is shown with the discussion of that
+command. Common elements and parameters are shown in section
+##4.1.2.
+
+
+
+3. THE SMTP PROCEDURES: AN OVERVIEW
+
+This section presents the procedures used in SMTP in several parts.
+After a review of session initiation by the server and client, there
+is the basic mail procedure defined as a mail transaction. Following
+this are descriptions of forwarding mail, verifying mailbox names and
+expanding mailing lists, and the opening and closing exchanges. At
+the end of this section are comments on relaying, a note on mail
+domains, and a discussion of changing roles. Throughout this section
+are examples of partial command and reply sequences, several complete
+scenarios are presented in Appendix F.
+
+
+3.1 Session initiation
+
+An SMTP session is initiated by the client opening a connection to
+the server and the server responding with an opening message.
+
+SMTP server implementations SHOULD include identification of their
+software and version information in the connection greeting reply
+after the 220 code. This practice permits much more efficient
+isolation and repair of any problems. While some systems also
+identify their contact point for mail problems, this is not a
+substitute for maintaining the required Postmaster address (see
+[RFC822]). Implementations MAY make provision for SMTP servers to be
+configured to disable the software and version announcement where it
+causes security concerns.
+
+3.2 Client initiation: EHLO
+
+The client then sends the EHLO command to the server, indicating its
+identity. In addition to opening the session, use of EHLO indicates
+that the client is able to process service extensions and requests
+that the server provide a list of the extensions it supports. Older
+SMTP systems, unable to support service extensions, MAY use HELO
+instead of EHLO but EHLO SHOULD be used by all current clients and
+accepted by all current systems.
+
+In the EHLO, or the older HELO, command the host sending the command
+identifies itself; the command may be interpreted as saying "Hello, I
+am <domain>" (and, in the case of EHLO, "and I support service
+extension requests").
+
+ -------------------------------------------------------------
+ |
+ | Example of Connection Opening
+ |
+ | R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+ | S: HELO USC-ISIF.ARPA
+ | R: 250 BBN-UNIX.ARPA
+ |
+ | Example 5
+ |
+ -------------------------------------------------------------
+
+ -------------------------------------------------------------
+ |
+ | Example of Connection Closing
+ |
+ | S: QUIT
+ | R: 221 BBN-UNIX.ARPA Service closing transmission channel
+ |
+ | Example 6
+ |
+ -------------------------------------------------------------
+
+
+3.3. Mail Transactions
+
+There are three steps to SMTP mail transactions. The transaction
+is started with a MAIL command which gives the sender
+identification. A series of one or more RCPT commands follows
+giving the receiver information. Then a DATA command gives the
+mail data. And finally, the end of mail data indicator confirms
+the transaction.
+
+ The first step in the procedure is the MAIL command. The
+ <reverse-path> contains the source mailbox.
+
+ MAIL <SP> FROM:<reverse-path> [<SP> <mail-parameters>] <CRLF>
+
+ This command tells the SMTP-receiver that a new mail
+ transaction is starting and to reset all its state tables and
+ buffers, including any recipients or mail data. It gives the
+ reverse-path which can be used to report errors (see section
+ ##4.2 for a discussion of error reporting). If accepted, the
+ SMTP server returns a 250 OK reply.
+
+ The <reverse-path> can contain more than just a mailbox. The
+ <reverse-path> is a reverse source routing list of hosts and
+ source mailbox. The first host in the <reverse-path> should be
+ the host sending this command.
+
+ The optional <mail-parameters> are associated with negotiated SMTP
+ service extensions (see section ##2.2).
+
+ The second step in the procedure is the RCPT command.
+
+ RCPT <SP> TO:<forward-path> [<SP> <rcpt-parameters>] <CRLF>
+
+ This command gives a forward-path (normally a mailbox and domain)
+ identifying one recipient. If accepted, the SMTP server returns a
+ 250 OK reply, and stores the forward-path. If the recipient is
+ unknown the SMTP server returns a 550 Failure reply (other
+ circumstances and reply codes are possible). This second step of
+ the procedure can be repeated any number of times. The
+ <forward-path> can contain more than just a mailbox. The
+ <forward-path> may be a source routing list of hosts and the
+ destination mailbox. However, in general, the <forward-path>
+ should contain only a mailbox and domain name, relying on the
+ domain name system to supply routing information if required.
+ Servers MUST be prepared to encounter a list of source routes in
+ the forward path, but MAY ignore the routes or decline to support
+ the relaying they imply. Similarly, servers MAY decline to accept
+ mail that is destined for other hosts or systems. Of course, such
+ a restrictions would make a server useless as a relay for clients
+ that do not support full SMTP functionality, but such clients MUST
+ NOT assume that any SMTP server on the Internet can be used as
+ their mail processing site.
+
+ Clients SHOULD NOT utilize explicit source routing except as
+ discussed in Appendix I.
+
+ The optional <mail-parameters> are associated with negotiated SMTP
+ service extensions (see section ##2.2).
+
+ The third step in the procedure is the DATA command.
+
+ DATA <CRLF>
+
+ If accepted, the SMTP server returns a 354 Intermediate reply
+ and considers all succeeding lines to be the message text.
+ When the end of text is received and stored the SMTP-receiver
+ sends a 250 OK reply.
+
+ Since the mail data is sent on the transmission channel, the end
+ of the mail data must be indicated so that the command and
+ reply dialog can be resumed. SMTP indicates the end of the
+ mail data by sending a line containing only "." (period or
+ full stop). A transparency procedure is used to prevent
+ this from interfering with the user's text (see Section ##4.5.2).
+
+ The end of mail data indicator also confirms the mail transaction
+ and tells the SMTP server to now process the stored recipients and
+ mail data. If accepted, the SMTP server returns a 250 OK reply.
+ The DATA command should fail only if the mail transaction was
+ incomplete (for example, no recipients), or if resources are not
+ available. However, some servers in practice do not perform
+ recipient verification until after the message text is received.
+ These servers SHOULD treat a failure for one or more recipients as
+ a "subsequent failure" and return a mail message as discussed in
+ section ##<<>>. Using a "recipient not found" or equivalent
+ reply code after the data are accepted makes it difficult or
+ impossible for the client to determine which recipients failed.
+
+ Please note that, when RFC 822 format is being used, the mail data
+ includes the memo header items such as Date, Subject, To, Cc, From
+ [RFC822]. Server SMTP systems SHOULD NOT reject messages based on
+ perceived defects in the RFC 822 or MIME [MIME] message header or
+ message body. In particular, they MUST NOT reject messages on the
+ basis of trying to match numbers of Resent- fields. In
+ particular, messages MUST NOT be rejected because Resent-to
+ appears without Resent-from, Resent-date, or both.
+
+
+The above procedure is an example of a mail transaction. These
+commands must be used only in the order discussed above.
+Example 1 (below) illustrates the use of these commands in a mail
+transaction.
+
+
+ -------------------------------------------------------------
+ |
+ | Example of the SMTP Procedure
+ |
+ | This SMTP example shows mail sent by Smith at host Alpha.ARPA,
+ | to Jones, Green, and Brown at host Beta.ARPA. Here we assume
+ | that host Alpha contacts host Beta directly.
+ |
+ | S: MAIL FROM:<Smith@Alpha.ARPA>
+ | R: 250 OK
+ |
+ | S: RCPT TO:<Jones@Beta.ARPA>
+ | R: 250 OK
+ |
+ | S: RCPT TO:<Green@Beta.ARPA>
+ | R: 550 No such user here
+ |
+ | S: RCPT TO:<Brown@Beta.ARPA>
+ | R: 250 OK
+ |
+ | S: DATA
+ | R: 354 Start mail input; end with <CRLF>.<CRLF>
+ | S: Blah blah blah...
+ | S: ...etc. etc. etc.
+ | S: <CRLF>.<CRLF>
+ | R: 250 OK
+ |
+ | The mail has now been accepted for Jones and Brown. Green did
+ | not have a mailbox at domain Beta.ARPA.
+ |
+ | Example 1
+ |
+ -------------------------------------------------------------
+
+
+
+3.4. Forwarding for Address Correction or Updating
+
+The "forwarding" mechanisms described in section 3.2 of RFC 821, and
+especially the 251 reply code from RCPT that indicates a corrected
+destination, are no longer in active use. Forwarding support is most
+often required to consolodate and simplify addresses within, or
+relative to, some enterprise. In most of those cases, information
+hiding (and sometimes security) considerations argue against exposure
+of the "final" address through the SMTP protocol as a consequence of
+the forwarding activity and, in some cases, that final address may
+not even be reachable by the sender.
+
+Silent forwarding of messages (without server notification to the
+sender) is common in the contemporary Internet.
+
+If the forwarding and address correction mechanisms described in
+RFC 821 are used, the addresses given should be stable enough that
+it would be reasonable for the client to update local records with
+them.
+
+
+3.5. Verifying and Expanding
+
+3.5.1 Overview
+
+SMTP provides, as additional features, commands to verify a user
+name or expand a mailing list. This is done with the VRFY and
+EXPN commands, which have character string arguments. For the
+VRFY command, the string is a user name (see below) and the
+response may include the full name of the user and must include
+the mailbox of the user, e.g., it MUST BE in either
+ User Name <mailbox@domain>
+or
+ mailbox@domain
+form.
+
+Paths (explicit source routes) MUST NOT be returned by VRFY or
+EXPN.
+
+When a name that is the argument to VRFY could identify more
+than one mailbox, the server MAY either note the ambiguity or
+identify the alternatives. In other words, either of the
+following are legitimate response to VRFY:
+
+ 553 User ambiguous
+ or
+ 553- Ambiguous; Possibilities are
+ 553-Joe Smith <jsmith@somedomain>
+ 553-Harry Smith <hsmith@somedomain>
+ 553 Melvin Smith <dweep@somedomain>
+
+Under normal circumstances a client receiving a 553 reply
+would be expected to expose the result to the user. Use
+of exactly the forms given, and the "user ambiguous" or
+"ambiguous" keywords, will facilitate automated
+translation into other languages as needed.
+
+For the EXPN command, the string identifies a mailing
+list, and the multiline response may include the full name of the
+users and must give the mailboxes on the mailing list.
+
+"User name" is a fuzzy term and used purposely. An
+implementation of the VRFY or EXPN commands MUST include at
+least recognition of local mailboxes as "user names". If a
+host chooses to recognize other strings as "user names" that is
+allowed.
+
+In some hosts the distinction between a mailing list and an alias
+for a single mailbox is a bit fuzzy, since a common data structure
+may hold both types of entries, and it is possible to have mailing
+lists of one mailbox. If a request is made to verify a mailing
+list a positive response can be given if on receipt of a message
+so addressed it will be delivered to everyone on the list,
+otherwise an error should be reported (e.g., "550 That is a
+mailing list, not a user"). If a request is made to expand a user
+name a positive response can be formed by returning a list
+containing one name, or an error can be reported (e.g., "550 That
+is a user name, not a mailing list").
+
+In the case of a multiline reply (normal for EXPN) exactly one
+mailbox is to be specified on each line of the reply. The case
+of an ambiguous request is discussed above.
+
+The case of verifying a user name is straightforward as shown in
+example 3.
+
+
+ -----------------------------------------------------------------
+ |
+ | Example of Verifying a User Name
+ |
+ | Either
+ |
+ | S: VRFY Smith
+ | R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
+ |
+ | Or
+ |
+ | S: VRFY Smith
+ | R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
+ |
+ | Or
+ |
+ | S: VRFY Jones
+ | R: 550 String does not match anything.
+ |
+ | Or
+ |
+ | S: VRFY Jones
+ | R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
+ |
+ | Or
+ |
+ | S: VRFY Gourzenkyinplatz
+ | R: 553 User ambiguous.
+ |
+ | Example 3
+ |
+ -----------------------------------------------------------------
+
+ The case of expanding a mailbox list requires a multiline reply as
+ shown in example 4.
+
+ -------------------------------------------------------------
+ |
+ | Example of Expanding a Mailing List
+ |
+ | Either
+ |
+ | S: EXPN Example-People
+ | R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
+ | R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+ | R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
+ | R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ | R: 250-<joe@foo-unix.ARPA>
+ | R: 250 <xyz@bar-unix.ARPA>
+ |
+ | Or
+ |
+ | S: EXPN Executive-Washroom-List
+ | R: 550 Access Denied to You.
+ |
+ | Example 4
+ |
+ -------------------------------------------------------------
+
+ The character string arguments of the VRFY and EXPN commands
+ cannot be further restricted due to the variety of implementations
+ of the user name and mailbox list concepts. On some systems it
+ may be appropriate for the argument of the EXPN command to be a
+ file name for a file containing a mailing list, but again there is
+ a variety of file naming conventions in the Internet.
+
+
+3.5.2 VRFY normal response.
+
+When normal (2yz or 551) responses are returned from a VRFY or EXPN
+request, the reply MUST include the mailbox name, e.g., "<foo@bar>"
+(where "bar" is a fully qualified domain name) must appear in the
+syntax. EXPN and VRFY MUST return only valid domain addresses that
+are usable in SMTP RCPT commands. Consequently, if an address
+implies delivery to a program or other system, the mailbox name used
+to reach that target should be given.
+
+Server implementations MUST support VRFY and SHOULD support EXPN. For
+security reasons, implementations MAY provide local installations a
+way to disable either or both of these commands through configuration
+options or the equivalent. When these commands are supported, they
+are not required to work across relays when relaying is supported.
+Since they were both optional in RFC 821, they MUST, if supported, be
+listed in the response to EHLO if service extensions are supported.
+
+
+3.5.3 Meaning of VRFY or EXPN success response.
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN
+command unless it has actually verified the address. In particular,
+a server MUST NOT return 220 if all it has done is to verify that the
+syntax given is valid. In that case 502 (Command not implemented) or
+500 (Syntax error, command unrecognized) SHOULD be returned (note
+that implementation of VRFY is required by RFC 1123 and EXPN is
+strongly recommended; this specification does not change that
+requirement and, hence, except as provided in section ##3.5.5,
+implementations that return 500 or 502 for VRFY are not in compliance
+with the specification).
+
+Especially when a server is acting as a mail exchanger for another,
+there may be circumstances where an address appears to be correct but
+cannot reasonably be verified in real time. In that situation, reply
+code 252 SHOULD BE returned. These cases parallel the discussion of
+RCPT verification discussed in section ##2.1 although implementations
+generally SHOULD be more aggressive about address verification in the
+case of VRFY than in the case of RCPT even if a little more time is
+required to do so.
+
+
+3.5.4. Semantics and applications of EXPN.
+
+While EXPN is often very useful in debugging and understanding
+problems with mailing lists and multiple-target-address aliases,
+some systems have attempted to use source expansion of mailing
+lists as a means of eliminating duplicates. The propagation of
+aliasing systems with mail on the Internet--both for hosts
+(typically with MX and CNAME DNS records) and for mailboxes
+(various types of local host aliases) has made it nearly
+impossible for these strategies to work, and mail systems SHOULD
+NOT attempt them.
+
+
+3.5.5 VRFY, EXPN, and security.
+
+As discussed above, individual sites may want to disable one or both
+of VRFY or EXPN for security reasons. As a corollary to the above,
+implementations that permit this MUST NOT appear to have verified
+addresses that are not, in fact, verified. If a site disables these
+commands for security reasons, the SMTP server SHOULD return a 252
+response, rather than a code that could be confused with successful
+or unsuccessful verification.
+
+Returning a 250 reply code with the address listed in the VRFY
+command after having checked it for syntax only violates this
+rule. Of course, an implementation that "supports" VRFY by
+always returning 550 whether or not the address is valid is
+equally not in conformance.
+
+
+
+3.6. Domains
+
+Domains have become a key concept in the Internet mail system. The
+use of domains changes the address space from a flat global space of
+simple character string host names to a hierarchically structured
+rooted tree of global addresses. The host name is replaced by a
+domain and host designator which is a sequence of domain element
+strings separated by periods with the understanding that the domain
+elements are ordered from the most specific to the most general.
+
+For example, "ISIF.ISI.EDU", "Fred.Cambridge.UK", and
+"PC7.LCS.MIT.EDU" might be domain identifiers.
+
+Whenever domain names are used in SMTP, only resolvable,
+fully-qualified, domain names (FQDNs) are permitted. In other words,
+names that can be resolved to MX RRs or A RRs (as discussed in
+section ##5.??.??) are permitted, as are CNAME RRs whose targets can
+be resolved, in turn, to MX or A RRs. Local nicknames or unqualified
+names MUST NOT be used. There is one exception to this rule: the
+domain name given in the EHLO (or HELO) command MUST BE either a
+primary host name (a domain name that resolves to an A RR) or, if the
+host has no name, a domain literal in dotted-decimal notation.
+
+
+
+3.7. RELAYING
+
+The forward-path may be a source route of the form
+"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE
+fully-qualified domain names. This form is used to emphasize the
+distinction between an address and a route. The mailbox is an
+absolute address, and the route is information about how to get
+there. The two concepts should not be confused.
+
+In general, the availability of Mail eXchanger records in the
+domain name system [RFC-DNS] makes the use of explicit source
+routes in the Internet mail system unnecessary. Many historical
+problems with their interpretation have made their use
+undesirable. SMTP clients SHOULD NOT generate explicit source
+routes except under unusual circumstances. SMTP servers MAY
+decline to act as mail relays or to accept addresses that
+specify source routes. They are also permitted to ignore the route
+information and simply send to the final destination as specified in
+the route and the DNS. However, there has been a practice, albeit
+invalid, of using names that do not appear in the DNS as destination
+names, with the senders counting on the intermediate hosts specified
+in source routing to resolve any problems. If source routes are
+stripped, this practice will cause failures -- one of several reasons
+why SMTP clients MUST NOT generate invalid source routes or depend on
+serial resolution of names.
+
+If source routes are not used, the process described in RFC 821 for
+constructing a reverse-path from the forward-path is not applicable
+and the reverse-path at the time of delivery will simply be the
+address that appeared in the MAIL command. If source routes are
+used, RFC 821 should be consulted for the mechanisms for constructing
+and updating the forward- and reverse-paths.
+
+Using source routing the SMTP server receives mail to be relayed to
+another SMTP server. The SMTP server may accept or reject the task
+of relaying the mail in the same way it accepts or rejects mail for a
+local user. The SMTP server transforms the command arguments by
+moving its own identifier (its domain name or that of any domain for
+which it is acting as a mail exchanger), if it appears, from the
+forward-path to the beginning of the reverse-path. The SMTP server
+then becomes an SMTP client, establishes a transmission channel to
+the next SMTP server in the forward-path, and sends it the mail.
+
+Notice that the forward-path and reverse-path appear in the SMTP
+commands and replies, but not necessarily in the message. That is,
+there is no need for these paths and especially this syntax to appear
+in the "To:" , "From:", "CC:", etc. fields of the message header.
+Conversely, SMTP servers MUST NOT derive final message delivery
+information from message header fields.
+
+If an SMTP server has accepted the task of relaying the mail and
+later finds that the forward-path is incorrect or that the mail
+cannot be delivered for some other reason, then it MUST construct an
+"undeliverable mail" notification message and send it to the
+originator of the undeliverable mail (as indicated by the
+reverse-path). Formats specified for non-delivery reports by other
+standards SHOULD be used if possible.
+
+This notification message must be from the SMTP server at the relay
+host or the host that first determines that delivery cannot be
+accomplished. Of course, SMTP servers should not send notification
+messages about problems with notification messages. One way to
+prevent loops in error reporting is to specify a null reverse-path in
+the MAIL command of a notification message. When such a message is
+transmitted the reverse-path SHOULD BE set to null. A MAIL command
+with a null reverse-path appears as follows:
+
+ MAIL FROM:<>
+
+An undeliverable mail notification message is shown in example 7.
+This notification is in response to a message originated by JOE at
+HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
+to HOSTZ. What we see in the example is the transaction between
+HOSTY and HOSTX, which is the first step in the return of the
+notification message.
+
+ -------------------------------------------------------------
+ |
+ | Example Undeliverable Mail Notification Message
+ |
+ | S: MAIL FROM:<>
+ | R: 250 ok
+ | S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
+ | R: 250 ok
+ | S: DATA
+ | R: 354 send the mail data, end with .
+ | S: Date: 23 Oct 81 11:22:33
+ | S: From: SMTP@HOSTY.ARPA
+ | S: To: JOE@HOSTW.ARPA
+ | S: Subject: Mail System Problem
+ | S:
+<<>>replace with NOTARY format <<>>
+ | S: .
+ | R: 250 ok
+ |
+ | Example 7
+ |
+ -------------------------------------------------------------
+
+
+
+
+
+3.8. Terminating Sessions and Connections
+
+An SMTP connection is terminated by the client's sending a QUIT
+command. The server then responds with a positive reply code, after
+which it closes the connection.
+
+ An SMTP server MUST NOT intentionally close the connection
+ except:
+ o After receiving a QUIT connand and responding with a 221 reply.
+ o After detecting the need to shutdown the SMTP service and
+ returning a 451 reply to any command.
+
+ In particular, a server that closes connections in response
+ to commands that are not understood is in violation of this
+ specification. Instead, servers are expected to be tolerant of
+ unknown commands, issuing a 500 reply and awaiting further
+ instructions from the client.
+
+ An SMTP server which is forcibly shut down via external
+ means SHOULD attempt to send a line containing 451 response
+ code to the SMTP client before exiting. The SMTP client will
+ normally read the 451 response code after sending its next
+ command.
+
+
+
+
+4. THE SMTP SPECIFICATIONS
+
+4.1. SMTP COMMANDS
+
+4.1.1. COMMAND SEMANTICS AND SYNTAX
+
+The SMTP commands define the mail transfer or the mail system
+function requested by the user. SMTP commands are character strings
+terminated by <CRLF>. The command codes themselves are alphabetic
+characters terminated by <SP> if parameters follow and <CRLF>
+otherwise. The syntax of mailboxes must conform to receiver site
+conventions. The SMTP commands are discussed below. The SMTP
+replies are discussed in Section ##4.2.
+
+A mail transaction involves several data objects which are
+communicated as arguments to different commands. The reverse-path is
+the argument of the MAIL command, the forward-path is the argument of
+the RCPT command, and the mail data is the argument of the DATA
+command. These arguments or data objects must be transmitted and
+held pending the confirmation communicated by the end of mail data
+indication which finalizes the transaction. The model for this is
+that distinct buffers are provided to hold the types of data objects,
+that is, there is a reverse-path buffer, a forward-path buffer, and a
+mail data buffer. Specific commands cause information to be appended
+to a specific buffer, or cause one or more buffers to be cleared.
+
+
+4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
+
+These commands are used to identify the SMTP client to the SMTP
+server. The argument field contains the host name of the SMTP
+client.
+
+The SMTP server identifies itself to the SMTP client in the
+connection greeting reply, and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO
+command. If the SMTP server supports the SMTP service extensions it
+will give a successful response, a failure response, or an error
+response. If the SMTP server does not support any SMTP service
+extensions it will generate an error response. Older client SMTP
+systems MAY, as discussed above, use HELO (as specified in RFC 821)
+instead of EHLO.
+
+These commands and an OK reply to one of them confirm that both the
+SMTP client and the SMTP server are in the initial state, that is,
+there is no transaction in progress and all state tables and buffers
+are cleared.
+
+If the server SMTP implements and is able to perform the EHLO
+command, it will return code 250. This indicates that both the
+server and client SMTP are in the initial state, that is, there is no
+transaction in progress and all state tables and buffers are cleared.
+
+Normally, this response will be a multiline reply. Each line of the
+response contains a keyword and, optionally, one or more parameters.
+The syntax for a positive response, using the ABNF notation of
+[RFC822], is:
+
+ ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF
+ / ( "250-" domain [ SP greeting ] CR LF
+ *( "250-" ehlo-line CR LF )
+ "250" SP ehlo-line CR LF )
+
+ ; the usual HELO chit-chat
+ greeting ::= 1*<any character other than CR or LF>
+
+ ehlo-line ::= ehlo-keyword *( SP ehlo-param )
+
+ ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+ ; syntax and values depend on ehlo-keyword
+ ehlo-param ::= 1*<any CHAR excluding SP and all
+ control characters (US ASCII 0-31
+ inclusive)>
+
+ ALPHA ::= <any one of the 52 alphabetic characters
+ (A through Z in upper case, and,
+ a through z in lower case)>
+ DIGIT ::= <any one of the 10 numeric characters
+ (0 through 9)>
+
+ CR ::= <the carriage-return character
+ (ASCII decimal code 13)>
+ LF ::= <the line-feed character
+ (ASCII decimal code 10)>
+ SP ::= <the space character
+ (ASCII decimal code 32)>
+
+Although EHLO keywords may be specified in upper, lower, or mixed
+case, they must always be recognized and processed in a
+case-insensitive manner. This is simply an extension of practices
+specified in RFC 821.
+
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail
+data is delivered to one or more mailboxes. The argument field
+contains a reverse-path.
+
+The reverse-path consists of an optional list of hosts and the sender
+mailbox. When the list of hosts is present, it is a "reverse" source
+route and indicates that the mail was relayed through each host on
+the list (the first host in the list was the most recent relay).
+This list is used as a source route to return non-delivery notices to
+the sender. As each relay host adds itself to the beginning of the
+list, it must use its name as known in the transport environment to
+which it is relaying the mail rather than that of the transport
+environment from which the mail came (if they are different). In
+some types of error reporting messages (for example, undeliverable
+mail notifications) the reverse-path may be null (see Example 7).
+
+This command clears the reverse-path buffer, the forward-path buffer,
+and the mail data buffer; and inserts the reverse-path information
+from this command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also
+carry parameters associated with a particular service extension.
+
+Syntax: "MAIL FROM:" Reverse-path [ Mail-parameters ]
+ or
+ "MAIL FROM:<>"
+
+
+4.1.1.3 RECIPIENT (RCPT)
+
+This command is used to identify an individual recipient of
+the mail data; multiple recipients are specified by multiple
+use of this command.
+
+The forward-path consists of an optional list of hosts and a
+required destination mailbox. When the list of hosts is
+present, it is a source route and indicates that the mail
+must be relayed to the next host on the list. If the
+SMTP server does not implement the relay function it may
+user the same reply it would for an unknown local user
+(550).
+
+When mail is relayed, the relay host must remove itself from
+the beginning forward-path and put itself at the beginning
+of the reverse-path. When mail reaches its ultimate
+destination (the forward-path contains only a destination
+mailbox), the SMTP server inserts it into the destination
+mailbox in accordance with its host mail conventions.
+
+
+ For example, mail received at relay host A with arguments
+
+ FROM:<USERX@HOSTY.ARPA>
+ TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
+
+ will be relayed on to host B with arguments
+
+ FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
+ TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
+
+This command causes its forward-path argument to be appended
+to the forward-path buffer.
+
+If service extensions were negotiated, the MAIL command may also
+carry parameters associated with a particular service extension.
+
+Syntax: "RCPT TO:" Forward-path [ Rcpt-parameters ]
+
+
+4.1.1.4 DATA (DATA)
+
+The receiver treats the lines (strings ending in CRLF sequences)
+following the command as mail data from the sender. This command
+causes the mail data from this command to be appended to the mail
+data buffer. The mail data may contain any of the 128 ASCII
+character codes.
+
+SMTP is defined in terms of sending messages consisting of lines of
+text. Lines are strictly defined as ending in ASCII CR LF sequences.
+Systems that use other line delimiting mechanisms internally MUST
+convert to CR LF sequences before transmitting mail with unextended
+SMTP or with any SMTP service extension on the standards track as of
+the time of this writing.
+
+The mail data is terminated by a line containing only a period, that
+is the character sequence "<CRLF>.<CRLF>" (see Section ##4.6.2 on
+Transparency). This is the end of mail data indication.
+
+The custom of accepting lines ending only in LF, as a concession to
+non-conforming behavior on the part of some UNIX systems, has proven
+to cause more interoperability problems than it solves and SMTP
+server systems MUST NOT do this, even in the name of improved
+robustness. In particular, the sequence "LF.LF" (bare line feeds,
+without carriage returns) MUST NOT be treated as equivalent to
+CRLF.CRLF as the end of mail data indication.
+
+
+Receipt of the end of mail data indication requires that the server
+process the stored mail transaction information. This processing
+consumes the information in the reverse-path buffer, the forward-path
+buffer, and the mail data buffer, and on the completion of this
+command these buffers are cleared. If the processing is successful
+the receiver must send an OK reply. If the processing fails
+completely the receiver must send a failure reply.
+
+When the SMTP server accepts a message either for relaying or for
+final delivery it inserts a trace record (also referred to
+interchangabily as a "time stamp line" or "Received" line) at the top
+of the mail data. This trace record indicates the identity of the
+host that sent the message, and the identity of the host that
+received the message (and that is inserting this time stamp), and the
+date and time the message was received. Relayed messages will have
+multiple time stamp lines. Details for formation of these lines,
+including their syntax, is specified in section ##4.4.
+
+
+4.1.1.5 RESET (RSET)
+
+This command specifies that the current mail transaction is to be
+aborted. Any stored sender, recipients, and mail data must be
+discarded, and all buffers and state tables cleared. The receiver
+must send an OK reply. A reset command may be issued by the client
+at any time. It is effectively equivalent to a NOOP if issued
+immediately after EHLO or HELO, or before either of those commands
+have been issued. In other situations, it restores the state to
+that immediately after the most recent EHLO or HELO. An SMTP server
+MUST NOT close the connection as the result of receiving a RSET; that
+action is reserved for QUIT (see section ##4.1.1.10, below).
+
+4.1.1.6 VERIFY (VRFY)
+
+This command asks the receiver to confirm that the argument
+identifies a user. If it is a user name, the full name of
+the user (if known) and the fully specified mailbox are
+returned.
+
+This command has no effect on any of the reverse-path
+buffer, the forward-path buffer, or the mail data buffer.
+
+Syntax: "VRFY" SP String
+
+4.1.1.7 EXPAND (EXPN)
+
+This command asks the receiver to confirm that the argument
+identifies a mailing list, and if so, to return the
+membership of that list. The full name of the users (if
+known) and the fully specified mailboxes are returned in a
+multiline reply.
+
+This command has no effect on any of the reverse-path
+buffer, the forward-path buffer, or the mail data buffer.
+
+Syntax: "EXPN" SP String
+
+4.1.1.8 HELP (HELP)
+
+This command causes the receiver to send helpful information
+to the sender of the HELP command. The command MAY take an
+argument (e.g., any command name) and return more specific
+information as a response.
+
+This command has no effect on any of the reverse-path
+buffer, the forward-path buffer, or the mail data buffer.
+
+SMTP servers SHOULD support HELP even if the form with an argument
+is not supported.
+
+Syntax: "HELP" [ SP String ]
+
+
+4.1.1.9 NOOP (NOOP)
+
+This command does not affect any parameters or previously
+entered commands. It specifies no action other than that
+the receiver send an OK reply.
+
+This command has no effect on any of the reverse-path
+buffer, the forward-path buffer, or the mail data buffer.
+
+Syntax: "NOOP" [SP String]
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver must send an OK
+reply, and then close the transmission channel.
+
+The receiver MUST NOT intentionally close the transmission channel
+until it receives and replies to a QUIT command (even if there was
+an error). The sender MUST NOT intentionally close the
+transmission channel until it send a QUIT command and receives the
+reply (even if there was an error response to a previous command).
+If the connection is closed prematurely due to violations of the
+above or system or network failure the server MUST act as if a
+RSET command had been received (cancelling any pending
+transaction, but not undoing any previously completed transaction)
+and the client MUST act as if the command or transaction in
+progress had received a temporary error (4xx).
+
+Syntax: "QUIT"
+
+
+4.1.2. LOWER-LEVEL SYNTAX
+
+The syntax of the argument fields of the above commands (using the
+syntax specified in [ABNF] where applicable) is given below.
+
+ Reverse-path ::= Path
+
+ Forward-path ::= Path
+
+ Path ::= "<" [ A-d-l ":" ] <mailbox> ">"
+
+ A-d-l ::= At-domain *( "," A-d-l )
+
+ At-domain ::= "@" Domain
+
+ Mail-parameters ::= *( SP Keyword "=" Argument )
+
+ Rcpt-parameters ::= *( SP Keyword "=" Argument )
+
+ Keyword ::= String <<>>???
+ Argument ::= String <<>>???
+
+ Domain ::= sub-domain 1*("." sub-domain) | domain-literal
+
+ sub-domain ::= let-dig *(ldh-str)
+ domain-literal = "[" IP-address-literal "]"
+ IP-address-literal = snum 3*("." snum)
+ snum = one, two, or three digits representing a decimal
+ integer value in the range 0 through 255
+ let-dig = Alpha / Digit
+ ldh-str = *( Alpha / Digit / "-" ) 1*(let-dig)
+
+ Alpha = ASCII character in the range A-Z or a-z. As specified in
+ the domain name system definition [RFC-DNS], case is not
+ significant in domain strings.
+ Digit = 0 - 9
+
+
+ Mailbox ::= Local-part "@" Domain
+
+ Local-part ::= Dot-string | Quoted-string
+
+ While the definition for Local-part above is relatively
+permissive, for maximum interoperability, a host that expects to
+receive mail SHOULD avoid defining mailboxes where the Local-part
+requires (or uses) the Quoted-string form or where the Local-part
+is case-sensitive.
+
+Systems MUST NOT define mailboxes in such a way as to require the use
+of non-ASCII characters (octets with the high order bit set to one)
+or ASCII "control characters" (decimal value 0-31 and 127). These
+characters MUST NOT be used in MAIL FROM or RCPT TO commands or other
+commands that require mailbox names.
+
+
+<<?>> <string> ::= <char> | <char> <string>
+
+<<?>> <quoted-string> ::= """ <qtext> """
+
+<<?>> <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+ <char> ::= <c> | "\" <x>
+
+ <number> ::= <d> | <d> <number>
+
+ <CRLF> ::= <CR> <LF>
+
+ <CR> ::= the carriage return character (ASCII code 13)
+
+ <LF> ::= the line feed character (ASCII code 10)
+
+ <SP> ::= the space character (ASCII code 32)
+
+ <snum> ::= one, two, or three digits representing a decimal
+ integer value in the range 0 through 255
+
+ <a> ::= any one of the 52 alphabetic characters A through Z
+ in upper case and a through z in lower case
+
+ <c> ::= any one of the 128 ASCII characters, but not any
+ <special> or <SP>
+
+ <d> ::= any one of the ten digits 0 through 9
+
+ <q> ::= any one of the 128 ASCII characters except <CR>,
+ <LF>, quote ("), or backslash (\)
+
+ <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+ <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
+ | "," | ";" | ":" | "@" """ | the control
+ characters (ASCII codes 0 through 31 inclusive and
+ 127)
+
+Note that the backslash, "\", is a quote character, which is
+used to indicate that the next character is to be used
+literally (instead of its normal interpretation). For example,
+"Joe\,Smith" could be used to indicate a single nine character
+user field with comma being the fourth character of the field.
+
+Characters outside the set of specials, alphas, digits, and hyphen
+are prohibited by the domain name system definition and MUST NOT
+appear in domain names. In particular, the underscore character is
+not permitted.
+
+Sometimes a host is not known to the translation function and
+communication is blocked. To bypass this barrier a numeric form is
+also allowed for host "names". This form uses four or more small
+decimal integers separated by dots and enclosed by brackets, e.g.,
+"[123.255.37.2]", which indicates an Internet Address in
+sequence-of-octets form.
+
+The time stamp line and the return path line are formally defined as
+follows:
+
+<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
+
+<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
+
+<stamp> ::= <from-domain> <by-domain> <opt-info> ";"
+ <daytime>
+
+<from-domain> ::= "FROM" <SP> <domain> <SP>
+
+<by-domain> ::= "BY" <SP> <domain> <SP>
+
+<opt-info> ::= [<via>] [<with>] [<id>] [<for>]
+
+<via> ::= "VIA" <SP> <link> <SP>
+
+<with> ::= "WITH" <SP> <protocol> <SP>
+
+<id> ::= "ID" <SP> <string> <SP>
+
+<for> ::= "FOR" <SP> <path> <SP>
+
+<<>>FOR and <link> need to be nailed down.
+
+ <link> ::= The standard names for links are registered with
+ the Internet Assigned Numbers Authority (IANA).
+
+ <protocol> ::= The standard names for protocols are
+ registered with the Internet Assigned Numbers Authority
+ (IANA).
+
+ <daytime> ::= <SP> <date> <SP> <time>
+
+ <date> ::= <dd> <SP> <mon> <SP> <yyyy>
+
+ Note that the earlier form, which permits
+ two-digit years, is deprecated. SMTP systems
+ SHOULD use four-digit years.
+
+ <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
+
+ <dd> ::= the one or two decimal integer day of the month in
+ the range 1 to 31.
+
+ <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+ "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+ <yyyy> ::= the four decimal integer year in the range 0000 to
+ 9999.
+
+ <hh> ::= the two decimal integer hour of the day in the
+ range 00 to 24.
+
+ <mm> ::= the two decimal integer minute of the hour in the
+ range 00 to 59.
+
+ <ss> ::= the two decimal integer second of the minute in the
+ range 00 to 59.
+
+ <zone> ::= A four-digit time zone offset, such as -0600 for US
+ Eastern Standard Time. This may be supplemented by a
+ time zone name in parentheses, e.g., "-0800 (PDT)". See
+ ??? for additional discussion.
+
+ Note that there is no default; time zone information
+ is required and MUST be supplied.
+
+
+
+ -------------------------------------------------------------
+ |
+ | Return Path Example
+ |
+ | Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
+ |
+ | Example 9
+ |
+ -------------------------------------------------------------
+
+ -------------------------------------------------------------
+ |
+ | Time Stamp Line Example
+ |
+ | Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81
+ | 09:23:59 PDT
+ |
+ | Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
+ | id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
+ |
+ | Example 10
+ |
+ --------------------------------------------------------------
+
+
+4.1.3. Order of commands
+
+There are restrictions on the order in which these commands may
+be used.
+
+A session that is to contain mail transactions MUST first be
+initialized by the use of the HELO or EHLO command. An SMTP server
+SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN)
+without this initialization.
+
+HELO or EHLO commands MAY be issued by a client later in the session.
+If either is issued after the session begins, the SMTP server MUST
+clear all buffers and state as if an RSET command had been issued.
+In other words, the sequence of RSET followed immediately by HELO is
+redundant, but not harmful other than in the performance cost of
+executing unnecessary commands.
+
+If the HELO or EHLO commands are not acceptable to the SMTP server,
+501, 500, or 502 failure replies MUST be returned as appropriate.
+The SMTP server must stay in the same state after transmitting these
+replies as it was in before the HELO or EHLO were received.
+
+RFC 1123 contains a discussion of arguments to HELO and conditions
+under which the HELO command can be rejected. In particular, HELO
+(or EHLO) MUST NOT be rejected because the client's putative name
+does not match some criteria established by the server (e.g.,
+verification of reverse DNS mapping).
+
+The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
+during a session, or without previously initializing a session. SMTP
+servers SHOULD process these normally (i.e., not return a 503 code)
+even if no HELO or EHLO command has yet been received; clients SHOULD
+open a session with HELO or EHLO before sending these commands.
+
+If the above rules are followed, the example in RFC 821 that shows
+"550 access denied to you" in response to an EXPN command is
+essentially meaningless unless a HELO or EHLO command preceeds the
+EXPN or the denial of access is based on the client's IP address.
+
+The MAIL, SEND, SOML, or SAML commands begin a mail transaction.
+Once started a mail transaction consists of one of the transaction
+beginning commands, one or more RCPT commands, and a DATA command, in
+that order. A mail transaction may be aborted by the RSET command.
+There may be zero or more transactions in a session.
+
+If the transaction beginning command argument is not acceptable a 501
+failure reply MUST be returned and the SMTP server must stay in the
+same state. If the commands in a transaction are out of order to the
+degree that they cannot be processed by the server a 503 failure
+reply MUST be returned and the SMTP server must stay in the same
+state.
+
+The last command in a session must be the QUIT command. The QUIT
+command can not be used at any other time in a session, but may be
+used by the client SMTP to request connection-closing even if no
+session-opening command has been sent and accepted.
+
+
+
+4.1.4 Private-use commands
+
+ Commands starting in "X" may be used by bilateral agreement
+ between the client (sending) and server (receiving) SMTPs.
+ An SMTP server that does not recognize such a command is
+ expected to reply with "500 Command not recognized". An
+ extended SMTP server MAY list the feature names associated
+ with these private commands in the response to the EHLO
+ command.
+
+ Commands sent or accepted by SMTP systems that do not start
+ with "X" MUST be documented in published RFCs and be at
+ least candidates for standardization.
+
+
+
+4.2. SMTP REPLIES
+
+Replies to SMTP commands are devised to ensure the synchronization of
+requests and actions in the process of mail transfer, and to
+guarantee that the SMTP client always knows the state of the SMTP
+server. Every command must generate exactly one reply.
+
+The details of the command-reply sequence are made explicit in
+Section ##4.3 on Sequencing and Section ##4.5 containing State
+Diagrams.
+
+An SMTP reply consists of a three digit number (transmitted as three
+alphanumeric characters) followed by some text. The number is
+intended for use by automata to determine what state to enter next;
+the text is meant for the human user. It is intended that the three
+digits contain enough encoded information that the SMTP client need
+not examine the text and may either discard it or pass it on to the
+user, as appropriate. In particular, the text may be
+receiver-dependent and context dependent, so there are likely to be
+varying texts for each reply code. A discussion of the theory of
+reply codes is given in Appendix E. Formally, a reply is defined to
+be the sequence: a three-digit code, SP, one line of text, and
+CRLF, or a multiline reply (as defined in Appendix E). Only the
+EXPN and HELP commands are expected to result in multiline replies in
+normal circumstances, however multiline replies are allowed for any
+command.
+
+An SMTP server SHOULD send only the reply codes listed in this
+document. An SMTP server SHOULD use the text shown in the examples
+whenever appropriate.
+
+A client SMTP MUST determine its actions only by the reply
+code, not by the text (except for 251 and 551 replies); any
+text, including no text at all, must be acceptable. The space
+(blank) following the reply code is considered part of the
+text. Whenever possible, a sender-SMTP SHOULD test only the
+first digit of the reply code.
+
+
+
+ 4.2.1. REPLY CODES BY FUNCTION GROUPS
+
+ 500 Syntax error, command unrecognized
+ [This may include errors such as command line too long]
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented (see section ##4.2.3)
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+
+ 211 System status, or system help reply
+ 214 Help message
+ [Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user]
+
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 421 <domain> Service not available,
+ closing transmission channel
+ [This may be a reply to any command if the service knows it
+ must shut down]
+
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+ 252 Cannot VRFY user, but will accept message and attempt
+ delivery
+ 450 Requested mail action not taken: mailbox unavailable
+ [E.g., mailbox busy]
+ 550 Requested action not taken: mailbox unavailable
+ [E.g., mailbox not found, no access]
+ 451 Requested action aborted: error in processing
+ 551 User not local; please try <forward-path>
+ 452 Requested action not taken: insufficient system storage
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ [E.g., mailbox syntax incorrect]
+ 354 Start mail input; end with <CRLF>.<CRLF>
+ 554 Transaction failed
+
+
+ 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
+
+ 211 System status, or system help reply
+ 214 Help message
+ [Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user]
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+ 252 Cannot VRFY user, but will accept message and attempt
+ delivery
+
+ 354 Start mail input; end with <CRLF>.<CRLF>
+
+ 421 <domain> Service not available,
+ closing transmission channel
+ [This may be a reply to any command if the service knows it
+ must shut down]
+ 450 Requested mail action not taken: mailbox unavailable
+ [E.g., mailbox busy]
+ 451 Requested action aborted: local error in processing
+ 452 Requested action not taken: insufficient system storage
+
+ 500 Syntax error, command unrecognized
+ [This may include errors such as command line too long]
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+ 550 Requested action not taken: mailbox unavailable
+ [E.g., mailbox not found, no access]
+ 551 User not local; please try <forward-path>
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ [E.g., mailbox syntax incorrect]
+ 554 Transaction failed
+
+
+4.2.3. Reply code 502
+
+Questions have been raised as to when reply code 502 (Command
+not implemented) should be returned in preference to other
+codes. 502 SHOULD be used when the command is actually
+recognized by the SMTP server, but not implemented. If the
+command is not recognized, code 500 SHOULD be returned.
+Extended SMTP systems MUST NOT list capabilities in response to
+EHLO for which they will return 502 (or 500) replies.
+
+
+4.2.4 Reply codes after DATA and the subsequent CRLF.CRLF.
+
+When an SMTP server returns a positive completion status (2yz
+code) after the DATA command is completed with CRLF.CRLF, it
+accepts responsibity for:
+
++ delivering the message (if the recipient mailbox exists), or
+
++ if attempts to deliver the message fail due to transient
+ conditions, retrying delivery some reasonable number of times
+ at intervals as specified in RFC 1123, or
+
++ if attempts to deliver the message fail due to permanent
+ conditions, or if repeated attempts to deliver the message
+ fail due to transient conditions, returning appropriate
+ notification to the sender of the original message (using the
+ address in the SMTP MAIL FROM command).
+
+
+When an SMTP server returns a transient error completion status
+(4yz) code after the DATA command is completed with CRLF.CRLF,
+it MUST NOT make any further attempt to deliver that message.
+The SMTP client retains responsibility for delivery of that
+message. The sending user should be able to interpret the
+return of a transient or permanent failure status as a
+non-delivery indication.
+
+
+
+
+4.3. SEQUENCING OF COMMANDS AND REPLIES
+
+4.3.1 Sequencing overview
+
+The communication between the sender and receiver is intended to be
+an alternating dialogue, controlled by the sender. As such, the
+sender issues a command and the receiver responds with a reply.
+Unless other arrangements are negotiated through service extensions,
+the sender must wait for this response before sending further
+commands.
+
+One important reply is the connection greeting. Normally, a receiver
+will send a 220 "Service ready" reply when the connection is
+completed. The sender should wait for this greeting message before
+sending any commands.
+
+Note: all the greeting type replies have the official name (i.e., the
+fully-qualified primary domain name) of the server host as the first
+word following the reply code. When the host has no name, the IP
+address should be used, in bracketed dotted-octet format, e.g.,
+[10.0.0.6].
+
+ For example,
+
+ 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
+
+
+The table below lists alternative success and failure replies for
+each command. These must be strictly adhered to; a receiver may
+substitute text in the replies, but the meaning and action implied
+by the code numbers and by the specific command reply sequence
+cannot be altered.
+
+COMMAND-REPLY SEQUENCES
+
+Each command is listed with its usual possible replies. The prefixes
+used before the possible replies are "P" for preliminary (not used in
+SMTP), "I" for intermediate, "S" for success, "F" for failure, and
+"E" for error. The 421 reply (service not available, closing
+transmission channel) may be given to any command if the
+SMTP-receiver knows it must shut down. Since some servers may
+generate other replies under special circumstances, and to allow for
+future extension, SMTP clients SHOULD, when possible, interpret only
+the first digit of the reply and MUST be prepared to deal with
+unrecognized reply codes by interpreting the first digit only. SMTP
+servers MUST NOT transmit reply codes to an SMTP client that are
+other than three digits or that do not start in a digit between 2 and
+5 inclusive. This listing forms the basis for the State Diagrams in
+Section ##4.5.
+
+ CONNECTION ESTABLISHMENT
+ S: 220
+ F: 421
+ HELO
+ S: 250
+ E: 500, 501, 504, 421
+ MAIL
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 421
+ RCPT
+ S: 250, 251 (but see section ##<<<>>> for discussion of 251)
+ F: 550, 551, 552, 553, 450, 451, 452
+ E: 500, 501, 503, 421
+ DATA
+ I: 354 -> data -> S: 250
+ F: 552, 554, 451, 452
+ F: 451, 554
+ E: 500, 501, 503, 421
+ RSET
+ S: 250
+ E: 500, 501, 504, 421
+ SEND
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ SOML
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ SAML
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ VRFY
+ S: 250, 251
+ F: 550, 551, 553
+ E: 500, 501, 502, 504, 421
+ EXPN
+ S: 250
+ F: 550
+ E: 500, 501, 502, 504, 421
+ HELP
+ S: 211, 214
+ E: 500, 501, 502, 504, 421
+ NOOP
+ S: 250
+ E: 500, 421
+ QUIT
+ S: 221
+ E: 500
+ TURN
+ S: 250
+ F: 502
+ E: 500, 503
+
+
+
+4.4 Trace information
+
+When an SMTP server receives a message for delivery or further
+processing, it MUST insert trace ("time stamp" or "Received"
+information at the beginning of the message body, as discussed under
+the DATA command in section ##4.1.1.4.
+
+This line must be structured as follows:
+
+ * The FROM field SHOULD contain both (1) the name of the
+ source host as presented in the EHLO or HELO command and (2) a
+ domain literal containing the IP address of the source,
+ determined from the TCP connection.
+
+ * The ID field MAY contain an "@" as suggested in RFC-822,
+ but this is not required.
+
+ * The FOR field MAY contain a list of <path> entries when
+ multiple RCPT commands have been given.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.
+
+
+As the Internet grows, comparability of Received fields is important
+for detecting problems, especially slow relays. SMTP servers that
+create Received fields SHOULD use explicit offsets in the dates
+(e.g., -0800), rather than time zone names of any type. If it is
+desired to also use a time zone name, it should be included in a
+commment.
+
+
+When the SMTP server makes the "final delivery" of a message it
+inserts a return-path line at the beginning of the mail data. This
+use of return-path is required; mail systems MUST support it. The
+return path line preserves the information in the <reverse-path> from
+the MAIL command. Here, final delivery means the message leaves the
+SMTP world. Normally, this would mean it has been delivered to the
+destination user, but in some cases it may be further processed and
+transmitted by another mail system.
+
+It is possible for the mailbox in the return path be different from
+the actual sender's mailbox, for example, if error responses are to
+be delivered a special error handling mailbox rather than to that of
+the message sender. When mailing lists are involved, this
+arrangement is common and useful as a means of directing errors to
+the list maintainer rather than the message originator.
+
+The preceding two paragraphs imply that the final mail data will
+begin with a return path line, followed by one or more time stamp
+lines. These lines will be followed by the mail data header and body
+[RFC822]. See Example 8.
+
+It is sometimes difficult for an SMTP server to determine whether or
+not it is making final delivery since forwarding or other operations
+may occur after the message is accepted for delivery. However any
+further (forwarding, gateway, or relay) systems MAY remove the return
+path and rebuild the MAIL FROM command as needed to ensure that
+exactly one such line appears in a delivered message.
+
+A message-originating SMTP system SHOULD NOT send a message that
+already contains a Return-path header. If a message that contains
+more than one Return-path header is received, only the first
+Return-path header line in the message header is valid. A message
+header processor SHOULD discard or, if necessary just ignore, any
+Return-path headers following the first one.
+
+The primary intent of the Return-path is that it designates the
+address to which messages indicating non-delivery or other mail
+system failures at to be sent. For this to be unambigious, exactly
+one return path should be present when the message is delivered.
+Systems using RFC 822 syntax with non-SMTP transports SHOULD preserve
+the intent of having an unambiguous address, associated with the
+transport envelope, to which to send error reports (e.g.,
+non-delivery messages).
+
+ Historical note: Text in RFC 822 that appears to contradict the
+ use of Return-path (or the envelope MAIL FROM address) as the
+ destination of error messages is not applicable on the Internet.
+ The MAIL FROM address (as copied into the Return-path) MUST be
+ used as the target of any mail containing delivery error messages.
+
+In particular,
+
+(i) a gateway from SMTP->elsewhere SHOULD insert a return-path
+header, unless it is known that the "elsewhere" transport
+also uses Internet domain addresses and maintains the
+envelope sender address separately.
+
+(ii) a gateway from elsewhere->SMTP SHOULD delete any
+return-path header present in the message, and either copy
+that information to the SMTP envelope or combine it with
+information present in the envelope of the other transport
+system to construct the MAIL FROM part of the SMTP envelope.
+
+
+Special mention is needed of the response and further action required
+when the processing following the end of mail data indication is
+partially successful. This could arise if after accepting several
+recipients and the mail data, the SMTP server finds that the mail
+data can be successfully delivered to some of the recipients, but it
+cannot be to others (for example, due to mailbox space allocation
+problems). In such a situation, the response to the DATA command
+must be an OK reply. But, the SMTP server must compose and send an
+"undeliverable mail" notification message to the originator of the
+message. Either a single notification which lists all of the
+recipients that failed to get the message, or separate notification
+messages must be sent for each failed recipient (see Example 7). All
+undeliverable mail notification messages are sent using the MAIL
+command (even if they result from processing a SEND, SOML, or SAML
+command).
+
+
+
+
+-------------------------------------------------------------
+|
+| Example of Return Path and Received Time Stamps
+|
+| Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
+| Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 -0800
+| Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 -0800
+| Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 -0800
+| Date: 27 Oct 81 15:01:01 -0800 (PST)
+| From: JOE@ABC.ARPA
+| Subject: Improved Mailing System Installed
+| To: SAM@JKL.ARPA
+|
+| This is to inform you that ...
+|
+| Example 8
+|
+-------------------------------------------------------------
+
+
+
+
+
+
+4.5. STATE DIAGRAMS
+
+Following are state diagrams for a simple-minded SMTP
+implementation. Only the first digit of the reply codes is used.
+There is one state diagram for each group of SMTP commands. The
+command groupings were determined by constructing a model for each
+command and then collecting together the commands with
+structurally identical models.
+
+For each command there are three possible outcomes: "success"
+(S), "failure" (F), and "error" (E). In the state diagrams below
+we use the symbol B for "begin", and the symbol W for "wait for
+reply".
+
+First, the diagram that represents most of the SMTP commands:
+
+
+ 1,3 +---+
+ ----------->| E |
+ | +---+
+ |
+ +---+ cmd +---+ 2 +---+
+ | B |---------->| W |---------->| S |
+ +---+ +---+ +---+
+ |
+ | 4,5 +---+
+ ----------->| F |
+ +---+
+
+
+ This diagram models the commands:
+
+ HELO, EHLO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN,
+ HELP, NOOP, QUIT, TURN.
+
+
+
+
+ A more complex diagram models the DATA command:
+
+
+ +---+ DATA +---+ 1,2 +---+
+ | B |---------->| W |-------------------->| E |
+ +---+ +---+ ------------>+---+
+ 3| |4,5 |
+ | | |
+ -------------- ----- |
+ | | | +---+
+ | ---------- -------->| S |
+ | | | | +---+
+ | | ------------
+ | | | |
+ V 1,3| |2 |
+ +---+ data +---+ --------------->+---+
+ | |---------->| W | | F |
+ +---+ +---+-------------------->+---+
+ 4,5
+
+
+ Note that the "data" here are a series of lines sent from the
+ sender to the receiver with no response expected until the last
+ line is sent.
+
+
+4.6. DETAILS
+
+4.6.1. MINIMUM IMPLEMENTATION
+
+ In order to make SMTP workable, the following minimum
+ implementation is required for all receivers:
+
+ COMMANDS -- HELO
+ VRFY
+ MAIL
+ RCPT
+ DATA
+ RSET
+ NOOP
+ QUIT
+
+Any system that includes an SMTP server that supports RCPT MUST
+support the reserved mailbox "Postmaster" as a case-insensitive
+mailbox name. EHLO SHOULD be supported if possible.
+
+
+
+4.6.2. TRANSPARENCY
+
+ Without some provision for data transparency the character
+ sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
+ by the user. In general, users are not aware of such
+ "forbidden" sequences. To allow all user composed text to be
+ transmitted transparently the following procedures are used.
+
+ 1. Before sending a line of mail text the SMTP client checks
+ the first character of the line. If it is a period, one
+ additional period is inserted at the beginning of the line.
+
+ 2. When a line of mail text is received by the SMTP server
+ it checks the line. If the line is composed of a single
+ period it is the end of mail. If the first character is a
+ period and there are other characters on the line, the first
+ character is deleted.
+
+ The mail data may contain any of the 128 ASCII characters. All
+ characters are to be delivered to the recipient's mailbox
+ including format effectors and other control characters. If
+ the transmission channel provides an 8-bit byte (octets) data
+ stream, the 7-bit ASCII codes are transmitted right justified
+ in the octets with the high order bits cleared to zero.
+
+ In some systems it may be necessary to transform the data as
+ it is received and stored. This may be necessary for hosts
+ that use a different character set than ASCII as their local
+ character set, or that store data in records rather than
+ strings. If such transforms are necessary, they must be
+ reversible -- especially if such transforms are applied to
+ mail being relayed.
+
+
+4.6.3. SIZES AND TIMEOUTS
+
+There are several objects that have required minimum maximum
+sizes. That is, every implementation must be able to receive
+objects of at least these sizes, but must not send objects
+larger than these sizes.
+
+
+****************************************************
+* *
+* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+* OF THESE OBJECTS SHOULD BE USED. *
+* *
+****************************************************
+
+user
+
+ The maximum total length of a user name is 64 characters.
+
+domain
+
+ The maximum total length of a domain name or number is 64
+ characters.
+
+path
+
+ The maximum total length of a reverse-path or
+ forward-path is 256 characters (including the punctuation
+ and element separators).
+
+command line
+
+ The maximum total length of a command line including the
+ command word and the <CRLF> is 512 characters.
+
+reply line
+
+ The maximum total length of a reply line including the
+ reply code and the <CRLF> is 512 characters.
+
+
+text line
+
+ The maximum total length of a text line including the
+ <CRLF> is 1000 characters (but not counting the leading
+ dot duplicated for transparency). This number may be increased by
+ the use of SMTP Service Extensions.
+
+message body
+
+ The maximum total length of a message body (including any message
+ headers) MUST BE at least 64K octets. Especially since the
+ introduction of multimedia mail [RFC-MIME], message lengths on the
+ Internet have grown dramatically, and message size restrictions
+ should be avoided if at all possible. SMTP server systems that must
+ impose restrictions SHOULD implement the "SIZE" service extension
+ ([RFC-SIZE]) and SMTP client systems that will send large messages
+ SHOULD utilize it when possible.
+
+recipients buffer
+
+ The maximum total number of recipients that must be
+ buffered is 100 recipients.
+
+
+****************************************************
+* *
+* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+* OF THESE OBJECTS SHOULD BE USED. *
+* *
+****************************************************
+
+Errors due to exceeding these limits may be reported by using
+the reply codes, for example:
+
+500 Line too long.
+
+501 Path too long
+
+552 Too many recipients.
+
+552 Too much mail data.
+
+
+An SMTP client should provide timeouts for all commands. Minimum
+values SHOULD be as follows:
+
+o Initial 220 Message: 5 minutes
+
+ An SMTP client process needs to distinguish between a
+ failed TCP connection and a delay in receiving the initial
+ 220 greeting message. Many SMTP servers will accept a
+ TCP connection but delay delivery of the 220 message until
+ their system load will permit more mail to be processed.
+
+o MAIL Command: 5 minutes
+
+
+o RCPT Command: 5 minutes
+
+ A longer timeout would be required if processing of
+ mailing lists and aliases were not deferred until after
+ the message was accepted.
+
+o DATA Initiation: 2 minutes
+
+ This is while awaiting the "354 Start Input" reply to a
+ DATA command.
+
+o Data Block: 3 minutes
+
+ This is while awaiting the completion of each TCP SEND
+ call transmitting a chunk of data.
+
+o DATA Termination: 10 minutes.
+
+ This is while awaiting the "250 OK" reply. When the
+ receiver gets the final period terminating the message
+ data, it typically performs processing to deliver the
+ message to a user mailbox. A spurious timeout at this
+ point would be very wasteful, since the message has been
+ successfully sent.
+
+An SMTP server SHOULD have a timeout of at least 5 minutes
+while it is awaiting the next command from the sender.
+
+
+4.6.4 Queuing Strategies
+
+The common structure of a host SMTP implementation includes
+user mailboxes, one or more areas for queueing messages in
+transit, and one or more daemon processes for sending and
+receiving mail. The exact structure will vary depending on the
+needs of the users on the host and the number and size of
+mailing lists supported by the host. We describe several
+optimizations that have proved helpful, particularly for
+mailers supporting high traffic levels.
+
+Any queueing strategy MUST include:
+
+o Timeouts on all activities on a per-command basis
+
+o Never sending error messages in response to error messages.
+
+
+4.6.4.1 Sending Strategy
+
+ The general model of an SMTP client is one or more processes
+ that periodically attempt to transmit outgoing mail. In a
+ typical system, the program that composes a message has some
+ method for requesting immediate attention for a new piece of
+ outgoing mail, while mail that cannot be transmitted
+ immediately MUST be queued and periodically retried by the
+ sender. A mail queue entry will include not only the
+ message itself but also the envelope information.
+
+ The sender MUST delay retrying a particular destination
+ after one attempt has failed. In general, the retry
+ interval SHOULD be at least 30 minutes; however, more
+ sophisticated and variable strategies will be beneficial
+ when the SMTP client can determine the reason for non-
+ delivery.
+
+ Retries continue until the message is transmitted or the
+ sender gives up; the give-up time generally needs to be at
+ least 4-5 days. The parameters to the retry algorithm MUST
+ be configurable.
+
+ A sender SHOULD keep a list of hosts it cannot reach and
+ corresponding connection timeouts, rather than just retrying queued
+ mail items.
+
+ DISCUSSION:
+ Experience suggests that failures are typically
+ transient (the target system has crashed), favoring a
+ policy of two connection attempts in the first hour the
+ message is in the queue, and then backing off to once
+ every two or three hours.
+
+ The SMTP client can shorten the queueing delay by
+ cooperation with the SMTP server. In particular, if
+ mail is received from a particular address, it is good
+ evidence that any mail queued for that host can now be
+ sent.
+
+ The strategy may be further modified as a result of
+ multiple addresses per host (see Section ##5.??.??), to
+ optimize delivery time vs. resource usage.
+
+ an SMTP client may have a large queue of messages for
+ each unavailable destination host, and if it retried
+ all these messages in every retry cycle, there would be
+ excessive Internet overhead and the daemon would be
+ blocked for a long period. Note that an SMTP can
+ generally determine that a delivery attempt has failed
+ only after a timeout of a minute or more; a one minute
+ timeout per connection will result in a very large
+ delay if it is repeated for dozens or even hundreds of
+ queued messages.
+
+ When the same message is to be delivered to several users on
+ the same host, only one copy of the message SHOULD be
+ transmitted. That is, the SMTP client should use the
+ command sequence: RCPT, RCPT,... RCPT, DATA instead of the
+ sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
+ Implementation of this efficiency feature is strongly urged.
+
+ Similarly, the SMTP client MAY support multiple concurrent
+ outgoing mail transactions to achieve timely delivery.
+ However, some limit SHOULD be imposed to protect the host
+ from devoting all its resources to mail.
+
+4.6.4.2 Receiving strategy
+
+ The SMTP server SHOULD attempt to keep a pending listen on
+ the SMTP port at all times. This will require the support
+ of multiple incoming TCP connections for SMTP. Some limit
+ MAY be imposed.
+
+ IMPLEMENTATION:
+ When the SMTP server receives mail from a particular
+ host address, it could notify the SMTP client to retry
+ any mail pending for that host address.
+
+
+5. Address resolution and mail handling
+
+Once an SMTP client lexically identifies a domain to which mail is to
+be delivered for processing (as described in sections ##3.6 and
+##3.7), a DNS lookup is performed to resolve that domain name (see
+[RFC-DNS]). The lookup first attempts to locate an MX record
+associated with that name. If a CNAME record is found instead, the
+resulting name is processed as if it were the initial name.
+
+When the lookup succeeds, the mapping can result in a list of
+alternative delivery addresses rather than a single address, because
+of (a) multiple MX records, (b) multihoming, or both. To provide
+reliable mail transmission, the SMTP client MUST be able to try (and
+retry) each of the addresses in this list in order, until a delivery
+attempt succeeds. However, there MAY also be a configurable limit on
+the number of alternate addresses that can be tried. In any case, a
+host SHOULD try at least two addresses.
+
+ The following information is to be used to rank the host
+ addresses:
+
+ (1) Multiple MX Records -- these contain a preference
+ indication that should be used in sorting. If there are
+ multiple destinations with the same preference and there
+ is no clear reason to favor one (e.g., by address
+ preference), then the sender-SMTP SHOULD pick one at
+ random to spread the load across multiple mail exchanges
+ for a specific organization; note that this is a
+ refinement of the procedure in [DNS:3].
+
+ (2) Multihomed host -- The destination host (perhaps taken
+ from the preferred MX record) may be multihomed, in which
+ case the domain name resolver will return a list of
+ alternative IP addresses. It is the responsibility of the
+ domain name resolver interface to have ordered this list by
+ decreasing preference, and SMTP MUST try them in the order
+ presented.
+
+ DISCUSSION:
+ Although the capability to try multiple alternative
+ addresses is required, there may be circumstances where
+ specific installations want to limit or disable the use of
+ alternative addresses. The question of whether a sender
+ should attempt retries using the different addresses of a
+ multihomed host has been controversial. The main argument
+ for using the multiple addresses is that it maximizes the
+ probability of timely delivery, and indeed sometimes the
+ probability of any delivery; the counter argument is that
+ it may result in unnecessary resource use.
+
+ Note that resource use is also strongly determined by the
+ sending strategy discussed in Section #??.??.??
+
+
+
+6. Problem detection and handling
+
+6.1 Replies by email
+
+ <<>>
+
+6.2 Loop detection
+
+Simple counting of the number of Received lines in a message has not
+proven to be a desirable method of detecting loops in mail systems,
+and SMTP servers SHOULD NOT use that technique. Loop detection by
+examination of Received fields for the domain name or other signature
+of the SMTP server making the check is effective and MAY be used by
+SMTP servers.
+
+
+
+7. Security Considerations
+
+7.1 Mail security and spoofing
+
+SMTP mail is inherently insecure in that it is feasible for even
+fairly casual users to negotiate directly with receiving and
+relaying SMTP servers and create messages that will trick a
+naive recipient into believing that they came from somewhere
+else. Constructing such a message so that the "spoofed"
+behavior cannot be detected by an expert is somewhat more
+difficult, but not sufficiently so as to be a deterrent to
+someone who is determined and knowledgeable.
+
+Consequently, as knowledge of Internet mail increases, so does the
+knowledge that SMTP mail inherently cannot be authenticated, or
+integrity checks provided, at the transport level. Real security
+lies only in end-to-end methods involving the message bodies, e.g.,
+those that can be provided in the MOSS framework [RFC-MOSS].
+
+A corollary to this is that efforts to make it more difficult
+for users to set envelope MAIL FROM and header "From" fields
+to point to valid addresses other than their own are largely
+misguided: they do not prevent any would-be mail spoofer from
+doing so, and do frustrate legitimate applications in which
+mail is sent by one user on behalf of another or in which
+error (or normal) replies should be directed to a special
+address. On the other hand, systems that provide convenient
+ways for users to alter these fields on a per-message basis
+should attempt to establish a primary and permanent mailbox
+address for the user so that Sender fields can be generated
+correctly.
+
+This specification does not further address the security issues
+associated with SMTP other than to advocate that useful
+functionality not be disabled in the hope of providing some
+small margin of protection against an ignorant user who is
+trying to fake mail.
+
+
+
+7.2 "Blind" copies.
+
+Addresses may appear in the RCPT TO commands to an SMTP server
+that do not appear in the message headers for a number of
+reasons. The two most common of these involve the use of a
+mailing address as a "list exploder" -- a single address that
+resolves into multiple addresses -- and the appearance of "blind
+copies". In order to avoid defeating some of the purpose of
+these mechanisms, SMTP clients and servers SHOULD NOT copy the
+RCPT TO command arguments into the headers, even as
+informational or private-extension headers. Since this rule is
+often violated in practice, and cannot be enforced, sending SMTP
+systems that are aware of "bcc" use MAY find it helpful to send
+each blind copy as a separate message transaction containing
+only a single RCPT TO command.
+
+More generally, while there are often similarities, there is no
+inherent relationship between either "reverse" (MAIL FROM, SAML FROM,
+etc.) or "forward" (RCPT TO) addresses in the SMTP transaction
+("envelope") and the addresses in the headers. Receiving systems
+SHOULD NOT attempt to deduce such relationships and use them to alter
+the headers of the message for delivery. The popular "Apparently-to"
+header is a violation of this principle and SHOULD NOT be used.
+
+See also section ##2.2.4.
+
+\f
+8. REFERENCES
+
+[1] ASCII
+
+ ASCII, "USA Code for Information Interchange", United States of
+ America Standards Institute, X3.4, 1968.
+
+[RFC822]
+ Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", RFC 822, Department of Electrical Engineering,
+ University of Delaware, August 1982.
+
+[3] TCP
+ Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+ Program Protocol Specification", RFC 793, USC/Information Sciences
+ Institute, NTIS AD Number A111091, September 1981. Also in:
+ Feinler, E. and J. Postel, eds., "Internet Protocol Transition
+ Workbook", SRI International, Menlo Park, California, March 1982.
+
+[HEADER-PEOPLE]
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+ specification", RFC 1035 and P. Mockapetris, "Domain names -
+ concepts and facilities", RFC 1034. (STD 13)
+
+[RFC 974] C. Partridge, "Mail routing and the domain system",
+ 01/01/1986
+
+[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D.
+ Crocker, "SMTP Service Extensions", RFC-1869, 11/06/1995.
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts -
+ application and support", 10/01/1989
+
+[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+ Security Services", RFC 1848, 10/03/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J.
+ Reynolds, "Post Office Protocol - version 2", RFC 937,
+ 02/01/1985
+
+[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3",
+ RFC 1725, 11/23/1994.
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol
+ - Version 4", RFC 1730, 12/20/1994.
+
+[ABNF] Crocker, D., "Augmented BNF for Syntax Specifictions" (sic),
+ (in progress -- draft-ietf-drums-abnf-00.txt)
+
+
+9. Editor's Addresses
+
+ John C. Klensin
+ MCI Data Services
+ 800 Boylston St, 7th floor
+ Boston, MA 02199
+ USA
+ Email: Klensin@mci.net
+ Phone: +1 617 859 1011
+ Fax: +1 617 859 1011
+
+
+10. Acknowledgements
+
+<<to be supplied>>
+
+\f
+APPENDIX A
+
+TCP Transport service
+
+The Transmission Control Protocol [3] is used in the Internet, and in
+any network following the Internet standards for internetwork protocols.
+
+Connection Establishment
+
+ The SMTP transmission channel is a TCP connection established
+ between the sender process port U and the receiver process port
+ L. This single full duplex connection is used as the
+ transmission channel. This protocol is assigned the service
+ port 25 (31 octal), that is L=25.
+
+Data Transfer
+
+ The TCP connection supports the transmission of 8-bit bytes.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+\f
+APPENDIX B
+
+Generating SMTP commands from RFC 822 headers
+
+Some systems use RFC 822 headers (only) in a mail submission
+protocol, or otherwise generate SMTP commands from RFC 822 headers
+when such a message is handed to an MTA from a UA. While the MTA-UA
+protocol is a private matter, not covered by any Internet Standard,
+there are problems with this approach. For example, there have been
+repeated problems with proper handling of "bcc" copies and
+redistribution lists when information that conceptually belongs to a
+mail envelopes is not separated early in processing from header
+information (and kept separate).
+
+It is recommended that the UA provide its initial MTA with an
+envelope separate from the message itself. However, if the envelope
+is not supplied, SMTP commands should be generated as follows:
+
+(i) each recipient addresses from a TO, CC, or BCC header field
+should be copied to a RCPT command (generating multiple message
+copies if that is required for queuing or delivery). This includes
+any addresses listed in a RFC 822 "group". Any BCC fields should
+then be removed from the headers. Once this process is completed,
+the remaining headers should be checked to verify that at least one
+To:, Cc:, or Bcc: header remains. If none do, then a bcc: header
+with no additional information SHOULD be inserted (see section ##2.15
+above).
+
+(ii) the return address in the MAIL command should be derived from
+the system's identity for the submitting (local) user. That return
+address should also be copied to the Sender header field if it is
+different from the address in the From header field. (Any Sender
+field that was already there should be removed.) Systems may provide
+a way for submitters to override the envelope return address, but may
+want to restrict its use to privileged users. (This will not prevent
+mail forgery, but may lessen its incidence.)
+
+A submission protocol based on Standard RFC 822 information alone
+MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
+system into an SMTP environment. Additional information to construct
+an envelope must come from some source in the other environment,
+whether supplemental headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc"
+fields, have repeatedly caused mail loops and other behavior adverse
+to the proper functioning of the Internet mail environment. These
+problems have been especially common when the message originates from
+an Internet mailing list and is distributed into the foreign
+environment using envelope information. When these messages are then
+processed by a header-only remailer, loops back to the Internet
+environment (and the mailing list) are almost inevitable.
+
+\f
+APPENDIX E
+
+Theory of Reply Codes
+
+The three digits of the reply each have a special significance.
+The first digit denotes whether the response is good, bad or
+incomplete. An unsophisticated SMTP client will be able to
+determine its next action (proceed as planned, redo, retrench,
+etc.) by simply examining this first digit. An SMTP client that
+wants to know approximately what kind of error occurred (e.g.,
+mail system error, command syntax error) may examine the second
+digit, reserving the third digit for the finest gradation of
+information.
+
+There are five values for the first digit of the reply code:
+
+ 1yz Positive Preliminary reply
+
+ The command has been accepted, but the requested action
+ is being held in abeyance, pending confirmation of the
+ information in this reply. The SMTP client should send
+ another command specifying whether to continue or abort
+ the action.
+
+ [Note: SMTP does not have any commands that allow this
+ type of reply, and so does not have the continue or
+ abort commands.]
+
+ 2yz Positive Completion reply
+
+ The requested action has been successfully completed. A
+ new request may be initiated.
+
+ 3yz Positive Intermediate reply
+
+ The command has been accepted, but the requested action
+ is being held in abeyance, pending receipt of further
+ information. The SMTP client should send another command
+ specifying this information. This reply is used in
+ command sequence groups.
+
+ 4yz Transient Negative Completion reply
+
+ The command was not accepted and the requested action did
+ not occur. However, the error condition is temporary and
+ the action may be requested again. The sender should
+ return to the beginning of the command sequence (if any).
+ It is difficult to assign a meaning to "transient" when
+ two different sites (receiver- and sender- SMTPs) must
+ agree on the interpretation. Each reply in this category
+ might have a different time value, but the SMTP client is
+ encouraged to try again. A rule of thumb to determine if
+ a reply fits into the 4yz or the 5yz category (see below)
+ is that replies are 4yz if they can be repeated without
+ any change in command form or in properties of the sender
+ or receiver. (E.g., the command is repeated identically
+ and the receiver does not put up a new implementation.)
+
+ 5yz Permanent Negative Completion reply
+
+ The command was not accepted and the requested action did
+ not occur. The SMTP client is discouraged from repeating
+ the exact request (in the same sequence). Even some
+ "permanent" error conditions can be corrected, so the
+ human user may want to direct the SMTP client to
+ reinitiate the command sequence by direct action at some
+ point in the future (e.g., after the spelling has been
+ changed, or the user has altered the account status).
+
+The second digit encodes responses in specific categories:
+
+ x0z Syntax -- These replies refer to syntax errors,
+ syntactically correct commands that don't fit any
+ functional category, and unimplemented or superfluous
+ commands.
+
+ x1z Information -- These are replies to requests for
+ information, such as status or help.
+
+ x2z Connections -- These are replies referring to the
+ transmission channel.
+
+ x3z Unspecified as yet.
+
+ x4z Unspecified as yet.
+
+ x5z Mail system -- These replies indicate the status of
+ the receiver mail system vis-a-vis the requested
+ transfer or other mail system action.
+
+The third digit gives a finer gradation of meaning in each
+category specified by the second digit. The list of replies
+illustrates this. Each reply text is recommended rather than
+mandatory, and may even change according to the command with
+which it is associated. On the other hand, the reply codes
+must strictly follow the specifications in this section.
+Receiver implementations should not invent new codes for
+slightly different situations from the ones described here, but
+rather adapt codes already defined.
+
+For example, a command such as NOOP whose successful execution
+does not offer the SMTP client any new information will return
+a 250 reply. The response is 502 when the command requests an
+unimplemented non-site-specific action. A refinement of that
+is the 504 reply for a command that is implemented, but that
+requests an unimplemented parameter.
+
+The reply text may be longer than a single line; in these cases
+the complete text must be marked so the SMTP client knows when it
+can stop reading the reply. This requires a special format to
+indicate a multiple line reply.
+
+The format for multiline replies requires that every line,
+except the last, begin with the reply code, followed
+immediately by a hyphen, "-" (also known as minus), followed by
+text. The last line will begin with the reply code, followed
+immediately by <SP>, optionally some text, and <CRLF>.
+
+ For example:
+ 123-First line
+ 123-Second line
+ 123-234 text beginning with numbers
+ 123 The last line
+
+In many cases the SMTP client then simply needs to search for
+the reply code followed by <SP> at the beginning of a line, and
+ignore all preceding lines. In a few cases, there is important
+data for the sender in the reply "text". The sender will know
+these cases from the current context.
+
+\f
+APPENDIX F
+
+Scenarios
+
+This section presents complete scenarios of several types of SMTP
+sessions.
+
+A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host USC-ISIF, to
+Jones, Green, and Brown at host BBN-UNIX. Here we assume that
+host USC-ISIF contacts host BBN-UNIX directly. The mail is
+accepted for Jones and Brown. Green does not have a mailbox at
+host BBN-UNIX.
+
+-------------------------------------------------------------
+
+ R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BBN-UNIX.ARPA
+
+ S: MAIL FROM:<Smith@USC-ISIF.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@BBN-UNIX.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Green@BBN-UNIX.ARPA>
+ R: 550 No such user here
+
+ S: RCPT TO:<Brown@BBN-UNIX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+ Scenario 1
+
+-------------------------------------------------------------
+
+
+
+
+
+Aborted SMTP Transaction Scenario
+
+-------------------------------------------------------------
+
+ R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+ S: HELO ISI-VAXA.ARPA
+ R: 250 MIT-Multics.ARPA
+
+ S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@MIT-Multics.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Green@MIT-Multics.ARPA>
+ R: 550 No such user here
+
+ S: RSET
+ R: 250 OK
+
+ S: QUIT
+ R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+ Scenario 2
+
+-------------------------------------------------------------
+
+
+
+Relayed Mail Scenario
+
+-------------------------------------------------------------
+
+ Step 1 -- Source Host to Relay Host
+
+ R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-AI.ARPA
+ R: 250 USC-ISIE.ARPA
+
+ S: MAIL FROM:<JQP@MIT-AI.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Date: 2 Nov 81 22:33:44
+ S: From: John Q. Public <JQP@MIT-AI.ARPA>
+ S: Subject: The Next Meeting of the Board
+ S: To: Jones@BBN-Vax.ARPA
+ S:
+ S: Bill:
+ S: The next meeting of the board of directors will be
+ S: on Tuesday.
+ S: John.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+
+ Step 2 -- Relay Host to Destination Host
+
+ R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIE.ARPA
+ R: 250 BBN-VAX.ARPA
+
+ S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Jones@BBN-VAX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+ 2 Nov 81 22:40:10 UT
+ S: Date: 2 Nov 81 22:33:44
+ S: From: John Q. Public <JQP@MIT-AI.ARPA>
+ S: Subject: The Next Meeting of the Board
+ S: To: Jones@BBN-Vax.ARPA
+ S:
+ S: Bill:
+ S: The next meeting of the board of directors will be
+ S: on Tuesday.
+ S: John.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+ Scenario 3
+
+-------------------------------------------------------------
+
+
+
+
+Verifying and Sending Scenario
+
+-------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+ S: SEND FROM:<EAK@MIT-MC.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 4
+
+-------------------------------------------------------------
+
+
+
+
+Mailing List Scenario
+
+First each of two mailing lists are expanded in separate sessions
+with different hosts. Then the message is sent to everyone that
+appeared on either list (but no duplicates) via a relay host.
+
+-------------------------------------------------------------
+
+ Step 1 -- Expanding the First List
+
+ R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 MIT-AI.ARPA
+
+ S: EXPN Example-People
+ R: 250-<ABC@MIT-MC.ARPA>
+ R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+ R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250-<joe@foo-unix.ARPA>
+ R: 250 <xyz@bar-unix.ARPA>
+
+ S: QUIT
+ R: 221 MIT-AI.ARPA Service closing transmission channel
+
+
+ Step 2 -- Expanding the Second List
+
+ R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 MIT-MC.ARPA
+
+ S: EXPN Interested-Parties
+ R: 250-Al Calico <ABC@MIT-MC.ARPA>
+ R: 250-<XYZ@MIT-AI.ARPA>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250-<fred@BBN-UNIX.ARPA>
+ R: 250 <xyz@bar-unix.ARPA>
+
+ S: QUIT
+ R: 221 MIT-MC.ARPA Service closing transmission channel
+
+
+ Step 3 -- Mailing to All via a Relay Host
+
+ R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 USC-ISIE.ARPA
+
+ S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
+ R: 250 OK
+ S: RCPT
+ TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+ Scenario 7
+
+-------------------------------------------------------------
+
+
+
+Too Many Recipients Scenario
+
+-------------------------------------------------------------
+
+ R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BERKELEY.ARPA
+
+ S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<fabry@BERKELEY.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<eric@BERKELEY.ARPA>
+ R: 552 Recipient storage full, try again in another transaction
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+ R: 250 OK
+
+ S: RCPT TO:<eric@BERKELEY.ARPA>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 BERKELEY.ARPA Service closing transmission channel
+
+ Scenario 10
+
+-------------------------------------------------------------
+
+Note that a real implementation must handle many recipients as
+specified in Section ##4.5.3.
+
+\f
+APPENDIX G Other gateway issues.
+
+In general, gateways between the Internet and other mail systems
+SHOULD attempt to preserve any layering semantics across the
+boundaries between the two mail systems involved. Gateway-
+translation approaches that attempt to take shortcuts by
+mapping, e.g., envelope information from one system to the
+message headers or body of another have generally proven to be
+inadequate in important ways. Systems translating between
+environments that do not support both envelopes and headers and
+Internet mail must be written with the understanding that some
+information loss is almost inevitable.
+
+
+
+\f
+APPENDIX H GLOSSARY
+
+ASCII
+
+American Standard Code for Information Interchange [1].
+
+command
+
+A request for a mail service action sent by the SMTP client to the
+SMTP server.
+
+domain
+
+The hierarchially structured global character string address of a
+host computer in the mail system.
+
+end of mail data indication
+
+A special sequence of characters that indicates the end of the
+mail data. In particular, the five characters carriage return,
+line feed, period, carriage return, line feed, in that order.
+
+host
+
+A computer in the internetwork environment on which mailboxes or
+SMTP processes reside.
+
+line
+
+A a sequence of ASCII characters ending with a <CRLF>.
+
+mail data
+
+A sequence of ASCII characters of arbitrary length, which conforms
+to the standard set in the Standard for the Format of ARPA
+Internet Text Messages (RFC 822 [RFC822]).
+
+mailbox
+
+A character string (address) which identifies a user to whom mail
+is to be sent. Mailbox normally consists of the host and user
+specifications. The standard mailbox naming convention is defined
+to be "user@domain". Additionally, the "container" in which mail
+is stored.
+
+
+SMTP server process
+
+A process which transfers mail in cooperation with an SMTP client
+process. It waits for a connection to be established via the
+transport service. It receives SMTP commands from the
+SMTP client, sends replies, and performs the specified operations.
+
+reply
+
+A reply is an acknowledgment (positive or negative) sent from
+receiver to sender via the transmission channel in response to a
+command. The general form of a reply is a completion code
+(including error codes) followed by a text string. The codes are
+for use by programs and the text is usually intended for human
+users.
+
+SMTP client process
+
+A process which transfers mail in cooperation with an SMTP server
+process. A local language may be used in the user interface
+command/reply dialogue. The SMTP client initiates the transport
+service connection. It initiates SMTP commands, receives replies,
+and governs the transfer of mail.
+
+session
+
+The set of exchanges that occur while the transmission channel is
+open.
+
+transaction
+
+The set of exchanges required for one message to be transmitted
+for one or more recipients.
+
+transmission channel
+
+A full-duplex communication path between an SMTP client and a
+SMTP server for the exchange of commands, replies, and mail
+text.
+
+transport service
+
+Any reliable stream-oriented data communication services. For
+example, NCP, TCP, NITS.
+
+
+user
+
+A human being (or a process on behalf of a human being) wishing to
+obtain mail transfer service. In addition, a recipient of
+computer mail.
+
+word
+
+A sequence of printing characters.
+
+<CRLF>
+
+The characters carriage return and line feed (in that order).
+
+<SP>
+
+The space character.
+\f
+APPENDIX I: Deprecated features of RFC 821
+
+A few features of RFC 821 have proven to be problematic and should
+not be used in Internet mail. These are:
+
+(1) TURN
+
+This command, described in RFC 821, raises important security
+issues (described in RFC 1123). Its use is deprecated; SMTP
+systems SHOULD NOT use it unless the server can authenticate the
+client.
+
+(2) Source routing
+
+RFC 821 utilized the concept of explicit source routing to get mail
+from one host to another via a series of relays. The requirement to
+utilize source routes in regular mail traffic was eliminated by the
+introduction of the domain name system "MX" record and the last
+significant justification for them was eliminated by the
+introduction, in RFC 1123, of a clear requirement that addresses
+following an "@" must all be fully-qualified domain names.
+Consequently, the only remaining justifications for the use of source
+routes are support for very old SMTP clients or MUAs and in mail system
+debugging. They can, however, still be useful in the latter
+circumstance and for routing mail around serious, but temporary,
+problems such as problems with the relevant DNS records.
+
+SMTP servers MUST continue to accept source route syntax as specified
+in the main body of this document and in RFC 1123. They MAY, if
+necessary, ignore the routes and utilize only the target domain in
+the address. If they do utilize the source route, the message MUST
+be sent to the first domain shown in the address. In particular, a
+server MUST NOT guess at shortcuts within the source route.
+
+Clients SHOULD NOT utilize explicit source routing except under
+unusual circumstances, such as debugging or potentially relaying
+around firewall or mail system configuration errors.
+
+(3) HELO
+
+As discussed in sections ##3.1 and ##4.1.1, EHLO is strongly
+preferred to HELO when the server will accept the former. Servers
+must continue to accept HELO in order to support older clients.
+
+
+(4) #-literals
+
+RFC 821 provided for specifying an Internet address as a decimal
+integer host number prefixed by a pound sign, "#". In practice, that
+form has been obsolete since the introduction of TCP/IP. It is
+deprecated and MUST NOT be used.
+
+(5) Dates and years
+
+When dates are inserted into messages by SMTP clients or servers
+(e.g., in trace fields), four-digit years MUST BE used. Two-digit
+years are deprecated; three-digit years were never permitted in the
+Internet mail system.
+
+(6) Sending versus mailing
+
+In addition to specifying a mechanism for delivering messages to
+user's mailboxes, RFC 821 provided additional, optional, commands to
+deliver messages directly to the user's terminal screen.
+These commands (SEND, SAML, SOML) were rarely implemented, and
+changes in workstation technology and the introduction of other
+protocols may have rendered them obsolete even where they are
+implemented.
+
+Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
+MAY implement them. If they are implemented by servers, the
+implementation model specified in RFC 821 MUST be used and the
+command names MUST be published in the response to the EHLO command.
+
+\f
+APPENDIX X: Change summary and Loose ends (temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt
+
+(i) Slightly clarified the discussions of rejection and failure of
+VRFY requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address
+validation.
+
+(iii) Removed the IPCE terminology and modified the text in section
+##4.1.1.2 to explicitly introduce the "mail gateway" terminology and
+to begin to distinguish a mail gateway from a conventional relay.
+**Please Review This Text**.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP
+may send everything to a single relay for further processing, rather
+than resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+
+
+X.1.2. Substantive changes between draft-ietf-drums-smtpupd-01.txt
+and draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several
+sections for clarity. Added definitions and other previous "loose
+end" material.
+
+
+X.2 Loose ends
+
+(i) Material in RFC1123, section 5.2.6, not yet fully incorporated.
+
+(ii) Are 5.3.3 and 5.3.4 of RFC1123 adequately incorporated?
+
+(iii) What needs to be done about RFC1123 5.3.6 and 5.3.7 and where
+should it/they go?
+
+(iv) The 822 BNF -> ABNF transition is not yet complete, and most of
+what has been done needs checking.
+
--- /dev/null
+
+
+
+Network Working Group F. Yergeau
+Internet Draft G. Nicol
+<draft-ietf-html-i18n-04.txt> G. Adams
+Expires 2 December 1996 M. Duerst
+ 27 May 1996
+
+
+ Internationalization of the Hypertext Markup Language
+
+
+Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working doc-
+ uments of the Internet Engineering Task Force (IETF), its areas, and
+ its working groups. Note that other groups may also distribute work-
+ ing documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months. Internet-Drafts may be updated, replaced, or obsoleted by
+ other documents at any time. It is not appropriate to use Internet-
+ Drafts as reference material or to cite them other than as a "working
+ draft" or "work in progress".
+
+ To learn the current status of any Internet-Draft, please check the
+ 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
+ Directories on ds.internic.net (US East Coast), nic.nordu.net
+ (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+ Rim).
+
+ Distribution of this document is unlimited. Please send comments to
+ the HTML working group (HTML-WG) of the Internet Engineering Task
+ Force (IETF) at <html-wg@w3.org>. Subscription address is <html-wg-
+ request@w3.org>. Discussions of the group are archived at
+ <URL:http://www.acl.lanl.gov/HTML_WG/archives.html>.
+
+
+Abstract
+
+ The Hypertext Markup Language (HTML) is a simple markup language used
+ to create hypertext documents that are platform independent. Ini-
+ tially, the application of HTML on the World Wide Web was seriously
+ restricted by its reliance on the ISO-8859-1 coded character set,
+ which is appropriate only for Western European languages. Despite
+ this restriction, HTML has been widely used with other languages,
+ using other coded character sets or character encodings, at the
+ expense of interoperability.
+
+ This document is meant to address the issue of the
+
+
+
+ Expires 2 December 1996 [Page 1]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ internationalization (i18n, i followed by 18 letters followed by n)
+ of HTML by extending the specification of HTML and giving additional
+ recommendations for proper internationalization support. A foremost
+ consideration is to make sure that HTML remains a valid application
+ of SGML, while enabling its use in all languages of the world.
+
+
+Table of contents
+
+ 1. Introduction .................................................. 2
+ 1.1. Scope ...................................................... 3
+ 1.2. Conformance ................................................ 3
+ 2. The document character set ..................................... 4
+ 2.1. Reference processing model ................................. 4
+ 2.2. The document character set ................................. 6
+ 2.3. Undisplayable characters ................................... 8
+ 3. The LANG attribute.............................................. 8
+ 4. Additional entities, attributes and elements ................... 9
+ 4.1. Full Latin-1 entity set .................................... 9
+ 4.2. Markup for language-dependent presentation ................. 9
+ 5. Forms ..........................................................15
+ 5.1. DTD additions ..............................................15
+ 5.2. Form submission ............................................15
+ 6. Miscellaneous ..................................................17
+ 7. HTML public text ...............................................18
+ 7.1. HTML DTD ...................................................18
+ 7.2. SGML declaration for HTML ..................................34
+ 7.3. ISO Latin 1 character entity set ...........................35
+ Bibliography ......................................................38
+ Authors' Addresses ................................................40
+
+
+1. Introduction
+
+ The Hypertext Markup Language (HTML) is a simple markup language used
+ to create hypertext documents that are platform independent. Ini-
+ tially, the application of HTML on the World Wide Web was seriously
+ restricted by its reliance on the ISO-8859-1 coded character set,
+ which is appropriate only for Western European languages. Despite
+ this restriction, HTML has been widely used with other languages,
+ using other coded character sets or character encodings, through var-
+ ious ad hoc extensions to the language [TAKADA].
+
+ This document is meant to address the issue of the internationaliza-
+ tion of HTML by extending the specification of HTML and giving addi-
+ tional recommendations for proper internationalization support. It
+ is in good part based on a paper by one of the authors on multilin-
+ gualism on the WWW [NICOL]. A foremost consideration is to make sure
+
+
+
+ Expires 2 December 1996 [Page 2]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ that HTML remains a valid application of SGML, while enabling its use
+ in all languages of the world.
+
+ The specific issues addressed are the SGML document character set to
+ be used for HTML, the proper treatment of the charset parameter asso-
+ ciated with the "text/html" content type and the specification of
+ some additional elements and entities.
+
+
+1.1 Scope
+
+ HTML has been in use by the World-Wide Web (WWW) global information
+ initiative since 1990. This specification extends the capabilities
+ of HTML 2.0 (RFC 1866), primarily by removing the restriction to the
+ ISO-8859-1 coded character set [ISO-8859-1].
+
+ HTML is an application of ISO Standard 8879:1986, Information Pro-
+ cessing Text and Office Systems -- Standard Generalized Markup Lan-
+ guage (SGML) [ISO-8879]. The HTML Document Type Definition (DTD) is a
+ formal definition of the HTML syntax in terms of SGML. This specifi-
+ cation amends the DTD of HTML in order to make it applicable to docu-
+ ments encompassing a character repertoire much larger than that of
+ ISO-8859-1, while still remaining SGML conformant.
+
+ Both formal and actual development of HTML are advancing very fast.
+ The features described in this document are designed so that they can
+ (and should) be added to other forms of HTML besides that described
+ in RFC 1866. Where indicated, attributes introduced here should be
+ extended to the appropriate elements.
+
+
+1.2 Conformance
+
+ This specification changes slightly the conformance requirements of
+ HTML documents and HTML user agents.
+
+1.2.1 Documents
+
+ All HTML 2.0 conforming documents remain conforming with this speci-
+ fication. However, the extensions introduced here make valid cer-
+ tains documents that would not be HTML 2.0 conforming, in particular
+ those containing characters or character references outside of the
+ repertoire of ISO 8859-1, and those containing markup introduced
+ herein.
+
+
+
+
+
+
+
+ Expires 2 December 1996 [Page 3]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+1.2.2. User agents
+
+ In addition to the requirements of RFC 1866, the following require-
+ ments are placed on HTML user agents.
+
+ To ensure interoperability and proper support for at least
+ ISO-8859-1 in an environment where character encoding schemes
+ other than ISO-8859-1 are present, user agents must correctly
+ interpret the charset parameter accompanying an HTML document
+ received from the network.
+
+ Furthermore, conforming user-agents are required to at least parse
+ correctly all numeric character references within the range of ISO
+ 10646-1 [ISO-10646].
+
+ Conforming user-agents are required to apply the BIDI presentation
+ algorithm if they display right-to-left characters. If there is
+ no displayable right-to-left character in a document, there is no
+ need to apply BIDI processing.
+
+2. The document character set
+
+2.1. Reference processing model
+
+ This overview explains a reference processing model used for HTML,
+ and in particular the SGML concept of a document character set. An
+ actual implementation may widely differ in its internal workings from
+ the model given below, but should behave as described to an outside
+ observer.
+
+ Because there are various widely differing encodings of text, SGML
+ does not directly address the question of how characters are encoded
+ e.g. in a file. SGML views the characters as a single set (called a
+ "character repertoire"), and a "code set" that assigns an integer
+ number (known as "character number") to each character in the reper-
+ toire. The document character set declaration defines what each of
+ the character numbers represents [GOLD90, p. 451]. In most cases, an
+ SGML DTD and all documents that refer to it have a single document
+ character set, and all markup and data characters are part of this
+ set.
+
+ HTML, as an application of SGML, does not directly address the ques-
+ tion of how characters are encoded as octets in external representa-
+ tions such as files. This is deferred to mechanisms external to HTML,
+ such as MIME as used by the HTTP protocol or by electronic mail.
+
+ For the HTTP protocol [RFC1945], the way characters are encoded is
+
+
+
+
+ Expires 2 December 1996 [Page 4]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ defined by the "charset" parameter[1] of the "Content-Type" field of
+ the header of an HTTP response. For example, to indicate that the
+ transmitted document is encoded in the "JIS" encoding of Japanese
+ [RFC1468], the header will contain the following line:
+
+ Content-Type: text/html; charset=ISO-2022-JP
+
+ The HTTP protocol also defines a mechanism for the client to specify
+ the character encodings it can accept. Clients and servers are
+ strongly requested to use these mechanisms to assure correct trans-
+ mission and interpretation of any document. Provisions that can be
+ taken to help correct interpretation, even in cases where a server or
+ client do not yet use these mechanisms, are described in section 6.
+
+ Similarly, if HTML documents are transferred by electronic mail, the
+ character encoding is defined by the "charset" parameter of the "Con-
+ tent-Type" MIME header line [RFC1521], and defaults to US-ASCII in
+ its absence.
+
+ In the case any other way of transferring and storing HTML documents
+ are defined or become popular, it is advised that similar provisions
+ be made to clearly identify the character encoding used and/or to use
+ a single/default encoding capable of representing the widest range of
+ characters used in an international context.
+
+ Whatever the external character encoding may be, the reference pro-
+ cessing model translates it to a representation of the document char-
+ acter set specified in Section 2.2 before processing specific to
+ SGML/HTML. The reference processing model can be depicted as fol-
+ lows:
+
+ [resource]->[decoder]->[entity ]->[ SGML ]->[application]->[display]
+ [manager] [parser]
+ ^ |
+ | |
+ +----------+
+
+ The decoder is responsible for decoding the external representation
+ of the resource to a representation using the document character set.
+ The entity manager, the parser, and the application deal only with
+ characters of the document character set. A display-oriented part of
+ the application or the display machinery itself may again convert
+-----------
+ 1 The term "charset" in MIME is used to designate a char-
+acter encoding, rather than a coded character set as the
+term may suggest. A character encoding is a mapping (possi-
+bly many-to-one) of a sequence of octets to a sequence of
+characters taken from one or more character repertoires.
+
+
+
+ Expires 2 December 1996 [Page 5]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ characters represented in the document character set to some other
+ representation more suitable for their purpose. In any case, the
+ entity manager, the parser, and the application, as far as character
+ semantics are concerned, are using the HTML document character set
+ only.
+
+ An actual implementation may choose, or not, to translate the docu-
+ ment into some encoding of the document character set as described
+ above; the behaviour described by this reference processing model can
+ be achieved otherwise. This subject is well out of the scope of this
+ specification, however, and the reader is invited to consult the SGML
+ standard [ISO-8879] or an SGML handbook [BRYAN88] [GOLD90] [VANH90]
+ [SQ91] for further information.
+
+ The most important consequence of this reference processing model is
+ that numeric character references are always resolved with respect to
+ the fixed document character set, and thus to the same characters,
+ whatever the external encoding actually used. For an example, see
+ Section 2.2.
+
+2.2. The document character set
+
+ The document character set, in the SGML sense, is the Universal Char-
+ acter Set (UCS) of ISO 10646:1993 [ISO-10646], as amended. Cur-
+ rently, this is code-by-code identical with the Unicode standard,
+ version 1.1 [UNICODE].
+
+ NOTE -- implementers should be aware that ISO 10646 is
+ amended from time to time; 4 amendments have been adopted
+ since the initial 1993 publication, none of which signifi-
+ cantly affects this specification. A fifth amendment, now
+ under consideration, will introduce incompatible changes to
+ the standard: 6556 Korean Hangul syllables allocated
+ between code positions 3400 and 4DFF (hexadecimal) will be
+ moved to new positions (and 4516 new syllables added), thus
+ making references to the old positions invalid. Since the
+ Unicode consortium has already adopted a corresponding
+ amendment for inclusion in the forthcoming Unicode 2.0,
+ adoption of DAM 5 is considered likely and implementers
+ should probably consider the old code positions as already
+ invalid. Despite this one-time change, the relevant stan-
+ dard bodies appear to remain committed not to change any
+ allocated code position in the future. To encode Korean
+ Hangul irrespective of these changes, the combining Hangul
+ Jamo in the range 1110-11F9 can be used.
+
+ The adoption of this document character set implies a change in the
+ SGML declaration specified in the HTML 2.0 specification (section 9.5
+
+
+
+ Expires 2 December 1996 [Page 6]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ of [RFC1866]). The change amounts to removing the first BASESET
+ specification and its accompanying DESCSET declaration, replacing
+ them with the following declaration:
+
+ BASESET "ISO Registration Number 177//CHARSET
+ ISO/IEC 10646-1:1993 UCS-4 with implementation level 3
+ //ESC 2/5 2/15 4/6"
+ DESCSET 0 9 UNUSED
+ 9 2 9
+ 11 2 UNUSED
+ 13 1 13
+ 14 18 UNUSED
+ 32 95 32
+ 127 1 UNUSED
+ 128 32 UNUSED
+ 160 2147483486 160
+
+ Making the UCS the document character set does not create non-
+ conformance of any expression, construct or document that is conform-
+ ing to HTML 2.0. It does make conforming certain constructs that are
+ not admissible in HTML 2.0. One consequence is that data characters
+ outside the repertoire of ISO-8859-1, but within that of UCS-4 become
+ valid SGML characters. Another is that the upper limit of the range
+ of numeric character references is extended from 255 to 2147483645;
+ thus, И is a valid reference to a "CYRILLIC CAPITAL LETTER I".
+ [ERCS] is a good source of information on Unicode and SGML, although
+ its scope and technical content differ greatly from this specifica-
+ tion.
+
+ NOTE -- the above SGML declaration, like that of HTML 2.0,
+ specifies the character numbers 128 to 159 (80 to 9F hex)
+ as UNUSED. This means that numeric character references
+ within that range (e.g. ’) are illegal in HTML. Nei-
+ ther ISO 8859-1 nor ISO 10646 contain characters in that
+ range, which is reserved for control characters.
+
+ ISO 10646-1:1993 is the most encompassing character set currently
+ existing, and there is no other character set that could take its
+ place as the document character set for HTML. If nevertheless for a
+ specific application there is a need to use characters outside this
+ standard, this should be done by avoiding any conflicts with present
+ or future versions of ISO 10646, i.e. by assigning these characters
+ to a private zone. Also, it should be borne in mind that such a use
+ will be highly unportable; in many cases, it may be better to use
+ inline bitmaps.
+
+
+
+
+
+
+ Expires 2 December 1996 [Page 7]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+2.3. Undisplayable characters
+
+ With the document character set being the full ISO 10646, the possi-
+ bility that a character cannot be displayed due to lack of appropri-
+ ate resources (fonts) cannot be avoided. Because there are many dif-
+ ferent things that can be done in such a case, this document does not
+ prescribe any specific behaviour. Depending on the implementation,
+ this may also be handled by the underlaying display system and not
+ the application itself. The following considerations, however, may
+ be of help:
+
+ - A clearly visible, but unobtrusive behaviour should be preferred.
+ Some documents may contain many characters that cannot be renden-
+ dered, and so showing an alert for each of them is not the right
+ thing to do.
+
+ - In case a numeric representation of the missing character is
+ given, its hexadecimal (not decimal) form is to be preferred,
+ because this form is used in character set standards [ERCS].
+
+3. The LANG attribute
+
+ Language tags can be used to control rendering of a marked up docu-
+ ment in various ways: glyph disambiguation, in cases where the char-
+ acter encoding is not sufficient to resolve to a specific glyph; quo-
+ tation marks; hyphenation; ligatures; spacing; voice synthesis; etc.
+ Independently of rendering issues, language markup is useful as con-
+ tent markup for purposes such as classification and searching.
+
+ Since any text can logically be assigned a language, almost all HTML
+ elements admit the LANG attribute. The DTD reflects this. It is
+ also intended that any new element introduced in later versions of
+ HTML will admit the LANG attribute, unless there is a good reason not
+ to do so.
+
+ The language attribute, LANG, takes as its value a language tag that
+ identifies a natural language spoken, written, or otherwise conveyed
+ by human beings for communication of information to other human
+ beings. Computer languages are explicitly excluded.
+
+ The syntax and registry of HTML language tags is the same as that
+ defined by RFC 1766 [RFC1766]. In summary, a language tag is composed
+ of one or more parts: A primary language tag and a possibly empty
+ series of subtags:
+
+ language-tag = primary-tag *( "-" subtag )
+ primary-tag = 1*8ALPHA
+ subtag = 1*8ALPHA
+
+
+
+ Expires 2 December 1996 [Page 8]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ Whitespace is not allowed within the tag and all tags are case-
+ insensitive. The namespace of language tags is administered by the
+ IANA. Example tags include:
+
+ en, en-US, en-cockney, i-cherokee, x-pig-latin
+
+ In the context of HTML, a language tag is not to be interpreted as a
+ single token, as per RFC 1766, but as a hierarchy. For example, a
+ user agent that adjusts rendering according to language should con-
+ sider that it has a match when a language tag in a style sheet entry
+ matches the initial portion of the language tag of an element. An
+ exact match should be preferred. This interpretation allows an ele-
+ ment marked up as, for instance, "en-US" to trigger styles corre-
+ sponding to, in order of preference, US-English ("en-US") or 'plain'
+ or 'international' English ("en").
+
+ NOTE -- using the language tag as a hierarchy does not
+ imply that all languages with a common prefix will be
+ understood by those fluent in one or more of those lan-
+ guages; it simply allows the user to request this commonal-
+ ity when it is true for that user.
+
+ The rendering of elements may be affected by the LANG attribute. For
+ any element, the value of the LANG attribute overrides the value
+ specified by the LANG attribute of any enclosing element and the
+ value (if any) of the HTTP Content-Language header. If none of these
+ are set, a suitable default, perhaps controlled by user preferences,
+ by automatic context analysis or by the user's locale, should be used
+ to control rendering.
+
+4. Additional entities, attributes and elements
+
+4.1. Full Latin-1 entity set
+
+ According to the suggestion of section 14 of [RFC1866], the set of
+ Latin-1 entities is extended to cover the whole right part of
+ ISO-8859-1 (all code positions with the high-order bit set), includ-
+ ing the already commonly used , © and ®. The names of
+ the entities are taken from the appendices of SGML [ISO-8879]. A
+ list is provided in section 7.3 of this specification.
+
+4.2. Markup for language-dependent presentation
+
+
+4.2.1. Overview
+
+ For the correct presentation of text in certain languages (irrespec-
+ tive of formatting issues), some support in the form of additional
+
+
+
+ Expires 2 December 1996 [Page 9]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ entities and elements is needed.
+
+ In particular, the following features are dealt with:
+
+ - Markup of bidirectional text, i.e. text where left-to-right and
+ right-to-left scripts are mixed.
+
+ - Control of cursive joining behaviour in contexts where the default
+ behaviour is not appropriate.
+
+ - Language-dependent rendering of short (in-line) quotations.
+
+ - Better justification control for languages where this is impor-
+ tant.
+
+ - Superscripts and subscripts for languages where they appear as
+ part of general text.
+
+ Some of the above features need very little additional support; oth-
+ ers need more. The additional features are introduced below with
+ brief comments only. Explanations on cursive joining behaviour and
+ bidirectional text follow later. For cursive joining behaviour and
+ bidirectional text, this document follows [UNICODE] in that: i) char-
+ acter semantics, where applicable, are identical to [UNICODE], and
+ ii) where functionality is moved to HTML as a higher level protocol,
+ this is done in a way that allows straightforward conversion to the
+ lower-level mechanisms defined in [UNICODE].
+
+
+4.2.2. List of entities, elements, and attributes
+
+ First, a generic container is needed to carry the LANG and DIR (see
+ below) attributes in cases where no other element is appropriate; the
+ SPAN element is introduced for that purpose.
+
+ A set of named character entities is added for use with bidirectional
+ rendering and cursive joining control:
+
+ <!ENTITY zwnj CDATA "‌"--=zero width non-joiner-->
+ <!ENTITY zwj CDATA "‍"--=zero width joiner-->
+ <!ENTITY lrm CDATA "‎"--=left-to-right mark-->
+ <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
+
+ These entities can be used in place of the corresponding formatting
+ characters whenever convenient, for example to ease keyboard entry or
+ when a formatting character is not available in the character encod-
+ ing of the document.
+
+
+
+
+ Expires 2 December 1996 [Page 10]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ Next, an attribute called DIR is introduced, restricted to the values
+ LTR (left-to-right) and RTL (right-to-left) and admitted by most ele-
+ ments, for the indication of directionality in the context of bidi-
+ rectional text (see 4.2.4 below for details). Since any text and
+ many other elements (e.g. tables) can logically be assigned a direc-
+ tionality, almost all HTML elements admit the DIR attribute. The DTD
+ reflects this. It is also intended that any new element introduced
+ in later versions of HTML will admit the DIR attribute, unless there
+ is a good reason not to do so.
+
+ A new element called BDO (BIDI Override) is introduced, which
+ requires the DIR attribute to specify whether the override is left-
+ to-right or right-to-left. This element is required for bidirec-
+ tional text control; for detailed explanations, see section 4.2.4.
+
+ The <Q> element is introduced to allow language-dependent rendering
+ of short quotations depending on language and platform capability.
+ As the following examples show, in particular the quotation marks
+ surrounding the quotation are affected: "a quotation in English",
+ `another, slightly better one', ,,a quotation in German'', << a quo-
+ tation in French >>. The contents of the <Q> element does not
+ include quotation marks, they have to be added by the rendering pro-
+ cess.
+
+ NOTE -- <Q> elements can be nested. Many languages use dif-
+ ferent quotation styles for outer and inner quotations, and
+ this should be respected by user-agents implementing this
+ element.
+
+ Many languages require superscripts for proper rendering: as an exam-
+ ple, the French "Mlle Dupont" should have "lle" in superscript. The
+ <SUP> element, and its sibling <SUB>, are introduced to allow proper
+ markup of such text. <SUP> and <SUB> contents are restricted to
+ PCDATA to avoid nesting problems.
+
+ Finally, in many languages text justification is much more important
+ than it is in Western languages, and justifies markup. The ALIGN
+ attribute, admitting values of LEFT, RIGHT, CENTER and JUSTIFY, is
+ added to a selection of elements where it makes sense (block-like).
+ If a user-agent chooses to have LEFT as a default for blocks of left-
+ to-right directionality, it should use RIGHT for blocks of right-to-
+ left directionality.
+
+ In the DTD, the LANG and DIR attributes are grouped together in a
+ parameter entity called attrs. In addition, the ID and CLASS
+ attributes from RFC 1942 [RFC1942] were added to attrs, as was done
+ in the latter. The ID, and CLASS attributes are required for use with
+ style sheets, and RFC 1942 defines them as follows:
+
+
+
+ Expires 2 December 1996 [Page 11]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ ID Used to define a document-wide identifier. This can be used
+ for naming positions within documents as the destination of a
+ hypertext link. It may also be used by style sheets for ren-
+ dering an element in a unique style. An ID attribute value is
+ an SGML NAME token. NAME tokens are formed by an initial let-
+ ter followed by letters, digits, "-" and "." characters. The
+ letters are restricted to A-Z and a-z.
+
+ CLASS A space separated list of SGML NAME tokens. CLASS names spec-
+ ify that the element belongs to the corresponding named
+ classes. It allows authors to distinguish different roles
+ played by the same tag. The classes may be used by style
+ sheets to provide different renderings as appropriate to
+ these roles.
+
+4.2.3. Cursive joining behaviour
+
+ Markup is needed in some cases to force cursive joining behavior in
+ contexts in which it would not normally occur, or to block it when it
+ would normally occur.
+
+ The zero-width joiner and non-joiner (‍ and ‌) are used to
+ control cursive joining behaviour. For example, ARABIC LETTER HEH is
+ used in isolation to abbreviate "Hijri" (the Islamic calendrical sys-
+ tem); however, the initial form of the letter is desired, because the
+ isolated form of HEH looks like the digit five as employed in Arabic
+ script. This is obtained by following the HEH with a zero-width
+ joiner whose only effect is to provide context. In Persian texts,
+ there are cases where a letter that normally would join a subsequent
+ letter in a cursive connection does not. Here a zero-width non-
+ joiner is used.
+
+4.2.4. Bidirectional text
+
+ Many languages are written in horizontal lines from left to right,
+ while others are written from right to left. When both writing
+ directions are present, one talks of bidirectional text (BIDI for
+ short). BIDI text requires markup in special circumstances where
+ ambiguities as to the directionality of some characters have to be
+ resolved. This markup affects the ability to render BIDI text in a
+ semantically legible fashion. That is, without this special BIDI
+ markup, cases arise which would prevent *any* rendering whatsoever
+ that reflected the basic meaning of the text. Plain text may contain
+ this markup (joining or BIDI) in the form of special-purpose charac-
+ ters; in HTML, these are supplemented by SGML markup.
+
+ BIDI is a complex issue, and implementers are advised to consult
+ appropriate documentation such as [UNICODE]. Here, explanations are
+
+
+
+ Expires 2 December 1996 [Page 12]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ given only as far as they are needed to understand the necessity of
+ the features introduced and to define their exact semantics.
+
+ The Unicode BIDI algorithm is based on a logical sequence of text
+ characters and works mainly by reference to the implicit directional-
+ ity of characters (e.g. Hebrew and Arabic characters are specified to
+ be rendered from right to left, etc.).
+
+ The left-to-right and right-to-left marks (‎ and ‏) are used
+ to disambiguate directionality of neutral characters. For example,
+ when a double quote sits between an Arabic and a Latin letter, its
+ direction is ambiguous; if a directional mark is added on one side
+ such that the quotation mark is surrounded by characters of only one
+ directionality, the ambiguity is removed. These characters are like
+ zero width spaces which have a directional property (but no word/line
+ break property).
+
+ Nested embeddings of contra-directional text runs, due to nested quo-
+ tations or to the pasting of text from one BIDI context to another,
+ is also a case where the implicit directionality of characters is not
+ sufficient, requiring markup. Also, it is frequently desirable to
+ specify the basic directionality of a block of text. For these pur-
+ poses, the DIR attribute is used.
+
+ On block-type elements, the DIR attribute indicates the base direc-
+ tionality of the text in the block; if omitted it is inherited from
+ the parent element. The default directionality of the overall HTML
+ document is left-to-right.
+
+ On inline elements, it makes the element start a new embedding level
+ (to be explained below); if omitted the inline element does not start
+ a new embedding level.
+
+ NOTE -- the PRE, XMP and LISTING elements admit the DIR
+ attribute, indicating that the contents should not be con-
+ sidered as preformatted with respect to bidirectional lay-
+ out. The BIDI algorithm still needs to be applied to each
+ line of text.
+
+ Following is an example of a case where embedding is needed, showing
+ its effect:
+
+ Given the following latin (upper case) and arabic (lower
+ case) letters in backing store with the specified embed-
+ dings:
+
+ <SPAN DIR=LTR> AB <SPAN DIR=RTL> xy <SPAN DIR=LTR> CD
+ </SPAN> zw </SPAN> EF </SPAN>
+
+
+
+ Expires 2 December 1996 [Page 13]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ One gets the following rendering (with [] showing the
+ directional transitions):
+
+ [ AB [ wz [ CD ] yx ] EF ]
+
+ On the other hand, without this markup and with a base
+ direction of LTR one gets the following rendering:
+
+ [ AB [ yx ] CD [ wz ] EF ]
+
+ Notice that yx is on the left and wz on the right unlike
+ the above case where the embedding levels are used. With-
+ out the embedding markup one has at most two levels: a base
+ directional level and a single counterflow directional
+ level.
+
+ The DIR attribute on inline elements is equivalent to the formatting
+ characters LEFT-TO-RIGHT EMBEDDING (202A) and RIGHT-TO-LEFT EMBED-
+ DING (202B) of ISO 10646. The end tag of the element is equivalent
+ to the POP DIRECTIONAL FORMATTING (202C) character.
+
+ Directional override, as provided by the <BDO> element, is needed to
+ deal with unusual short pieces of text in which directionality cannot
+ be resolved from context in an unambiguous fashion. For example, it
+ can be used to force left-to-right (or right-to-left) display of part
+ numbers composed of Latin letters, digits and Hebrew letters.
+
+ The effect of <BDO> is to force the directionality of all characters
+ within it to the value of DIR, irrespective of their intrinsic direc-
+ tional properties. It is equivalent to using the LEFT-TO-RIGHT OVER-
+ RIDE (202D) or RIGHT-TO-LEFT OVERRIDE (202E) characters of ISO 10646,
+ the end tag again being equivalent to the POP DIRECTIONAL FORMATTING
+ (202C) character.
+
+ NOTE -- authors and authoring software writers should be
+ aware that conflicts can arise if the DIR attribute is used
+ on inline elements (including <BDO>) concurrently with the
+ use of the corresponding ISO 10646 formatting characters.
+ Preferably one or the other should be used exclusively; the
+ markup method is better able to guarantee document struc-
+ tural integrity, and alleviates some problems when editing
+ bidirectional HTML text with a simple text editor, but some
+ software may be more apt at using the 10646 characters. If
+ both methods are used, great care should be exercised to
+ insure proper nesting of markup and directional embedding
+ or override; otherwise, rendering results are undefined.
+
+
+
+
+
+ Expires 2 December 1996 [Page 14]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+5. Forms
+
+
+5.1. DTD additions
+
+ It is natural to expect input in any language in forms, as they pro-
+ vide one of the only ways of obtaining user input. While this is pri-
+ marily a UI issue, there are some things that should be specified at
+ the HTML level to guide behavior and promote interoperability.
+
+ To ensure full interoperability, it is necessary for the user agent
+ (and the user) to have an indication of the character encoding(s)
+ that the server providing a form will be able to handle upon submis-
+ sion of the filled-in form. Such an indication is provided by the
+ ACCEPT-CHARSET attribute of the INPUT and TEXTAREA elements, modeled
+ on the HTTP Accept-Charset header (see [HTTP-1.1]), which contains a
+ space and/or comma delimited list of character sets acceptable to the
+ server. A user agent may want to somehow advise the user of the con-
+ tents of this attribute, or to restrict his possibility to enter
+ characters outside the repertoires of the listed character sets.
+
+ NOTE -- The list of character sets is to be interpreted as
+ an EXCLUSIVE-OR list; the server announces that it is ready
+ to accept any ONE of these character encoding schemes for
+ each part of a multipart entity. The client may perform
+ character encoding translation to satisfy the server if
+ necessary.
+
+ NOTE -- The default value for the ACCEPT-CHARSET attribute
+ of an INPUT or TEXTAREA element is the reserved value
+ "UNKNOWN". A user agent may interpret that value as the
+ character encoding scheme that was used to transmit the
+ document containing that element.
+
+
+5.2. Form submission
+
+ The HTML 2.0 form submission mechanism, based on the "application/x-
+ www-form-urlencoded" media type, is ill-equipped with regard to
+ internationalization. In fact, since URLs are restricted to ASCII
+ characters, the mechanism is akward even for ISO-8859-1 text. Sec-
+ tion 2.2 of [RFC1738] specifies that octets may be encoded using the
+ "%HH" notation, but text submitted from a form is composed of charac-
+ ters, not octets. Lacking a specification of a character encoding
+ scheme, the "%HH" notation has no well-defined meaning.
+
+ The best solution is to use the "multipart/form-data" media type
+ described in [RFC1867] with the POST method of form submission. This
+
+
+
+ Expires 2 December 1996 [Page 15]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ mechanism encapsulates the value part of each name-value pair in a
+ body-part of a multipart MIME body that is sent as the HTTP entity;
+ each body part can be labeled with an appropriate Content-Type,
+ including if necessary a charset parameter that specifies the charac-
+ ter encoding scheme. The changes to the DTD necessary to support
+ this method of form submission have been incorporated in the DTD
+ included in this specification.
+
+ A less satisfactory solution is to add a MIME charset parameter to
+ the "application/x-www-form-urlencoded" media type specifier sent
+ along with a POST method form submission, with the understanding that
+ the URL encoding of [RFC1738] is applied on top of the specified
+ character encoding, as a kind of implicit Content-Transfer-Encoding.
+
+ One problem with both solutions above is that current browsers do not
+ generally allow for bookmarks to specify the POST method; this should
+ be improved. Conversely, the GET method could be used with the form
+ data transmitted in the body instead of in the URL. Nothing in the
+ protocol seems to prevent it, but no implementations appear to exist
+ at present.
+
+ How the user agent determines the encoding of the text entered by the
+ user is outside the scope of this specification.
+
+ NOTE -- Designers of forms and their handling scripts
+ should be aware of an important caveat: when the default
+ value of a field (the VALUE attribute) is returned upon
+ form submission (i.e. the user did not modify this value),
+ it cannot be guaranteed to be transmitted as a sequence of
+ octets identical to that in the source document -- only as
+ a possibly different but valid encoding of the same
+ sequence of text elements. This may be true even if the
+ encoding of the document containing the form and that used
+ for submission are the same.
+
+ Differences can occur when a sequence of characters can be
+ represented by various sequences of octets, and also when a
+ composite sequence (a base character plus one or more com-
+ bining diacritics) can be represented by either a different
+ but equivalent composite sequence or by a fully precomposed
+ character. For instance, the UCS-2 sequence 00EA+0232
+ (LATIN SMALL LETTER E WITH CIRCUMFLEX ACCENT + COMBINING
+ DOT BELOW) may be transformed into 1EC7 (LATIN SMALL LETTER
+ E WITH CIRCUMFLEX ACCENT AND DOT BELOW), into
+ 0065+0302+0323 (LATIN SMALL LETTER E + COMBINING CIRCUMFLEX
+ ACCENT + COMBINING DOT BELOW), as well as into other equiv-
+ alent composite sequences.
+
+
+
+
+ Expires 2 December 1996 [Page 16]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+6. Miscellaneous
+
+ Proper interpretation of a text document requires that the character
+ encoding scheme be known. Current HTTP servers, however, do not gen-
+ erally include an appropriate charset parameter with the Content-Type
+ header. This is bad behaviour[2], and as such strongly discouraged,
+ but some preventive measures can be taken to minimize the detrimental
+ effects.
+
+ In the case where a document is accessed from a hyperlink in an ori-
+ gin HTML document, a CHARSET attribute is added to the attribute list
+ of elements with link semantics (A and LINK), specifically by adding
+ it to the linkExtraAttributes entity. The value of that attribute is
+ to be considered a hint to the User Agent as to the character encod-
+ ing scheme used by the ressource pointed to by the hyperlink; it
+ should be the appropriate value of the MIME charset parameter for
+ that ressource.
+
+ In any document, it is possible to include an indication of the
+ encoding scheme like the following, as early as possible within the
+ HEAD of the document:
+
+ <META HTTP-EQUIV="Content-Type"
+ CONTENT="text/html; charset=ISO-2022-JP">
+
+ This is not foolproof, but will work if the encoding scheme is such
+ that ASCII characters stand for themselves at least until the META
+ element is parsed. Note that there are better ways for a server to
+ obtain character encoding information, instead of the unreliable
+ <META> above; see [NICOL2] for some details and a proposal.
+
+ For definiteness, the "charset" parameter received from the source of
+ the document should be considered the most authoritative, followed in
+ order of preference by the contents of a META element such as the
+ above, and finally the CHARSET parameter of the anchor that was fol-
+ lowed (if any).
+
+ When HTML text is transmitted directly in UCS-2 or UCS-4 form, the
+ question of byte order arises: does the high-order byte of each
+ multi-byte character come first or last? For definiteness, this
+ specification recommends that UCS-2 and UCS-4 be transmitted in big-
+-----------
+ 2 This bad behaviour is even encouraged by the continued
+existence of browsers that declare an unrecognized media
+type when they receive a charset parameter. User agent
+implementators are strongly encouraged to make their soft-
+ware tolerant of this parameter, even if they cannot take
+advantage of it.
+
+
+
+ Expires 2 December 1996 [Page 17]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ endian byte order (high order byte first), which corresponds to the
+ established network byte order for two- and four-byte quantities, to
+ the Unicode recommendation for serialized text data and to RFC 1641.
+ Furthermore, to maximize chances of proper interpretation, it is rec-
+ ommended that documents transmitted as UCS-2 or UCS-4 always begin
+ with a ZERO-WIDTH NON-BREAKING SPACE character (hexadecimal FEFF or
+ 0000FEFF) which, when byte-reversed becomes number FFFE or FFFE0000,
+ a character guaranteed to be never assigned. Thus, a user-agent
+ receiving an FFFE as the first octets of a text would know that bytes
+ have to be reversed for the remainder of the text.
+
+ There exist so-called UCS Transformation Formats than can be used to
+ transmit UCS data, in addition to UCS-2 and UCS-4. UTF-7 [RFC1642]
+ and UTF-8 [UTF-8] have favorable properties (no byte-ordering prob-
+ lem, different flavours of ASCII compatibility) that make them worthy
+ of consideration, especially for transmission of multilingual text.
+ Another encoding scheme, MNEM [RFC1345], also has interesting proper-
+ ties and the capability to transmit the full UCS. The UTF-1 trans-
+ formation format of ISO 10646:1993 (registered by IANA as
+ ISO-10646-UTF-1), has been removed from ISO 10646 by amendment 4, and
+ should not be used.
+
+ The SOFT HYPHEN character (U+00AD) needs a little attention from
+ user-agent implementers. It is present in many character sets
+ (including the whole ISO 8859 series and, of course, ISO 10646), and
+ has semantics different from the plain HYPHEN. If not used for
+ hyphenation, the soft hyphen must be completely ignored. For exam-
+ ple, "rec­ord" should display as "record", should match a search
+ for "record", and should sort as "record". Non-observance of these
+ semantics effectively discourages its use on the World Wide Web, even
+ with software that does support it.
+
+7. HTML Public Text
+
+7.1. HTML DTD
+
+ This section contains a DTD for HTML based on the HTML 2.0 DTD of RFC
+ 1866, incorporating the changes for file upload as specified in RFC
+ 1867, and the changes deriving from this document.
+
+ <!-- html.dtd
+
+ Document Type Definition for the HyperText Markup Language,
+ extended for internationalisation (HTML DTD)
+
+ Last revised: 96/05/27
+
+ Authors: Daniel W. Connolly <connolly@w3.org>
+
+
+
+ Expires 2 December 1996 [Page 18]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ Francois Yergeau <yergeau@alis.com>
+ See Also: html.decl, html-1.dtd
+ http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
+ -->
+
+ <!ENTITY % HTML.Version
+ "-//IETF//DTD HTML//EN"
+
+ -- Typical usage:
+
+ <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+ <html>
+ ...
+ </html>
+ --
+ >
+
+
+ <!--============ Feature Test Entities ========================-->
+
+ <!ENTITY % HTML.Recommended "IGNORE"
+ -- Certain features of the language are necessary for
+ compatibility with widespread usage, but they may
+ compromise the structural integrity of a document.
+ This feature test entity enables a more prescriptive
+ document type definition that eliminates
+ those features.
+ -->
+
+ <![ %HTML.Recommended [
+ <!ENTITY % HTML.Deprecated "IGNORE">
+ ]]>
+
+ <!ENTITY % HTML.Deprecated "INCLUDE"
+ -- Certain features of the language are necessary for
+ compatibility with earlier versions of the specification,
+ but they tend to be used and implemented inconsistently,
+ and their use is deprecated. This feature test entity
+ enables a document type definition that eliminates
+ these features.
+ -->
+
+ <!ENTITY % HTML.Highlighting "INCLUDE"
+ -- Use this feature test entity to validate that a
+ document uses no highlighting tags, which may be
+ ignored on minimal implementations.
+ -->
+
+
+
+
+ Expires 2 December 1996 [Page 19]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ENTITY % HTML.Forms "INCLUDE"
+ -- Use this feature test entity to validate that a document
+ contains no forms, which may not be supported in minimal
+ implementations
+ -->
+
+ <!--============== Imported Names ==============================-->
+
+ <!ENTITY % Content-Type "CDATA"
+ -- meaning an internet media type
+ (aka MIME content type, as per RFC1521)
+ -->
+
+ <!ENTITY % HTTP-Method "GET | POST"
+ -- as per HTTP specification, RFC1945
+ -->
+
+ <!--========= DTD "Macros" =====================-->
+
+ <!ENTITY % heading "H1|H2|H3|H4|H5|H6">
+
+ <!ENTITY % list " UL | OL | DIR | MENU " >
+
+ <!ENTITY % attrs -- common attributes for elements --
+ "LANG NAME #IMPLIED -- RFC 1766 language tag --
+ DIR (ltr|rtl) #IMPLIED -- text directionnality --
+ ID ID #IMPLIED -- element identifier (from RFC1942) --
+ CLASS NAMES #IMPLIED -- for subclassing elements (from RFC1942) --">
+
+ <!ENTITY % just -- an attribute for text justification --
+ "ALIGN (left|right|center|justify) #IMPLIED"
+ -- default is left for ltr paragraphs, right for rtl -- >
+
+ <!--======= Character mnemonic entities =================-->
+
+ <!ENTITY % ISOlat1 PUBLIC
+ "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
+ %ISOlat1;
+
+ <!ENTITY amp CDATA "&" -- ampersand -->
+ <!ENTITY gt CDATA ">" -- greater than -->
+ <!ENTITY lt CDATA "<" -- less than -->
+ <!ENTITY quot CDATA """ -- double quote -->
+
+ <!--Entities for language-dependent presentation (BIDI and contextual analysis) -->
+ <!ENTITY zwnj CDATA "‌"-- zero width non-joiner-->
+ <!ENTITY zwj CDATA "‍"-- zero width joiner-->
+ <!ENTITY lrm CDATA "‎"-- left-to-right mark-->
+
+
+
+ Expires 2 December 1996 [Page 20]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ENTITY rlm CDATA "‏"-- right-to-left mark-->
+
+
+ <!--========= SGML Document Access (SDA) Parameter Entities =====-->
+
+ <!-- HTML contains SGML Document Access (SDA) fixed attributes
+ in support of easy transformation to the International Committee
+ for Accessible Document Design (ICADD) DTD
+ "-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
+ ICADD applications are designed to support usable access to
+ structured information by print-impaired individuals through
+ Braille, large print and voice synthesis. For more information on
+ SDA & ICADD:
+ - ISO 12083:1993, Annex A.8, Facilities for Braille,
+ large print and computer voice
+ - ICADD ListServ
+ <ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
+ - Usenet news group bit.listserv.easi
+ - Recording for the Blind, +1 800 221 4792
+ -->
+
+ <!ENTITY % SDAFORM "SDAFORM CDATA #FIXED"
+ -- one to one mapping -->
+ <!ENTITY % SDARULE "SDARULE CDATA #FIXED"
+ -- context-sensitive mapping -->
+ <!ENTITY % SDAPREF "SDAPREF CDATA #FIXED"
+ -- generated text prefix -->
+ <!ENTITY % SDASUFF "SDASUFF CDATA #FIXED"
+ -- generated text suffix -->
+ <!ENTITY % SDASUSP "SDASUSP NAME #FIXED"
+ -- suspend transform process -->
+
+
+ <!--========== Text Markup =====================-->
+
+ <![ %HTML.Highlighting [
+
+ <!ENTITY % font " TT | B | I ">
+
+ <!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE ">
+
+ <!ENTITY % text "#PCDATA|A|IMG|BR|%phrase|%font|SPAN|Q|BDO|SUP|SUB">
+
+ <!ELEMENT (%font;|%phrase) - - (%text)*>
+ <!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
+ %attrs;
+ %SDAFORM; "Lit"
+ >
+
+
+
+ Expires 2 December 1996 [Page 21]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ATTLIST ( B | STRONG )
+ %attrs;
+ %SDAFORM; "B"
+ >
+ <!ATTLIST ( I | EM | CITE )
+ %attrs;
+ %SDAFORM; "It"
+ >
+
+ <!-- <TT> Typewriter text -->
+ <!-- <B> Bold text -->
+ <!-- <I> Italic text -->
+
+ <!-- <EM> Emphasized phrase -->
+ <!-- <STRONG> Strong emphasis -->
+ <!-- <CODE> Source code phrase -->
+ <!-- <SAMP> Sample text or characters -->
+ <!-- <KBD> Keyboard phrase, e.g. user input -->
+ <!-- <VAR> Variable phrase or substitutable -->
+ <!-- <CITE> Name or title of cited work -->
+
+ <!ENTITY % pre.content "#PCDATA|A|HR|BR|%font|%phrase|SPAN|BDO">
+
+ ]]>
+
+ <!ENTITY % text "#PCDATA|A|IMG|BR|SPAN|Q|BDO|SUP|SUB">
+
+ <!ELEMENT BR - O EMPTY>
+ <!ATTLIST BR
+ %SDAPREF; "&#RE;"
+ >
+
+ <!-- <BR> Line break -->
+
+ <!ELEMENT SPAN - - (%text)*>
+ <!ATTLIST SPAN
+ %attrs;
+ %SDAFORM; "other #Attlist"
+ >
+
+ <!-- <SPAN> Generic inline container -->
+ <!-- <SPAN DIR=...> New counterflow embedding -->
+ <!-- <SPAN LANG="..."> Language of contents -->
+
+ <!ELEMENT Q - - (%text)*>
+ <!ATTLIST Q
+ %attrs;
+ %SDAPREF; '"'
+
+
+
+ Expires 2 December 1996 [Page 22]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ %SDASUFF; '"'
+ >
+
+ <!-- <Q> Short quotation -->
+ <!-- <Q LANG=xx> Language of quotation is xx -->
+ <!-- <Q DIR=...> New conterflow embedding -->
+
+ <!ELEMENT BDO - - (%text)+>
+ <!ATTLIST BDO
+ LANG NAME #IMPLIED
+ DIR (ltr|rtl) #REQUIRED
+ %SDAPREF "Bidi Override #Attval(DIR): "
+ %SDASUFF "End Bidi"
+ >
+
+ <!-- <BDO DIR=...> Override directionality of text to value of DIR -->
+ <!-- <BDO LANG=...> Language of contents -->
+
+ <!ELEMENT (SUP|SUB) - - (#PCDATA)>
+ <!ATTLIST (SUP)
+ %attrs;
+ %SDAPREF "Superscript(#content)"
+ >
+ <!ATTLIST (SUB)
+ %attrs;
+ %SDAPREF "Subscript(#content)"
+ >
+
+ <!-- <SUP> Superscript -->
+ <!-- <SUB> Subscript -->
+
+ <!--========= Link Markup ======================-->
+
+ <!ENTITY % linkType "NAMES">
+
+ <!ENTITY % linkExtraAttributes
+ "REL %linkType #IMPLIED
+ REV %linkType #IMPLIED
+ URN CDATA #IMPLIED
+ TITLE CDATA #IMPLIED
+ METHODS NAMES #IMPLIED
+ CHARSET NAME #IMPLIED
+ ">
+
+ <![ %HTML.Recommended [
+ <!ENTITY % A.content "(%text)*"
+ -- <H1><a name="xxx">Heading</a></H1>
+ is preferred to
+
+
+
+ Expires 2 December 1996 [Page 23]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <a name="xxx"><H1>Heading</H1></a>
+ -->
+ ]]>
+
+ <!ENTITY % A.content "(%heading|%text)*">
+
+ <!ELEMENT A - - %A.content -(A)>
+ <!ATTLIST A
+ %attrs;
+ HREF CDATA #IMPLIED
+ NAME CDATA #IMPLIED
+ %linkExtraAttributes;
+ %SDAPREF; "<Anchor: #AttList>"
+ >
+ <!-- <A> Anchor; source/destination of link -->
+ <!-- <A NAME="..."> Name of this anchor -->
+ <!-- <A HREF="..."> Address of link destination -->
+ <!-- <A URN="..."> Permanent address of destination -->
+ <!-- <A REL=...> Relationship to destination -->
+ <!-- <A REV=...> Relationship of destination to this -->
+ <!-- <A TITLE="..."> Title of destination (advisory) -->
+ <!-- <A METHODS="..."> Operations on destination (advisory) -->
+ <!-- <A CHARSET="..."> Charset of destination (advisory) -->
+ <!-- <A LANG="..."> Language of contents btw <A> and </A> -->
+ <!-- <A DIR=...> Contents is a new counterflow embedding -->
+
+ <!--========== Images ==========================-->
+
+ <!ELEMENT IMG - O EMPTY>
+ <!ATTLIST IMG
+ %attrs;
+ SRC CDATA #REQUIRED
+ ALT CDATA #IMPLIED
+ ALIGN (top|middle|bottom) #IMPLIED
+ ISMAP (ISMAP) #IMPLIED
+ %SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
+ >
+
+ <!-- <IMG> Image; icon, glyph or illustration -->
+ <!-- <IMG SRC="..."> Address of image object -->
+ <!-- <IMG ALT="..."> Textual alternative -->
+ <!-- <IMG ALIGN=...> Position relative to text -->
+ <!-- <IMG LANG=...> Image contains "text" in that language -->
+ <!-- <IMG DIR=rtl> Inline image acts as a right-to-left
+ embedding w/r to BIDI algorithm -->
+ <!-- <IMG ISMAP> Each pixel can be a link -->
+
+ <!--========== Paragraphs=======================-->
+
+
+
+ Expires 2 December 1996 [Page 24]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ELEMENT P - O (%text)*>
+ <!ATTLIST P
+ %attrs;
+ %just;
+ %SDAFORM; "Para"
+ >
+
+ <!-- <P> Paragraph -->
+ <!-- <P LANG="..."> Language of paragraph text -->
+ <!-- <P DIR=...> Base directionality of paragraph -->
+ <!-- <P ALIGN=...> Paragraph alignment (justification) -->
+
+ <!--========== Headings, Titles, Sections ===============-->
+
+ <!ELEMENT HR - O EMPTY>
+ <!ATTLIST HR
+ %just;
+ %SDAPREF; "&#RE;&#RE;"
+ >
+
+ <!-- <HR> Horizontal rule -->
+
+ <!ELEMENT ( %heading ) - - (%text;)*>
+ <!ATTLIST H1
+ %attrs;
+ %just;
+ %SDAFORM; "H1"
+ >
+ <!ATTLIST H2
+ %attrs;
+ %just;
+ %SDAFORM; "H2"
+ >
+ <!ATTLIST H3
+ %attrs;
+ %just;
+ %SDAFORM; "H3"
+ >
+ <!ATTLIST H4
+ %attrs;
+ %just;
+ %SDAFORM; "H4"
+ >
+ <!ATTLIST H5
+ %attrs;
+ %just;
+ %SDAFORM; "H5"
+ >
+
+
+
+ Expires 2 December 1996 [Page 25]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ATTLIST H6
+ %attrs;
+ %just;
+ %SDAFORM; "H6"
+ >
+
+ <!-- <H1> Heading, level 1 -->
+ <!-- <H2> Heading, level 2 -->
+ <!-- <H3> Heading, level 3 -->
+ <!-- <H4> Heading, level 4 -->
+ <!-- <H5> Heading, level 5 -->
+ <!-- <H6> Heading, level 6 -->
+
+
+ <!--========== Text Flows ======================-->
+
+ <![ %HTML.Forms [
+ <!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
+ ]]>
+
+ <!ENTITY % block.forms "BLOCKQUOTE">
+
+ <![ %HTML.Deprecated [
+ <!ENTITY % preformatted "PRE | XMP | LISTING">
+ ]]>
+
+ <!ENTITY % preformatted "PRE">
+
+ <!ENTITY % block "P | %list | DL
+ | %preformatted
+ | %block.forms">
+
+ <!ENTITY % flow "(%text|%block)*">
+
+ <!ENTITY % pre.content "#PCDATA | A | HR | BR | SPAN | BDO">
+ <!ELEMENT PRE - - (%pre.content)*>
+ <!ATTLIST PRE
+ %attrs;
+ WIDTH NUMBER #implied
+ %SDAFORM; "Lit"
+ >
+
+ <!-- <PRE> Preformatted text -->
+ <!-- <PRE WIDTH=...> Maximum characters per line -->
+ <!-- <PRE DIR=...> Base direction of preformatted block -->
+ <!-- <PRE LANG=...> Language of contents -->
+
+ <![ %HTML.Deprecated [
+
+
+
+ Expires 2 December 1996 [Page 26]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ENTITY % literal "CDATA"
+ -- historical, non-conforming parsing mode where
+ the only markup signal is the end tag
+ in full
+ -->
+
+ <!ELEMENT (XMP|LISTING) - - %literal>
+ <!ATTLIST XMP
+ %attrs;
+ %SDAFORM; "Lit"
+ %SDAPREF; "Example:&#RE;"
+ >
+ <!ATTLIST LISTING
+ %attrs;
+ %SDAFORM; "Lit"
+ %SDAPREF; "Listing:&#RE;"
+ >
+
+ <!-- <XMP> Example section -->
+ <!-- <LISTING> Computer listing -->
+
+ <!ELEMENT PLAINTEXT - O %literal>
+ <!-- <PLAINTEXT> Plain text passage -->
+
+ <!ATTLIST PLAINTEXT
+ %attrs;
+ %SDAFORM; "Lit"
+ >
+ ]]>
+
+
+ <!--========== Lists ==================-->
+
+ <!ELEMENT DL - - (DT | DD)+>
+ <!ATTLIST DL
+ %attrs;
+ COMPACT (COMPACT) #IMPLIED
+ %SDAFORM; "List"
+ %SDAPREF; "Definition List:"
+ >
+
+ <!ELEMENT DT - O (%text)*>
+ <!ATTLIST DT
+ %attrs;
+ %SDAFORM; "Term"
+ >
+
+ <!ELEMENT DD - O %flow>
+
+
+
+ Expires 2 December 1996 [Page 27]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ATTLIST DD
+ %attrs;
+ %SDAFORM; "LItem"
+ >
+
+ <!-- <DL> Definition list, or glossary -->
+ <!-- <DL COMPACT> Compact style list -->
+ <!-- <DT> Term in definition list -->
+ <!-- <DD> Definition of term -->
+
+ <!ELEMENT (OL|UL) - - (LI)+>
+ <!ATTLIST OL
+ %attrs;
+ %just;
+ COMPACT (COMPACT) #IMPLIED
+ %SDAFORM; "List"
+ >
+ <!ATTLIST UL
+ %attrs;
+ %just;
+ COMPACT (COMPACT) #IMPLIED
+ %SDAFORM; "List"
+ >
+ <!-- <UL> Unordered list -->
+ <!-- <UL COMPACT> Compact list style -->
+ <!-- <OL> Ordered, or numbered list -->
+ <!-- <OL COMPACT> Compact list style -->
+
+
+ <!ELEMENT (DIR|MENU) - - (LI)+ -(%block)>
+ <!ATTLIST DIR
+ %attrs;
+ %just;
+ COMPACT (COMPACT) #IMPLIED
+ %SDAFORM; "List"
+ %SDAPREF; "<LHead>Directory</LHead>"
+ >
+ <!ATTLIST MENU
+ %attrs;
+ %just;
+ COMPACT (COMPACT) #IMPLIED
+ %SDAFORM; "List"
+ %SDAPREF; "<LHead>Menu</LHead>"
+ >
+
+ <!-- <DIR> Directory list -->
+ <!-- <DIR COMPACT> Compact list style -->
+ <!-- <MENU> Menu list -->
+
+
+
+ Expires 2 December 1996 [Page 28]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!-- <MENU COMPACT> Compact list style -->
+
+ <!ELEMENT LI - O %flow>
+ <!ATTLIST LI
+ %attrs;
+ %just;
+ %SDAFORM; "LItem"
+ >
+
+ <!-- <LI> List item -->
+
+ <!--========== Document Body ===================-->
+
+ <![ %HTML.Recommended [
+ <!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
+ -- <h1>Heading</h1>
+ <p>Text ...
+ is preferred to
+ <h1>Heading</h1>
+ Text ...
+ -->
+ ]]>
+
+ <!ENTITY % body.content "(%heading | %text | %block |
+ HR | ADDRESS)*">
+
+ <!ELEMENT BODY O O %body.content>
+ <!ATTLIST BODY
+ %attrs;
+ >
+
+ <!-- <BODY> Document body -->
+ <!-- <BODY DIR=...> Base direction of whole body -->
+ <!-- <BODY LANG=...> Language of contents -->
+
+ <!ELEMENT BLOCKQUOTE - - %body.content>
+ <!ATTLIST BLOCKQUOTE
+ %attrs;
+ %just;
+ %SDAFORM; "BQ"
+ >
+
+ <!-- <BLOCKQUOTE> Quoted passage -->
+
+ <!ELEMENT ADDRESS - - (%text|P)*>
+ <!ATTLIST ADDRESS
+ %attrs;
+ %just;
+
+
+
+ Expires 2 December 1996 [Page 29]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ %SDAFORM; "Lit"
+ %SDAPREF; "Address:&#RE;"
+ >
+
+ <!-- <ADDRESS> Address, signature, or byline -->
+
+
+ <!--======= Forms ====================-->
+
+ <![ %HTML.Forms [
+
+ <!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
+ <!ATTLIST FORM
+ %attrs;
+ ACTION CDATA #IMPLIED
+ METHOD (%HTTP-Method) GET
+ ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
+ %SDAPREF; "<Para>Form:</Para>"
+ %SDASUFF; "<Para>Form End.</Para>"
+ >
+
+ <!-- <FORM> Fill-out or data-entry form -->
+ <!-- <FORM ACTION="..."> Address for completed form -->
+ <!-- <FORM METHOD=...> Method of submitting form -->
+ <!-- <FORM ENCTYPE="..."> Representation of form data -->
+ <!-- <FORM DIR=...> Base direction of form -->
+ <!-- <FORM LANG=...> Language of contents -->
+
+ <!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
+ RADIO | SUBMIT | RESET |
+ IMAGE | HIDDEN | FILE )">
+ <!ELEMENT INPUT - O EMPTY>
+ <!ATTLIST INPUT
+ %attrs;
+ TYPE %InputType TEXT
+ NAME CDATA #IMPLIED
+ VALUE CDATA #IMPLIED
+ SRC CDATA #IMPLIED
+ CHECKED (CHECKED) #IMPLIED
+ SIZE CDATA #IMPLIED
+ MAXLENGTH NUMBER #IMPLIED
+ ALIGN (top|middle|bottom) #IMPLIED
+ ACCEPT CDATA #IMPLIED --list of content types --
+ ACCEPT-CHARSET CDATA #IMPLIED --list of charsets accepted by server --
+ %SDAPREF; "Input: "
+ >
+
+ <!-- <INPUT> Form input datum -->
+
+
+
+ Expires 2 December 1996 [Page 30]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!-- <INPUT TYPE=...> Type of input interaction -->
+ <!-- <INPUT NAME=...> Name of form datum -->
+ <!-- <INPUT VALUE="..."> Default/initial/selected value -->
+ <!-- <INPUT SRC="..."> Address of image -->
+ <!-- <INPUT CHECKED> Initial state is "on" -->
+ <!-- <INPUT SIZE=...> Field size hint -->
+ <!-- <INPUT MAXLENGTH=...> Data length maximum -->
+ <!-- <INPUT ALIGN=...> Image alignment -->
+ <!-- <INPUT ACCEPT="..."> List of desired media types -->
+ <!-- <INPUT ACCEPT-CHARSET="..."> List of acceptable charsets -->
+
+ <!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
+ <!ATTLIST SELECT
+ %attrs;
+ NAME CDATA #REQUIRED
+ SIZE NUMBER #IMPLIED
+ MULTIPLE (MULTIPLE) #IMPLIED
+ %SDAFORM; "List"
+ %SDAPREF;
+ "<LHead>Select #AttVal(Multiple)</LHead>"
+ >
+
+ <!-- <SELECT> Selection of option(s) -->
+ <!-- <SELECT NAME=...> Name of form datum -->
+ <!-- <SELECT SIZE=...> Options displayed at a time -->
+ <!-- <SELECT MULTIPLE> Multiple selections allowed -->
+
+ <!ELEMENT OPTION - O (#PCDATA)*>
+ <!ATTLIST OPTION
+ %attrs;
+ SELECTED (SELECTED) #IMPLIED
+ VALUE CDATA #IMPLIED
+ %SDAFORM; "LItem"
+ %SDAPREF;
+ "Option: #AttVal(Value) #AttVal(Selected)"
+ >
+
+ <!-- <OPTION> A selection option -->
+ <!-- <OPTION SELECTED> Initial state -->
+ <!-- <OPTION VALUE="..."> Form datum value for this option-->
+
+ <!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
+ <!ATTLIST TEXTAREA
+ %attrs;
+ NAME CDATA #REQUIRED
+ ROWS NUMBER #REQUIRED
+ COLS NUMBER #REQUIRED
+ ACCEPT-CHARSET CDATA #IMPLIED -- list of charsets accepted by server --
+
+
+
+ Expires 2 December 1996 [Page 31]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ %SDAFORM; "Para"
+ %SDAPREF; "Input Text -- #AttVal(Name): "
+ >
+
+ <!-- <TEXTAREA> An area for text input -->
+ <!-- <TEXTAREA NAME=...> Name of form datum -->
+ <!-- <TEXTAREA ROWS=...> Height of area -->
+ <!-- <TEXTAREA COLS=...> Width of area -->
+
+ ]]>
+
+
+ <!--======= Document Head ======================-->
+
+ <![ %HTML.Recommended [
+ <!ENTITY % head.extra "">
+ ]]>
+ <!ENTITY % head.extra "& NEXTID?">
+
+ <!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
+
+ <!ELEMENT HEAD O O (%head.content) +(META|LINK)>
+ <!ATTLIST HEAD
+ %attrs; >
+
+ <!-- <HEAD> Document head -->
+
+ <!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)>
+ <!ATTLIST TITLE
+ %attrs;
+ %SDAFORM; "Ti" >
+
+ <!-- <TITLE> Title of document -->
+
+ <!ELEMENT LINK - O EMPTY>
+ <!ATTLIST LINK
+ %attrs;
+ HREF CDATA #REQUIRED
+ %linkExtraAttributes;
+ %SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>" >
+
+ <!-- <LINK> Link from this document -->
+ <!-- <LINK HREF="..."> Address of link destination -->
+ <!-- <LINK URN="..."> Lasting name of destination -->
+ <!-- <LINK REL=...> Relationship to destination -->
+ <!-- <LINK REV=...> Relationship of destination to this -->
+ <!-- <LINK TITLE="..."> Title of destination (advisory) -->
+ <!-- <LINK CHARSET="..."> Charset of destination (advisory) -->
+
+
+
+ Expires 2 December 1996 [Page 32]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!-- <LINK METHODS="..."> Operations allowed (advisory) -->
+
+ <!ELEMENT ISINDEX - O EMPTY>
+ <!ATTLIST ISINDEX
+ %attrs;
+ %SDAPREF;
+ "<Para>[Document is indexed/searchable.]</Para>">
+
+ <!-- <ISINDEX> Document is a searchable index -->
+
+ <!ELEMENT BASE - O EMPTY>
+ <!ATTLIST BASE
+ HREF CDATA #REQUIRED >
+
+ <!-- <BASE> Base context document -->
+ <!-- <BASE HREF="..."> Address for this document -->
+
+ <!ELEMENT NEXTID - O EMPTY>
+ <!ATTLIST NEXTID
+ N CDATA #REQUIRED >
+
+ <!-- <NEXTID> Next ID to use for link name -->
+ <!-- <NEXTID N=...> Next ID to use for link name -->
+
+ <!ELEMENT META - O EMPTY>
+ <!ATTLIST META
+ HTTP-EQUIV NAME #IMPLIED
+ NAME NAME #IMPLIED
+ CONTENT CDATA #REQUIRED >
+
+ <!-- <META> Generic Meta-information -->
+ <!-- <META HTTP-EQUIV=...> HTTP response header name -->
+ <!-- <META NAME=...> Meta-information name -->
+ <!-- <META CONTENT="..."> Associated information -->
+
+ <!--======= Document Structure =================-->
+
+ <![ %HTML.Deprecated [
+ <!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
+ ]]>
+ <!ENTITY % html.content "HEAD, BODY">
+
+ <!ELEMENT HTML O O (%html.content)>
+ <!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
+
+ <!ATTLIST HTML
+ %attrs;
+ %version.attr;
+
+
+
+ Expires 2 December 1996 [Page 33]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ %SDAFORM; "Book"
+ >
+
+ <!-- <HTML> HTML Document -->
+
+
+7.2. SGML Declaration for HTML
+
+ <!SGML "ISO 8879:1986"
+ --
+ SGML Declaration for HyperText Markup Language version 2.x
+ (HTML 2.x = HTML 2.0 + i18n).
+
+ --
+
+ CHARSET
+ BASESET "ISO Registration Number 177//CHARSET
+ ISO/IEC 10646-1:1993 UCS-4 with
+ implementation level 3//ESC 2/5 2/15 4/6"
+ DESCSET 0 9 UNUSED
+ 9 2 9
+ 11 2 UNUSED
+ 13 1 13
+ 14 18 UNUSED
+ 32 95 32
+ 127 1 UNUSED
+ 128 32 UNUSED
+ 160 2147483486 160
+
+ CAPACITY SGMLREF
+ TOTALCAP 150000
+ GRPCAP 150000
+ ENTCAP 150000
+
+ SCOPE DOCUMENT
+ SYNTAX
+ SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+ 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
+ BASESET "ISO 646:1983//CHARSET
+ International Reference Version
+ (IRV)//ESC 2/5 4/0"
+ DESCSET 0 128 0
+
+ FUNCTION
+ RE 13
+ RS 10
+ SPACE 32
+ TAB SEPCHAR 9
+
+
+
+ Expires 2 December 1996 [Page 34]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ NAMING LCNMSTRT ""
+ UCNMSTRT ""
+ LCNMCHAR ".-"
+ UCNMCHAR ".-"
+ NAMECASE GENERAL YES
+ ENTITY NO
+ DELIM GENERAL SGMLREF
+ SHORTREF SGMLREF
+ NAMES SGMLREF
+ QUANTITY SGMLREF
+ ATTSPLEN 2100
+ LITLEN 1024
+ NAMELEN 72 -- somewhat arbitrary; taken from
+ internet line length conventions --
+ PILEN 1024
+ TAGLVL 100
+ TAGLEN 2100
+ GRPGTCNT 150
+ GRPCNT 64
+
+ FEATURES
+ MINIMIZE
+ DATATAG NO
+ OMITTAG YES
+ RANK NO
+ SHORTTAG YES
+ LINK
+ SIMPLE NO
+ IMPLICIT NO
+ EXPLICIT NO
+ OTHER
+ CONCUR NO
+ SUBDOC NO
+ FORMAL YES
+ APPINFO "SDA" -- conforming SGML Document Access application
+ --
+ >
+
+
+7.3. ISO Latin 1 entity set
+
+ The following public text lists each of the characters specified in
+ the Added Latin 1 entity set, along with its name, syntax for use,
+ and description. This list is derived from ISO Standard
+ 8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire
+ entity set, and adds entities for all missing characters in the right
+ part of ISO-8859-1.
+
+
+
+
+ Expires 2 December 1996 [Page 35]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!-- (C) International Organization for Standardization 1986
+ Permission to copy in any form is granted for use with
+ conforming SGML systems and applications as defined in
+ ISO 8879, provided this notice is included in all copies.
+ -->
+ <!-- Character entity set. Typical invocation:
+ <!ENTITY % ISOlat1 PUBLIC
+ "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
+ %ISOlat1;
+ -->
+ <!ENTITY nbsp CDATA " " -- no-break space -->
+ <!ENTITY iexcl CDATA "¡" -- inverted exclamation mark -->
+ <!ENTITY cent CDATA "¢" -- cent sign -->
+ <!ENTITY pound CDATA "£" -- pound sterling sign -->
+ <!ENTITY curren CDATA "¤" -- general currency sign -->
+ <!ENTITY yen CDATA "¥" -- yen sign -->
+ <!ENTITY brvbar CDATA "¦" -- broken (vertical) bar -->
+ <!ENTITY sect CDATA "§" -- section sign -->
+ <!ENTITY uml CDATA "¨" -- umlaut (dieresis) -->
+ <!ENTITY copy CDATA "©" -- copyright sign -->
+ <!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine -->
+ <!ENTITY laquo CDATA "«" -- angle quotation mark, left -->
+ <!ENTITY not CDATA "¬" -- not sign -->
+ <!ENTITY shy CDATA "­" -- soft hyphen -->
+ <!ENTITY reg CDATA "®" -- registered sign -->
+ <!ENTITY macr CDATA "¯" -- macron -->
+ <!ENTITY deg CDATA "°" -- degree sign -->
+ <!ENTITY plusmn CDATA "±" -- plus-or-minus sign -->
+ <!ENTITY sup2 CDATA "²" -- superscript two -->
+ <!ENTITY sup3 CDATA "³" -- superscript three -->
+ <!ENTITY acute CDATA "´" -- acute accent -->
+ <!ENTITY micro CDATA "µ" -- micro sign -->
+ <!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) -->
+ <!ENTITY middot CDATA "·" -- middle dot -->
+ <!ENTITY cedil CDATA "¸" -- cedilla -->
+ <!ENTITY sup1 CDATA "¹" -- superscript one -->
+ <!ENTITY ordm CDATA "º" -- ordinal indicator, masculine -->
+ <!ENTITY raquo CDATA "»" -- angle quotation mark, right -->
+ <!ENTITY frac14 CDATA "¼" -- fraction one-quarter -->
+ <!ENTITY frac12 CDATA "½" -- fraction one-half -->
+ <!ENTITY frac34 CDATA "¾" -- fraction three-quarters -->
+ <!ENTITY iquest CDATA "¿" -- inverted question mark -->
+ <!ENTITY Agrave CDATA "À" -- capital A, grave accent -->
+ <!ENTITY Aacute CDATA "Á" -- capital A, acute accent -->
+ <!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent -->
+ <!ENTITY Atilde CDATA "Ã" -- capital A, tilde -->
+ <!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut mark -->
+ <!ENTITY Aring CDATA "Å" -- capital A, ring -->
+
+
+
+ Expires 2 December 1996 [Page 36]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) -->
+ <!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla -->
+ <!ENTITY Egrave CDATA "È" -- capital E, grave accent -->
+ <!ENTITY Eacute CDATA "É" -- capital E, acute accent -->
+ <!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent -->
+ <!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut mark -->
+ <!ENTITY Igrave CDATA "Ì" -- capital I, grave accent -->
+ <!ENTITY Iacute CDATA "Í" -- capital I, acute accent -->
+ <!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent -->
+ <!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut mark -->
+ <!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic -->
+ <!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde -->
+ <!ENTITY Ograve CDATA "Ò" -- capital O, grave accent -->
+ <!ENTITY Oacute CDATA "Ó" -- capital O, acute accent -->
+ <!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent -->
+ <!ENTITY Otilde CDATA "Õ" -- capital O, tilde -->
+ <!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut mark -->
+ <!ENTITY times CDATA "×" -- multiply sign -->
+ <!ENTITY Oslash CDATA "Ø" -- capital O, slash -->
+ <!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent -->
+ <!ENTITY Uacute CDATA "Ú" -- capital U, acute accent -->
+ <!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent -->
+ <!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut mark -->
+ <!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent -->
+ <!ENTITY THORN CDATA "Þ" -- capital Thorn, Icelandic -->
+ <!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) -->
+ <!ENTITY agrave CDATA "à" -- small a, grave accent -->
+ <!ENTITY aacute CDATA "á" -- small a, acute accent -->
+ <!ENTITY acirc CDATA "â" -- small a, circumflex accent -->
+ <!ENTITY atilde CDATA "ã" -- small a, tilde -->
+ <!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut mark -->
+ <!ENTITY aring CDATA "å" -- small a, ring -->
+ <!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) -->
+ <!ENTITY ccedil CDATA "ç" -- small c, cedilla -->
+ <!ENTITY egrave CDATA "è" -- small e, grave accent -->
+ <!ENTITY eacute CDATA "é" -- small e, acute accent -->
+ <!ENTITY ecirc CDATA "ê" -- small e, circumflex accent -->
+ <!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut mark -->
+ <!ENTITY igrave CDATA "ì" -- small i, grave accent -->
+ <!ENTITY iacute CDATA "í" -- small i, acute accent -->
+ <!ENTITY icirc CDATA "î" -- small i, circumflex accent -->
+ <!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut mark -->
+ <!ENTITY eth CDATA "ð" -- small eth, Icelandic -->
+ <!ENTITY ntilde CDATA "ñ" -- small n, tilde -->
+ <!ENTITY ograve CDATA "ò" -- small o, grave accent -->
+ <!ENTITY oacute CDATA "ó" -- small o, acute accent -->
+ <!ENTITY ocirc CDATA "ô" -- small o, circumflex accent -->
+ <!ENTITY otilde CDATA "õ" -- small o, tilde -->
+
+
+
+ Expires 2 December 1996 [Page 37]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ <!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut mark -->
+ <!ENTITY divide CDATA "÷" -- divide sign -->
+ <!ENTITY oslash CDATA "ø" -- small o, slash -->
+ <!ENTITY ugrave CDATA "ù" -- small u, grave accent -->
+ <!ENTITY uacute CDATA "ú" -- small u, acute accent -->
+ <!ENTITY ucirc CDATA "û" -- small u, circumflex accent -->
+ <!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut mark -->
+ <!ENTITY yacute CDATA "ý" -- small y, acute accent -->
+ <!ENTITY thorn CDATA "þ" -- small thorn, Icelandic -->
+ <!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark -->
+
+
+Bibliography
+
+ [BRYAN88] M. Bryan, "SGML -- An Author's Guide to the Standard
+ Generalized Markup Language", Addison-Wesley, Reading,
+ 1988.
+
+ [ERCS] Extended Reference Concrete Syntax for SGML.
+ <http://www.sgmlopen.org/sgml/docs/ercs/ercs-
+ home.html>
+
+ [GOLD90] C. F. Goldfarb, "The SGML Handbook", Y. Rubinsky, Ed.,
+ Oxford University Press, 1990.
+
+ [HTTP-1.1] R.T. Fielding, H. Frystyk Nielsen, and T. Berners-Lee,
+ "Hypertext Transfer Protocol -- HTTP/1.1", Work in
+ progress (draft-ietf-http-v11-spec-03.txt), MIT/LCS,
+ May 1996.
+
+ [ISO-639] ISO 639:1988. Codes pour la représentation des noms de
+ langue. Technical content in
+ <http://www.sil.org/sgml/iso639a.html>
+
+ [ISO-3166] ISO 3166:1993. Codes pour la représentation des noms
+ de pays.
+
+ [ISO-8601] ISO 8601:1988. Éléments de données et formats
+ d'échange -- Échange d'information -- Représentation
+ de la date et de l'heure.
+
+ [ISO-8859-1] ISO 8859-1:1987. International Standard -- Informa-
+ tion Processing -- 8-bit Single-Byte Coded Graphic
+ Character Sets -- Part 1: Latin Alphabet No. 1.
+
+ [ISO-8879] ISO 8879:1986. International Standard -- Information
+ Processing -- Text and Office Systems -- Standard Gen-
+ eralized Markup Language (SGML).
+
+
+
+ Expires 2 December 1996 [Page 38]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Infor-
+ mation technology -- Universal Multiple-Octet Coded
+ Character Set (UCS) -- Part 1: Architecture and Basic
+ Multilingual Plane.
+
+ [NICOL] G.T. Nicol, "The Multilingual World Wide Web", Elec-
+ tronic Book Technologies, 1995,
+ <http://www.ebt.com/docs/multling.html>
+
+ [NICOL2] G.T. Nicol, "MIME Header Supplemented File Type", Work
+ in progress, <draft-nicol-mime-header-type-00.txt>,
+ EBT, October 1995.
+
+ [RFC1345] K. Simonsen, "Character Mnemonics & Character Sets",
+ RFC 1345, Rationel Almen Planlaegning, June 1992.
+
+ [RFC1468] J. Murai, M. Crispin and E. van der Poel, "Japanese
+ Character Encoding for Internet Messages", RFC 1468,
+ Keio University, Panda Programming, June 1993.
+
+ [RFC1521] N. Borenstein and N. Freed, "MIME (Multipurpose Inter-
+ net Mail Extensions) Part One: Mechanisms for Specify-
+ ing and Describing the Format of Internet Message Bod-
+ ies", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [RFC1641] D. Goldsmith, M.Davis, "Using Unicode with MIME", RFC
+ 1641, Taligent inc., July 1994.
+
+ [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor-
+ mation Format of Unicode", RFC 1642, Taligent inc.,
+ July 1994.
+
+ [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
+ University of Minnesota, October 1994.
+
+ [RFC1766] H. Alverstrand, "Tags for the Identification of Lan-
+ guages", RFC 1766, UNINETT, March 1995.
+
+ [RFC1866] T. Berners-Lee and D. Connolly, "Hypertext Markup Lan-
+ guage - 2.0", RFC 1866, MIT/W3C, November 1995.
+
+ [RFC1867] E. Nebel and L. Masinter, "Form-based File Upload in
+ HTML", RFC 1867, Xerox Corporation, November 1995.
+
+ [RFC1942] D. Raggett, "HTML Tables", RFC 1942, W3C, May 1996.
+
+
+
+
+
+ Expires 2 December 1996 [Page 39]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ [RFC1945] T. Berners-Lee, R.T. Fielding, and H. Frystyk Nielsen,
+ "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
+ MIT/LCS, UC Irvine, May 1996.
+
+ [SQ91] SoftQuad, "The SGML Primer", 3rd ed., SoftQuad Inc.,
+ 1991.
+
+ [TAKADA] Toshihiro Takada, "Multilingual Information Exchange
+ through the World-Wide Web", Computer Networks and
+ ISDN Systems, Vol. 27, No. 2, Nov. 1994 , p. 235-241.
+
+ [TEI] TEI Guidelines for Electronic Text Encoding and Inter-
+ change. <http://etext.virgina.edu/TEI.html>
+
+ [UNICODE] The Unicode Consortium, "The Unicode Standard --
+ Worldwide Character Encoding -- Version 1.0", Addison-
+ Wesley, Volume 1, 1991, Volume 2, 1992, and Technical
+ Report #4, 1993. The BIDI algorithm is in appendix A
+ of volume 1, with corrections in appendix D of volume
+ 2.
+
+ [UTF-8] ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transfor-
+ mation Format 8 (UTF-8).
+
+ [VANH90] E. van Hervijnen, "Practical SGML", Kluwer Academicq
+ Publishers Group, Norwell and Dordrecht, 1990.
+
+Authors' Addresses
+
+ François Yergeau
+ Alis Technologies
+ 100, boul. Alexis-Nihon, bureau 600
+ Montréal QC H4M 2P2
+ Canada
+
+ Tel: +1 (514) 747-2547
+ Fax: +1 (514) 747-2561
+ EMail: fyergeau@alis.com
+
+
+ Gavin Thomas Nicol
+ Electronic Book Technologies, Japan
+ 1-29-9 Tsurumaki,
+ Setagaya-ku,
+ Tokyo
+ Japan
+
+ Tel: +81-3-3230-8161
+
+
+
+ Expires 2 December 1996 [Page 40]
+\f
+Internet Draft HTML internationalization 27 May 1996
+
+
+ Fax: +81-3-3230-8163
+ EMail: gtn@ebt.com, gtn@twics.co.jp
+
+
+ Glenn Adams
+ Spyglass
+ 118 Magazine Street
+ Cambridge, MA 02139
+ U.S.A.
+
+ Tel: +1 (617) 864-5524
+ Fax: +1 (617) 864-4965
+ EMail: glenn@spyglass.com
+
+
+ Martin J. Duerst
+ Multimedia-Laboratory
+ Department of Computer Science
+ University of Zurich
+ Winterthurerstrasse 190
+ CH-8057 Zurich
+ Switzerland
+
+ Tel: +41 1 257 43 16
+ Fax: +41 1 363 00 35
+ E-mail: mduerst@ifi.unizh.ch
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Expires 2 December 1996 [Page 41]
+\f
--- /dev/null
+
+
+HTTP Working Group R. Fielding, UC Irvine
+INTERNET-DRAFT H. Frystyk, MIT/LCS
+<draft-ietf-http-v11-spec-03.html> T. Berners-Lee, MIT/LCS
+ J. Gettys, DEC
+ J. C. Mogul, DEC
+Expires October 2, 1996 May 2, 1996
+
+ Hypertext Transfer Protocol -- HTTP/1.1
+
+
+1 Status of this Memo
+This document is an Internet-Draft. Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas, and
+its working groups. Note that other groups may also distribute working
+documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or made obsolete by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as "work in progress".
+
+To learn the current status of any Internet-Draft, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ftp.isi.edu (US West Coast).
+
+Distribution of this document is unlimited. Please send comments to the
+HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the
+working group are archived at
+<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about
+HTTP and the applications which use HTTP should take place on the <www-
+talk@w3.org> mailing list.
+
+ NOTE: This specification is for discussion purposes only. It is not
+ claimed to represent the consensus of the HTTP working group, and
+ contains a number of proposals that either have not been discussed
+ or are controversial. The working group is discussing significant
+ changes in many areas, including - support for caching, persistent
+ connections, range retrieval, content negotiation, MIME
+ compatibility, authentication, timing of the PUT operation.
+
+
+2 Abstract
+The Hypertext Transfer Protocol (HTTP) is an application-level protocol
+for distributed, collaborative, hypermedia information systems. It is a
+generic, stateless, object-oriented protocol which can be used for many
+tasks, such as name servers and distributed object management systems,
+through extension of its request methods (commands). A feature of HTTP
+is the typing and negotiation of data representation, allowing systems
+to be built independently of the data being transferred.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 1]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+HTTP has been in use by the World-Wide Web global information initiative
+since 1990. This specification defines the protocol referred to as
+"HTTP/1.1".
+
+3 Note to Readers of This Document
+
+
+We believe this draft to be very close to consensus of the working group
+in terms of functionality for HTTP/1.1, and the text substantially
+correct. One final technical change NOT reflected in this draft is to
+make persistent connections the default behavior for HTTP/1.1; editorial
+changes to reflect this in the next, and we hope final draft, are being
+circulated in the working group mailing list.
+
+This draft has undergone extensive reorganization to improve
+presentation. Let us know if there are remaining problems.
+
+The terminology used in this draft has changed to reduce confusion.
+While we are converging on a shared set of terminology and definitions,
+it is possible there will be a final set of terminology adopted in the
+next draft. Despite any terminology changes that may occur to improve
+the presentation of the specification, we do not expect to change the
+name of any header field or parameter name.
+
+There are a very few remaining issues indicated by Editor's Note: in
+bold font.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 2]
+
+
+
+
+
+
+
+
+4 Table of Contents
+
+
+HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1
+
+1 Status of this Memo
+
+2 Abstract
+
+3 Note to Readers of This Document
+
+4 Table of Contents
+
+5 Introduction
+ 5.1 Purpose
+ 5.2 Requirements
+ 5.3 Terminology
+ 5.4 Overall Operation
+ 5.5 HTTP and MIME
+
+6 Notational Conventions and Generic Grammar
+ 6.1 Augmented BNF
+ 6.2 Basic Rules
+
+7 Protocol Parameters
+ 7.1 HTTP Version
+ 7.2 Uniform Resource Identifiers
+ 7.3 Date/Time Formats
+ 7.4 Character Sets
+ 7.5 Content Codings
+ 7.6 Transfer Codings
+ 7.7 Media Types
+ 7.8 Product Tokens
+ 7.9 Quality Values
+ 7.10 Language Tags
+ 7.11 Entity Tags
+ 7.12 Variant IDs
+ 7.13 Variant Sets
+ 7.14 Range Protocol Parameters
+
+8 HTTP Message
+ 8.1 Message Types
+ 8.2 Message Headers
+ 8.3 General Header Fields
+
+9 Request
+ 9.1 Request-Line
+ 9.2 The Resource Identified by a Request
+ 9.3 Request Header Fields
+
+10 Response
+ 10.1 Status-Line
+ 10.2 Response Header Fields
+
+Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+11 Entity
+ 11.1 Entity Header Fields
+ 11.2 Entity Body
+
+12 Status Code Definitions
+ 12.1 Informational 1xx
+ 12.2 Successful 2xx
+ 12.3 Redirection 3xx
+ 12.4 Client Error 4xx
+ 12.5 Server Error 5xx
+
+13 Method Definitions
+ 13.1 OPTIONS
+ 13.2 GET
+ 13.3 HEAD
+ 13.4 POST
+ 13.5 PUT
+ 13.6 DELETE
+ 13.7 TRACE
+
+14 Access Authentication
+ 14.1 Basic Authentication Scheme
+ 14.2 Digest Authentication Scheme
+
+15 Content Negotiation
+ 15.1 Negotiation Facilities Defined in this Specification
+
+16 Caching in HTTP
+ 16.1 Semantic Transparency
+ 16.2 Expiration Model
+ 16.3 Validation Model
+ 16.4 Constructing Responses From Caches
+ 16.5 Caching and Generic Resources
+ 16.6 Shared and Non-Shared Caches
+ 16.7 Selecting a Cached Response
+ 16.8 Errors or Incomplete Response Cache Behavior
+ 16.9 Side Effects of GET and HEAD
+ 16.10 Invalidation After Updates or Deletions
+ 16.11 Write-Through Mandatory
+ 16.12 Generic Resources and HTTP/1.0 Proxy Caches
+ 16.13 Cache Replacement
+ 16.14 Caching of Negative Responses
+ 16.15 History Lists
+
+17 Persistent Connections
+ 17.1 Purpose
+ 17.2 Overall Operation
+ 17.3 Proxy Servers
+ 17.4 Interaction with Security Protocols
+ 17.5 Practical Considerations
+
+18 Header Field Definitions
+ 18.1 Accept
+ 18.2 Accept-Charset
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ 18.3 Accept-Encoding
+ 18.4 Accept-Language
+ 18.5 Accept-Ranges
+ 18.6 Age
+ 18.7 Allow
+ 18.8 Alternates
+ 18.9 Authorization
+ 18.10 Cache-Control
+ 18.11 Connection
+ 18.12 Content-Base
+ 18.13 Content-Encoding
+ 18.14 Content-Language
+ 18.15 Content-Length
+ 18.16 Content-Location
+ 18.17 Content-MD5
+ 18.18 Content-Range
+ 18.19 Content-Type
+ 18.20 Date
+ 18.21 ETag
+ 18.22 Expires
+ 18.23 From
+ 18.24 Host
+ 18.25 If-Modified-Since
+ 18.26 If-Match
+ 18.27 If-NoneMatch
+ 18.28 If-Range
+ 18.29 If-Unmodified-Since
+ 18.30 Last-Modified
+ 18.31 Location
+ 18.32 Max-Forwards
+ 18.33 Persist
+ 18.34 Pragma
+ 18.35 Proxy-Authenticate
+ 18.36 Proxy-Authorization
+ 18.37 Public
+ 18.38 Range
+ 18.39 Referer
+ 18.40 Retry-After
+ 18.41 Server
+ 18.42 Title
+ 18.43 Transfer Encoding
+ 18.44 Upgrade
+ 18.45 User-Agent
+ 18.46 Vary
+ 18.47 Via
+ 18.48 Warning
+ 18.49 WWW-Authenticate
+
+19 Security Considerations
+ 19.1 Authentication of Clients
+ 19.2 Safe Methods
+ 19.3 Abuse of Server Log Information
+ 19.4 Transfer of Sensitive Information
+ 19.5 Attacks Based On File and Path Names
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ 19.6 Personal Information
+ 19.7 Privacy Issues Connected to Accept headers
+ 19.8 DNS Spoofing
+ 19.9 Location Headers and Spoofing
+
+20 Acknowledgments
+
+21 References
+
+22 Authors' Addresses
+
+23 Appendices
+ 23.1 Internet Media Type message/http
+ 23.2 Tolerant Applications
+ 23.3 Differences Between HTTP Bodies and RFC 1521 Internet Message
+ Bodies
+ 23.4 Changes from HTTP/1.0
+ 23.5 Additional Features
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 6]
+
+
+
+
+
+
+
+5 Introduction
+5.1 Purpose
+The Hypertext Transfer Protocol (HTTP) is an application-level protocol
+for distributed, collaborative, hypermedia information systems. HTTP has
+been in use by the World-Wide Web global information initiative since
+1990. The first version of HTTP, referred to as HTTP/0.9, was a simple
+protocol for raw data transfer across the Internet. HTTP/1.0, as defined
+by RFC xxxx , improved the protocol by allowing messages to be in the
+format of MIME-like entities, containing metainformation about the data
+transferred and modifiers on the request/response semantics. However,
+HTTP/1.0 does not sufficiently take into consideration the effect of
+hierarchical proxies , caching, the need for persistent connections and
+virtual hosts.. In addition, the proliferation of incompletely-
+implemented applications calling themselves "HTTP/1.0" has necessitated
+a protocol version change in order for two communicating applications to
+determine each other's true capabilities.
+
+This specification defines the protocol referred to as "HTTP/1.1". This
+protocol is backwards-compatible with HTTP/1.0, but includes more
+stringent requirements in order to ensure reliable implementation of its
+features.
+
+Practical information systems require more functionality than simple
+retrieval, including search, front-end update, and annotation. HTTP
+allows an open-ended set of methods that indicate the purpose of a
+request. It builds on the discipline of reference provided by the
+Uniform Resource Identifier (URI) , as a location (URL) or name (URN)
+,
+for indicating the resource to which a method is to be applied. Messages
+are passed in a format similar to that used by Internet Mail and the
+Multipurpose Internet Mail Extensions (MIME) .
+
+HTTP is also used as a generic protocol for communication between user
+agents and proxies/gateways to other Internet protocols, such as SMTP ,
+NNTP , FTP , Gopher , and WAIS , allowing basic hypermedia access to
+resources available from diverse applications and simplifying the
+implementation of user agents.
+
+
+5.2 Requirements
+This specification uses the same words as RFC 1123 for defining the
+significance of each particular requirement. These words are:
+
+
+MUST
+ This word or the adjective "required" means that the item is an
+ absolute requirement of the specification.
+
+SHOULD
+ This word or the adjective "recommended" means that there may
+exist
+ valid reasons in particular circumstances to ignore this item, but
+ the full implications should be understood and the case carefully
+ weighed before choosing a different course.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 7]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+MAY
+ This word or the adjective "optional" means that this item is
+truly
+ optional. One vendor may choose to include the item because a
+ particular marketplace requires it or because it enhances the
+ product, for example; another vendor may omit the same item.
+An implementation is not compliant if it fails to satisfy one or more of
+the MUST requirements for the protocols it implements. An implementation
+that satisfies all the MUST and all the SHOULD requirements for its
+protocols is said to be "unconditionally compliant"; one that satisfies
+all the MUST requirements but not all the SHOULD requirements for its
+protocols is said to be "conditionally compliant".
+
+
+5.3 Terminology
+This specification uses a number of terms to refer to the roles played
+by participants in, and objects of, the HTTP communication.
+
+
+connection
+ A transport layer virtual circuit established between two programs
+ for the purpose of communication.
+
+message
+ The basic unit of HTTP communication, consisting of a structured
+ sequence of octets matching the syntax defined in section 8 and
+ transmitted via the connection.
+
+request
+ An HTTP request message as defined in section 9.
+
+response
+ An HTTP response message as defined in section 10.
+
+resource
+ A network data object or service that can be identified by a URI
+ (section 7.2). At any point in time, a resource may be either a
+ plain resource, which corresponds to only one possible
+ representation, or a generic resource.
+
+generic resource
+ A resource that is a set of closely related representations of the
+ same document, form, applet, etc. A generic resource is always
+ identified by a URI. The individual representations may each be
+ identified by a unique URI, or by the combination of the generic
+ resource's URI and a variant-ID, or by the combination of the generic
+ resource's URI and some "content-negotiation" mechanism. In this
+ case, other URIs may exist which identify a resource more
+ specifically.
+
+plain resource
+ A resource that is not a generic resource. A plain resource is
+ always identified by a URI.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 8]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+entity
+ The set of information transferred as the payload of a request or
+ response An entity consists of metainformation in the form of
+ Entity-Header fields and content in the form of an Entity-Body, as
+ described in section 11.
+
+resource entity
+ A specific representation, rendition, encoding, or presentation of a
+ network data object or service, either a plain resource or a specific
+ member of a generic resource. A resource entity might be identified
+ by a URI, or by the combination of a URI and a variant-ID, or by the
+ combination of a URI and some other mechanism. An plain resource MUST
+ be bound to a single resource entity at any instant in time.
+
+variant
+ A resource entity that is a member of at least one generic resource.
+ Sometimes called a resource variant. Note that the set of variants
+ of a generic resource may change over time as well.
+
+content negotiation
+ The mechanism for selecting the appropriate variant of a generic
+ resource when servicing a request, as described in section 15.
+
+entity tag
+ An opaque string associated with an entity and used to distinguish it
+ from other entities of the requested resource . A "strong entity
+ tag" is one that may be shared by two entities of a resource only if
+ they are equivalent by octet equality. A "weak entity tag" is one
+ that may be shared by two entities of a resource if they are
+ equivalent and could be substituted for each other with no
+ significant change in semantics. A given entity tag value may be
+ used for entities obtained by requests on different URIs without
+ implying anything about the equivalence of these entities.
+
+client
+ An application program that establishes connections for the purpose
+ of sending requests.
+
+user agent
+ The client which initiates a request. These are often browsers,
+ editors, spiders (web-traversing robots), or other end user tools.
+
+server
+ An application program that accepts connections in order to service
+ requests by sending back responses. Any given program MAY be capable
+ of being both a client and a server; our use of these terms refers
+ only to the role being performed by the program for a particular
+ connection, rather than to the program's capabilities in general.
+ Likewise, any server MAY act as an origin server, proxy, gateway, or
+ tunnel, switching behavior based on the nature of each request.
+
+origin server
+ The server on which a given resource resides or is to be created.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 9]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+proxy
+ An intermediary program which acts as both a server and a client for
+ the purpose of making requests on behalf of other clients. Requests
+ are serviced internally or by passing them on, with possible
+ translation, to other servers. A proxy MUST interpret and, if
+ necessary, rewrite a request message before forwarding it. Proxies
+ are often used as client-side portals through network firewalls and
+ as helper applications for handling requests via protocols not
+ implemented by the user agent.
+
+gateway
+ A server which acts as an intermediary for some other server. Unlike
+ a proxy, a gateway receives requests as if it were the origin server
+ for the requested resource; the requesting client may not be aware
+ that it is communicating with a gateway. Gateways are often used as
+ server-side portals through network firewalls and as protocol
+ translators for access to resources stored on non-HTTP systems.
+
+tunnel
+ An intermediary program which is acting as a blind relay between two
+ connections. Once active, a tunnel is not considered a party to the
+ HTTP communication, though the tunnel may have been initiated by an
+ HTTP request. The tunnel ceases to exist when both ends of the
+ relayed connections are closed. Tunnels are used when a portal is
+ necessary and the intermediary cannot, or should not, interpret the
+ relayed communication.
+
+cache
+ A program's local store of response messages and the subsystem that
+ controls its message storage, retrieval, and deletion. A cache stores
+ cachable responses in order to reduce the response time and network
+ bandwidth consumption on future, equivalent requests. Any client or
+ server MAY include a cache, though a cache cannot be used by a server
+ that acts acting as a tunnel.
+
+cachable
+ A response is cachable if a cache is allowed to store a copy of the
+ response message for use in answering subsequent requests. The rules
+ for determining the cachability of HTTP responses are defined in
+ Section 16. Even if a resource is cachable, there may be additional
+ constraints on when and if a cache can use the cached copy for a
+ particular request.
+
+firsthand
+ A response is firsthand if it comes directly and without unnecessary
+ delay from the origin server, perhaps via one or more proxies. A
+ response is also firsthand if its validity has just been checked
+ directly with the origin server.
+
+explicit expiration time
+ The time at which the origin server intends that an entity should no
+ longer be returned by a cache without further validation.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+heuristic expiration time
+ An expiration time assigned by a cache when no explicit expiration
+ time is available.
+
+age
+ The age of a response is the time since it was generated by, or
+ successfully validated with, the origin server.
+
+freshness lifetime
+ The length of time between the generation of a response and its
+ expiration time.
+
+fresh
+ A response is fresh if its age has not yet exceeded its freshness
+ lifetime.
+
+stale
+ A response is stale if its age has passed its freshness lifetime. A
+ cache may use a fresh response without validating it, but "normally"
+ may not use a stale response without first validating it.
+ ("Normally" means "unless configured to provide better performance at
+ the expense of transparency.")
+ Therefore, what expires is the cache's authority to use a cached
+ response, without validation, in its reply to a subsequent request.
+
+semantically transparent
+ Ideally, an HTTP/1.1 cache would be "semantically transparent." That
+ is, use of the cache would not affect either the clients or the
+ servers in any way except to improve performance. When a client makes
+ a request via a semantically transparent cache, it receives exactly
+ the same entity headers and entity body it would have received if it
+ had made the same request to the origin server, at the same time.
+
+validator
+ An entity tag, or a Last-Modified time, which is used to find out
+ whether a cache entry is a semantically transparent copy of a
+ resource entity. A cache entry is semantically transparent if its
+ validator exactly matches the validator that the server would provide
+ for current instance of that resource entity.
+
+5.4 Overall Operation
+The HTTP protocol is a request/response protocol. A client sends a
+request to the server in the form of a request method, URI, and protocol
+version, followed by a MIME-like message containing request modifiers,
+client information, and possible body content over a connection with a
+server. The server responds with a status line, including the message's
+protocol version and a success or error code, followed by a MIME-like
+message containing server information, entity metainformation, and
+possible entity body content.
+
+Most HTTP communication is initiated by a user agent and consists of a
+request to be applied to a resource on some origin server. In the
+simplest case, this may be accomplished via a single connection (v)
+between the user agent (UA) and the origin server (O).
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ request chain ------------------------>
+ UA -------------------v------------------- O
+ <----------------------- response chain
+
+A more complicated situation occurs when one or more intermediaries are
+present in the request/response chain. There are three common forms of
+intermediary: proxy, gateway, and tunnel. A proxy is a forwarding
+agent,
+receiving requests for a URI in its absolute form, rewriting all or part
+of the message, and forwarding the reformatted request toward the server
+identified by the URI. A gateway is a receiving agent, acting as a layer
+above some other server(s) and, if necessary, translating the requests
+to the underlying server's protocol. A tunnel acts as a relay point
+between two connections without changing the messages; tunnels are used
+when the communication needs to pass through an intermediary (such as a
+firewall) even when the intermediary cannot understand the contents of
+the messages.
+
+ request chain -------------------------------------->
+ UA -----v----- A -----v----- B -----v----- C -----v----- O
+ <------------------------------------- response chain
+
+The figure above shows three intermediaries (A, B, and C) between the
+user agent and origin server. A request or response message that travels
+the whole chain MUST pass through four separate connections. This
+distinction is important because some HTTP communication options may
+apply only to the connection with the nearest, non-tunnel neighbor, only
+to the end-points of the chain, or to all connections along the chain.
+Although the diagram is linear, each participant may be engaged in
+multiple, simultaneous communications. For example, B may be receiving
+requests from many clients other than A, and/or forwarding requests to
+servers other than C, at the same time that it is handling A's request.
+
+Any party to the communication which is not acting as a tunnel may
+employ an internal cache for handling requests. The effect of a cache is
+that the request/response chain is shortened if one of the participants
+along the chain has a cached response applicable to that request. The
+following illustrates the resulting chain if B has a cached copy of an
+earlier response from O (via C) for a request which has not been cached
+by UA or A.
+
+ request chain ---------->
+ UA -----v----- A -----v----- B - - - - - - C - - - - - - O
+ <--------- response chain
+
+Not all responses are cachable, and some requests may contain modifiers
+which place special requirements on cache behavior. HTTP requirements
+for cache behavior and cachable responses are defined in section 16.
+
+HTTP communication usually takes place over TCP/IP connections. The
+default port is TCP 80 , but other ports can be used. This does not
+preclude HTTP from being implemented on top of any other protocol on the
+Internet, or on other networks. HTTP only presumes a reliable
+transport;
+any protocol that provides such guarantees can be used; the mapping of
+the HTTP/1.1 request and response structures onto the transport data
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+units of the protocol in question is outside the scope of this
+specification.
+
+However, HTTP/1.1 implementations SHOULD implement persistent
+connections (See section 17). Both clients and servers MUST be capable
+of handling cases where either party closes the connection prematurely,
+due to user action, automated time-out, or program failure. In any
+case,
+the closing of the connection by either or both parties always
+terminates the current request, regardless of its status.
+
+
+5.5 HTTP and MIME
+HTTP/1.1 uses many of the constructs defined for MIME, as defined in RFC
+1521 . Appendix 23.3 describes the ways in which the context of HTTP
+allows for different use of Internet Media Types than is typically found
+in Internet mail, and gives the rationale for those differences.
+
+
+6 Notational Conventions and Generic Grammar
+
+6.1 Augmented BNF
+All of the mechanisms specified in this document are described in both
+prose and an augmented Backus-Naur Form (BNF) similar to that used by
+RFC 822 . Implementers will need to be familiar with the notation in
+order to understand this specification. The augmented BNF includes the
+following constructs:
+
+
+name = definition
+ The name of a rule is simply the name itself (without any enclosing
+ "<" and ">") and is separated from its definition by the equal
+ character "=". Whitespace is only significant in that indentation
+ of continuation lines is used to indicate a rule definition that
+ spans more than one line. Certain basic rules are in uppercase,
+ such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are
+ used within definitions whenever their presence will facilitate
+ discerning the use of rule names.
+
+"literal"
+ Quotation marks surround literal text. Unless stated otherwise, the
+ text is case-insensitive.
+
+rule1 | rule2
+ Elements separated by a bar ("I") are alternatives, e.g., "yes |
+ no" will accept yes or no.
+
+(rule1 rule2)
+ Elements enclosed in parentheses are treated as a single element.
+ Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
+ foo elem" and "elem bar elem".
+
+*rule
+ The character "*" preceding an element indicates repetition. The
+ full form is "<n>*<m>element" indicating at least <n> and at most
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ <m> occurrences of element. Default values are 0 and infinity so
+ that "*(element)" allows any number, including zero; "1*element"
+ requires at least one; and "1*2element" allows one or two.
+
+[rule]
+ Square brackets enclose optional elements; "[foo bar]" is
+ equivalent to "*1(foo bar)".
+
+N rule
+ Specific repetition: "<n>(element)" is equivalent to
+ "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
+ Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
+ alphabetic characters.
+
+#rule
+ A construct "#" is defined, similar to "*", for defining lists of
+ elements. The full form is "<n>#<m>element " indicating at least
+ <n> and at most <m> elements, each separated by one or more commas
+ (",") and optional linear whitespace (LWS). This makes the usual
+ form of lists very easy; a rule such as "( *LWS element *( *LWS
+","
+ *LWS element )) " can be shown as "1#element". Wherever this
+ construct is used, null elements are allowed, but do not contribute
+ to the count of elements present. That is, "(element), , (element)
+ " is permitted, but counts as only two elements. Therefore, where
+ at least one element is required, at least one non-null element
+ MUST be present. Default values are 0 and infinity so that
+ "#(element) " allows any number, including zero; "1#element"
+ requires at least one; and "1#2element" allows one or two.
+
+; comment
+ A semi-colon, set off some distance to the right of rule text,
+ starts a comment that continues to the end of line. This is a
+ simple way of including useful notes in parallel with the
+ specifications.
+
+implied *LWS
+ The grammar described by this specification is word-based. Except
+ where noted otherwise, linear whitespace (LWS) can be included
+ between any two adjacent words (token or quoted-string), and
+ between adjacent tokens and delimiters (tspecials), without
+ changing the interpretation of a field. At least one delimiter
+ (tspecials) MUST exist between any two tokens, since they would
+ otherwise be interpreted as a single token. However, applications
+ SHOULD attempt to follow "common form" when generating HTTP
+ constructs, since there exist some implementations that fail to
+ accept anything beyond the common forms.
+
+6.2 Basic Rules
+The following rules are used throughout this specification to describe
+basic parsing constructs. The US-ASCII coded character set is defined by.
+
+ OCTET = <any 8-bit sequence of data>
+ CHAR = <any US-ASCII character (octets 0 - 127)>
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ UPALPHA = <any US-ASCII uppercase letter "A".."Z">
+ LOALPHA = <any US-ASCII lowercase letter "a".."z">
+ ALPHA = UPALPHA | LOALPHA
+ DIGIT = <any US-ASCII digit "0".."9">
+ CTL = <any US-ASCII control character
+ (octets 0 - 31) and DEL (127)>
+ CR = <US-ASCII CR, carriage return (13)>
+ LF = <US-ASCII LF, linefeed (10)>
+ SP = <US-ASCII SP, space (32)>
+ HT = <US-ASCII HT, horizontal-tab (9)>
+ <"> = <US-ASCII double-quote mark (34)>
+
+HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker for
+all protocol elements except the Entity-Body (see appendix 23.2 for
+tolerant applications). The end-of-line marker within an Entity-Body is
+defined by its associated media type, as described in section 7.7.
+
+ CRLF = CR LF
+
+HTTP/1.1 headers can be folded onto multiple lines if the continuation
+line begins with a space or horizontal tab. All linear whitespace,
+including folding, has the same semantics as SP.
+
+ LWS = [CRLF] 1*( SP | HT )
+
+The TEXT rule is only used for descriptive field contents and values
+that are not intended to be interpreted by the message parser. Words of
+*TEXT MAY contain octets from character sets other than US-ASCII only
+when encoded according to the rules of RFC 1522 .
+
+ TEXT = <any OCTET except CTLs,
+ but including LWS>
+
+Recipients of header field TEXT containing octets outside the US-ASCII
+character set range MAY assume that they represent ISO-8859-1 characters
+if there is no other encoding indicated by an RFC 1522 mechanism.
+
+Hexadecimal numeric characters are used in several protocol elements.
+
+ HEX = "A" | "B" | "C" | "D" | "E" | "F"
+ | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+
+Many HTTP/1.1 header field values consist of words separated by LWS or
+special characters. These special characters MUST be in a quoted string
+to be used within a parameter value.
+
+ word = token | quoted-string
+
+ token = 1*<any CHAR except CTLs or tspecials>
+
+ tspecials = "(" | ")" | "<" | ">" | "@"
+ | "," | ";" | ":" | "\" | <">
+ | "/" | "[" | "]" | "?" | "="
+ | "{" | "}" | SP | HT
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 15]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Comments can be included in some HTTP header fields by surrounding the
+comment text with parentheses. Comments are only allowed in fields
+containing "comment" as part of their field value definition. In all
+other fields, parentheses are considered part of the field value.
+
+ comment = "(" *( ctext | comment ) ")"
+ ctext = <any TEXT excluding "(" and ")">
+
+A string of text is parsed as a single word if it is quoted using
+double-quote marks.
+
+ quoted-string = ( <"> *(qdtext) <"> )
+
+
+ qdtext = <any CHAR except <"> and CTLs,
+ but including LWS>
+
+The backslash character ("\") may be used as a single-character quoting
+mechanism only within quoted-string and comment constructs.
+
+ quoted-pair = "\" CHAR
+
+
+7 Protocol Parameters
+
+7.1 HTTP Version
+HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of
+the protocol. The protocol versioning policy is intended to allow the
+sender to indicate the format of a message and its capacity for
+understanding further HTTP communication, rather than the features
+obtained via that communication. No change is made to the version number
+for the addition of message components which do not affect communication
+behavior or which only add to extensible field values. The <minor>
+number is incremented when the changes made to the protocol add features
+which do not change the general message parsing algorithm, but which may
+add to the message semantics and imply additional capabilities of the
+sender. The <major> number is incremented when the format of a message
+within the protocol is changed.
+
+The version of an HTTP message is indicated by an HTTP-Version field in
+the first line of the message. If the protocol version is not specified,
+the recipient MUST assume that the message is in the simple HTTP/0.9
+format .
+
+ HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
+
+Note that the major and minor numbers SHOULD be treated as separate
+integers and that each MAY be incremented higher than a single digit.
+Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower
+than HTTP/12.3. Leading zeros SHOULD be ignored by recipients and never
+generated by senders.
+
+Applications sending Full-Request or Full-Response messages, as defined
+by this specification, MUST include an HTTP-Version of "HTTP/1.1". Use
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+of this version number indicates that the sending application is at
+least conditionally compliant with this specification.
+
+Proxy and gateway applications MUST be careful in forwarding requests
+that are received in a format different from that of the application's
+native HTTP version. Since the protocol version indicates the protocol
+capability of the sender, a proxy/gateway MUST never send a message with
+a version indicator which is greater than its native version; if a
+higher version request is received, the proxy/gateway MUST either
+downgrade the request version, respond with an error, or switch to
+tunnel behavior. Requests with a version lower than that of the
+application's native format MAY be upgraded before being forwarded; the
+proxy/gateway's response to that request MUST follow the server
+requirements listed above.
+
+ Note: Converting between versions of HTTP may involve addition or
+ deletion of headers required or forbidden by the version involved.
+ It is likely more involved than just changing the version
+ indicator.
+
+
+7.2 Uniform Resource Identifiers
+URIs have been known by many names: WWW addresses, Universal Document
+Identifiers, Universal Resource Identifiers , and finally the
+combination of Uniform Resource Locators (URL) and Names (URN) . As far
+as HTTP is concerned, Uniform Resource Identifiers are simply formatted
+strings which identify--via name, location, or any other characteristic--
+a network resource.
+
+
+7.2.1 General Syntax
+URIs in HTTP can be represented in absolute form or relative to some
+known base URI , depending upon the context of their use. The two forms
+are differentiated by the fact that absolute URIs always begin with a
+scheme name followed by a colon.
+
+ URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
+
+ absoluteURI = scheme ":" *( uchar | reserved )
+
+ relativeURI = net_path | abs_path | rel_path
+
+ net_path = "//" net_loc [ abs_path ] abs_path
+ = "/" rel_path
+ rel_path = [ path ] [ ";" params ] [ "?" query ]
+
+ path = fsegment *( "/" segment )
+ fsegment = 1*pchar
+ segment = *pchar
+
+ params = param *( ";" param )
+ param = *( pchar | "/" )
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
+ net_loc = *( pchar | ";" | "?" )
+ query = *( uchar | reserved )
+ fragment = *( uchar | reserved )
+
+ pchar = uchar | ":" | "@" | "&" | "=" | "+"
+ uchar = unreserved | escape
+ unreserved = ALPHA | DIGIT | safe | extra | national
+
+ escape = "%" HEX HEX
+ reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
+ extra = "!" | "*" | "'" | "(" | ")" | ","
+ safe = "$" | "-" | "_" | "."
+ unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
+ national = <any OCTET excluding ALPHA, DIGIT,
+ reserved, extra, safe, and unsafe>
+
+For definitive information on URL syntax and semantics, see RFC 1738
+and RFC 1808 . The BNF above includes national characters not allowed in
+valid URLs as specified by RFC 1738, since HTTP servers are not
+restricted in the set of unreserved characters allowed to represent the
+rel_path part of addresses, and HTTP proxies may receive requests for
+URIs not defined by RFC 1738.
+
+The HTTP protocol does not place any a priori limit on the length of a
+URI. Servers MUST be able to handle the URI of any resource they
+serve, and SHOULD be able to handle URIs of unbounded length if they
+provide GET-based forms that could generate such URIs. A server SHOULD
+return a status code of
+
+ 414 Request-URI Too Large
+
+ if a URI is longer than the server can handle. See section 12.4.1.15.
+
+ Note: Servers should be cautious about depending on URI lengths
+ above 255 bytes, because some older client or proxy implementations
+ may not properly support these.
+
+ All client and proxy implementations MUST be able to handle a URI of
+any finite length.
+
+
+7.2.2 http URL
+The "http" scheme is used to locate network resources via the HTTP
+protocol. This section defines the scheme-specific syntax and semantics
+for http URLs.
+
+ http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
+
+ host = <A legal Internet host domain name
+ or IP address (in dotted-decimal form),
+ as defined by Section 2.1 of RFC 1123>
+
+ port = *DIGIT
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+If the port is empty or not given, port 80 is assumed. The semantics are
+that the identified resource is located at the server listening for TCP
+connections on that port of that host, and the Request-URI for the
+resource is abs_path. The use of IP addresses in URL's SHOULD be
+avoided whenever possible. See RFC 1900. If the abs_path is not
+present in the URL, it MUST be given as "/" when used as a Request-URI
+for a resource (section 9.1.2).
+
+ Note: Although the HTTP protocol is independent of the transport
+ layer protocol, the http URL only identifies resources by their TCP
+ location, and thus non-TCP resources MUST be identified by some
+ other URI scheme.
+
+The canonical form for "http" URLs is obtained by converting any UPALPHA
+characters in host to their LOALPHA equivalent (hostnames are case-
+insensitive), eliding the [ ":" port ] if the port is 80, and replacing
+an empty abs_path with "/".
+
+
+7.2.3 URI Canonicalization
+A cache, when comparing two URIs to decide if they match or not, a cache
+MUST use a case-sensitive octet-by-octet comparison of the entire URIs,
+with these exceptions:
+
+Following the rules from section 7.2.2:
+
+ . A port that is empty or not given is equivalent to port 80.
+ . Comparisons of host names MUST be case-insensitive.
+ . Comparisons of scheme names MUST be case-insensitive.
+ . An empty abs_path is equivalent to an abs_path of "/"
+Characters except those in the reserved set and the unsafe set (see
+section 7.2) are equivalent to their ""%" HEX HEX" encodings.
+
+For example, the following three URIs are equivalent:
+
+ http://abc.com:80/~smith/home.html
+ http://ABC.com/%7Esmith/home.html
+ http://ABC.com:/%7esmith/home.html
+
+
+
+
+7.3 Date/Time Formats
+
+7.3.1 Full Date
+HTTP applications have historically allowed three different formats for
+the representation of date/time stamps:
+
+ Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
+ Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
+ Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
+
+The first format is preferred as an Internet standard and represents a
+fixed-length subset of that defined by RFC 1123 (an update to RFC 822).
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The second format is in common use, but is based on the obsolete RFC
+850 date format and lacks a four-digit year. HTTP/1.1 clients and
+servers that parse the date value MUST accept all three formats, though
+they MUST generate only the RFC 1123 format for representing date/time
+stamps in HTTP message fields.
+
+ Note: Recipients of date values are encouraged to be robust in
+ accepting date values that may have been generated by non-HTTP
+ applications, as is sometimes the case when retrieving or posting
+ messages via proxies/gateways to SMTP or NNTP.
+
+All HTTP date/time stamps MUST be represented in Universal Time (UT),
+also known as Greenwich Mean Time (GMT), without exception. This is
+indicated in the first two formats by the inclusion of "GMT" as the
+three-letter abbreviation for time zone, and SHOULD be assumed when
+reading the asctime format.
+
+ HTTP-date = rfc1123-date | rfc850-date | asctime-date
+
+ rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+ rfc850-date = weekday "," SP date2 SP time SP "GMT"
+ asctime-date = wkday SP date3 SP time SP 4DIGIT
+
+ date1 = 2DIGIT SP month SP 4DIGIT
+ ; day month year (e.g., 02 Jun 1982)
+ date2 = 2DIGIT "-" month "-" 2DIGIT
+ ; day-month-year (e.g., 02-Jun-82)
+ date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
+ ; month day (e.g., Jun 2)
+
+ time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+ ; 00:00:00 - 23:59:59
+
+ wkday = "Mon" | "Tue" | "Wed"
+ | "Thu" | "Fri" | "Sat" | "Sun"
+
+ weekday = "Monday" | "Tuesday" | "Wednesday"
+ | "Thursday" | "Friday" | "Saturday" | "Sunday"
+
+ month = "Jan" | "Feb" | "Mar" | "Apr"
+ | "May" | "Jun" | "Jul" | "Aug"
+ | "Sep" | "Oct" | "Nov" | "Dec"
+
+ Note: HTTP requirements for the date/time stamp format apply only
+ to their usage within the protocol stream. Clients and servers are
+ not required to use these formats for user presentation, request
+ logging, etc.
+
+Additional rules for requirements on parsing and representation of dates
+and other potential problems with date representations include:
+
+ . HTTP/1.1 clients and caches should assume that an RFC-850 date
+ which appears to be more than 50 years in the future is in fact in
+ the past (this helps solve the "year 2000" problem).
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . An HTTP/1.1 implementation may internally represent a parsed
+ Expires date as earlier than the proper value, but MUST NOT
+ internally represent a parsed Expires date as later than the proper
+ value.
+ . All expiration-related calculations must be done in Universal Time
+ (GMT). The local time zone MUST NOT influence the calculation or
+ comparison of an age or expiration time.
+ . If an HTTP header incorrectly carries a date value with a time zone
+ other than GMT, it must be converted into GMT using the most
+ conservative possible conversion.
+
+
+
+
+7.3.2 Delta Seconds
+Some HTTP header fields allow a time value to be specified as an integer
+number of seconds, represented in decimal, after the time that the
+message was received. This format SHOULD only be used to represent short
+time periods or periods that cannot start until receipt of the message.
+
+ delta-seconds = 1*DIGIT
+
+
+7.4 Character Sets
+HTTP uses the same definition of the term "character set" as that
+described for MIME:
+
+ The term "character set" is used in this document to refer to a
+ method used with one or more tables to convert a sequence of octets
+ into a sequence of characters. Note that unconditional conversion
+ in the other direction is not required, in that not all characters
+ may be available in a given character set and a character set may
+ provide more than one sequence of octets to represent a particular
+ character. This definition is intended to allow various kinds of
+ character encodings, from simple single-table mappings such as US-
+ ASCII to complex table switching methods such as those that use ISO
+ 2022's techniques. However, the definition associated with a MIME
+ character set name MUST fully specify the mapping to be performed
+ from octets to characters. In particular, use of external profiling
+ information to determine the exact mapping is not permitted.
+
+ Note: This use of the term "character set" is more commonly
+ referred to as a "character encoding." However, since HTTP and MIME
+ share the same registry, it is important that the terminology also
+ be shared.
+
+HTTP character sets are identified by case-insensitive tokens. The
+complete set of tokens is defined by the IANA Character Set registry .
+However, because that registry does not define a single, consistent
+token for each character set, we define here the preferred names for
+those character sets most likely to be used with HTTP entities. These
+character sets include those registered by RFC 1521 -- the US-ASCII
+and ISO-8859 character sets -- and other names specifically recommended
+for use within MIME charset parameters.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ charset = "US-ASCII"
+ | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
+ | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
+ | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
+ | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
+ | "UNICODE-1-1" | "UNICODE-1-1-UTF-7"
+ | "UNICODE-1-1-UTF-8" | token
+
+Although HTTP allows an arbitrary token to be used as a charset value,
+any token that has a predefined value within the IANA Character Set
+registry MUST represent the character set defined by that registry.
+Applications SHOULD limit their use of character sets to those defined
+by the IANA registry.
+
+The character set of an entity body SHOULD be labeled as the lowest
+common denominator of the character codes used within that body, with
+the exception that no label is preferred over the labels US-ASCII or
+ISO-8859-1.
+
+
+7.5 Content Codings
+Content coding values indicate an encoding transformation that has been
+or can be applied to a resource entity. Content codings are primarily
+used to allow a document to be compressed or encrypted without losing
+the identity of its underlying media type. Typically, the resource
+entity is stored in this encoding and only decoded before rendering or
+analogous usage.
+
+ content-coding = "gzip" | "x-gzip"
+ | "compress" | "x-compress" | token
+
+ Note: For historical reasons, HTTP applications SHOULD consider "x-
+ gzip" and "x-compress" to be equivalent to "gzip" and "compress",
+ respectively.
+
+All content-coding values are case-insensitive. HTTP/1.1 uses content-
+coding values in the Accept-Encoding (section 18.3) and
+Content-Encoding
+(section 18.13) header fields. Although the value describes the
+content-
+coding, what is more important is that it indicates what decoding
+mechanism will be required to remove the encoding. Note that a single
+program MAY be capable of decoding multiple content-coding formats. Two
+values are defined by this specification:
+
+
+gzip
+ An encoding format produced by the file compression program "gzip"
+ (GNU zip) developed by Jean-loup Gailly. This format is typically a
+ Lempel-Ziv coding (LZ77) with a 32 bit CRC.
+
+compress
+ The encoding format produced by the file compression program
+ "compress". This format is an adaptive Lempel-Ziv-Welch coding
+ (LZW).
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ Note: Use of program names for the identification of encoding
+ formats is not desirable and should be discouraged for future
+ encodings. Their use here is representative of historical practice,
+ not good design.
+
+HTTP defines a registration process which uses the Internet Assigned
+Numbers Authority (IANA) as a central registry for content-coding value
+tokens. Additional content-coding value tokens beyond the four defined
+in this document (gzip x-gzip compress x-compress) SHOULD be registered
+with the IANA. To allow interoperability between clients and servers,
+specifications of the content coding algorithms used to implement a new
+value SHOULD be publicly available and adequate for independent
+implementation, and MUST conform to the purpose of content coding
+defined in this section.
+
+
+7.6 Transfer Codings
+Transfer coding values are used to indicate an encoding transformation
+that has been, can be, or may need to be applied to an Entity-Body in
+order to ensure safe transport through the network. This differs from a
+content coding in that the transfer coding is a property of the
+message,
+not of the original resource entity.
+
+ transfer-coding = "chunked" | transfer-extension
+
+ transfer-extension = token
+
+All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer
+coding values in the Transfer-Encoding header field (section 18.43).
+
+Transfer codings are analogous to the Content-Transfer-Encoding values
+of MIME , which were designed to enable safe transport of binary data
+over a 7-bit transport service. However, "safe transport" has a
+different focus for an 8bit-clean transfer protocol. In HTTP, the only
+unsafe characteristic of message bodies is the difficulty in determining
+the exact body length (section 11.2.2), or the desire to encrypt data
+over a shared transport.
+
+All HTTP/1.1 applications MUST be able to receive and decode the
+"chunked" transfer coding , and MUST ignore transfer coding extensions
+they do not understand. A server which receives a an entity-body with a
+transfer-coding it does not understand SHOULD return
+501(Unimplemented),
+and close the connection. A server MUST NOT send transfer-codings to a
+client that were not defined in the version of HTTP used in the client's
+request. Clients sending entity-bodies with transfer-codings SHOULD must
+be prepared for the connection to be closed if the server doesn't
+understand the transfer-coding. The chunked encoding modifies the body
+of a message in order to transfer it as a series of chunks, each with
+its own size indicator, followed by an optional footer containing
+entity-header fields. This allows dynamically-produced content to be
+transferred along with the information necessary for the recipient to
+verify that it has received the full message.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ Chunked-Body = *chunk
+ "0" CRLF
+ footer
+ CRLF
+
+ chunk = chunk-size [ chunk-ext ] CRLF
+ chunk-data CRLF
+
+ chunk-size = hex-no-zero *HEX
+ chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
+ chunk-ext-name = token
+ chunk-ext-val = token | quoted-string
+ chunk-data = chunk-size(OCTET)
+
+ footer = *<<Content-MD5 and future headers that specify
+ they are allowed in footer>>
+
+ hex-no-zero = <HEX excluding "0">
+
+Note that the chunks are ended by a zero-sized chunk, followed by the
+footer and terminated by an empty line. An example process for decoding
+a Chunked-Body is presented in appendix 23.3.6.
+
+
+7.7 Media Types
+HTTP uses Internet Media Types in the Content-Type (section 18.19) and
+Accept (section 18.1) header fields in order to provide open and
+extensible data typing and type negotiation.
+
+ media-type = type "/" subtype *( ";" parameter )
+ type = token
+ subtype = token
+
+Parameters may follow the type/subtype in the form of attribute/value
+pairs.
+
+ parameter = attribute "=" value
+ attribute = token
+ value = token | quoted-string
+
+The type, subtype, and parameter attribute names are case-insensitive.
+Parameter values may or may not be case-sensitive, depending on the
+semantics of the parameter name. LWS MUST NOT be generated between the
+type and subtype, nor between an attribute and its value. Upon receipt
+of a media type with an unrecognized parameter, a user agent SHOULD
+treat the media type as if the unrecognized parameter and its value were
+not present.
+
+Some older HTTP applications do not recognize media type parameters.
+HTTP/1.1 applications SHOULD only use media type parameters when they
+are necessary to define the content of a message.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Media-type values are registered with the Internet Assigned Number
+Authority (IANA ). The media type registration process is outlined in
+RFC 1590 . Use of non-registered media types is discouraged.
+
+
+7.7.1 Canonicalization and Text Defaults
+Internet media types are registered with a canonical form. In general,
+an Entity-Body transferred via HTTP MUST be represented in the
+appropriate canonical form prior to its transmission; the exception is
+"text" types, as defined in the next paragraph..
+
+when in canonical form , media subtypes of the "text" type use CRLF as
+the text line break. However, HTTP allows the transport of text media
+with plain CR or LF alone representing a line break when if it is done
+consistently for an entire Entity-Body.. HTTP applications MUST accept
+CRLF, bare CR, and bare LF as being representative of a line break in
+text media received via HTTP.In addition, if the text media is
+represented in a character set that does not use octets 13 and 10 for CR
+and LF respectively, as is the case for some multi-byte character sets,
+HTTP allows the use of whatever octet sequences are defined by that
+character set to represent the equivalent of CR and LF for line breaks.
+This flexibility regarding line breaks applies only to text media in the
+Entity-Body; a bare CR or LF MUST NOT be substituted for CRLF within any
+of the HTTP control structures (such as header fields and multipart
+boundaries).
+
+If an Entity-Body is encoded with a Content-Encoding, the underlying
+data MUST be in a form defined above prior to being encoded.
+
+The "charset" parameter is used with some media types to define the
+character set (section 7.4) of the data. When no explicit charset
+parameter is provided by the sender, media subtypes of the "text" type
+are defined to have a default charset value of "ISO-8859-1" when
+received via HTTP. Data in character sets other than "ISO-8859-1" or its
+subsets MUST be labeled with an appropriate charset value in order to be
+consistently interpreted by the recipient.
+
+ Note: Many current HTTP servers provide data using charsets other
+ than "ISO-8859-1" without proper labeling. This situation reduces
+ interoperability and is not recommended. To compensate for this,
+ some HTTP user agents provide a configuration option to allow the
+ user to change the default interpretation of the media type
+ character set when no charset parameter is given.
+
+
+
+
+7.7.2 Multipart Types
+MIME provides for a number of "multipart" types -- encapsulations of one
+or more entities within a single message's Entity-Body. All multipart
+types share a common syntax, as defined in section 7.2.1 of RFC 1521 ,
+and MUST include a boundary parameter as part of the media type value.
+The message body is itself a protocol element and MUST therefore use
+only CRLF to represent line breaks between body-parts. Unlike in RFC
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+1521, the epilogue of any multipart message MUST be empty; HTTP
+applications MUST NOT transmit the epilogue even if the original
+resource entity contains an epilogue.
+
+In HTTP, multipart body-parts MAY contain header fields which are
+significant to the meaning of that part.
+
+In general, an HTTP user agent SHOULD follow the same or similar
+behavior as a MIME user agent would upon receipt of a multipart type. If
+an application receives an unrecognized multipart subtype, the
+application MUST treat it as being equivalent to "multipart/mixed".
+
+ Note: The "multipart/form-data" type has been specifically defined
+ for carrying form data suitable for processing via the POST request
+ method, as described in RFC 1867 .
+
+
+
+
+7.8 Product Tokens
+Product tokens are used to allow communicating applications to identify
+themselves via a simple product token, with an optional slash and
+version designator. Most fields using product tokens also allow sub-
+products which form a significant part of the application to be listed,
+separated by whitespace. By convention, the products are listed in order
+of their significance for identifying the application.
+
+ product = token ["/" product-version]
+ product-version = token
+
+Examples:
+
+ User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+ Server: Apache/0.8.4
+
+Product tokens should be short and to the point -- use of them for
+advertising or other non-essential information is explicitly forbidden.
+Although any token character may appear in a product-version, this token
+SHOULD only be used for a version identifier (i.e., successive versions
+of the same product SHOULD only differ in the product-version portion of
+the product value).
+
+
+7.9 Quality Values
+HTTP content negotiation (section 15) uses short "floating point"
+numbers to indicate the relative importance ("weight") of various
+negotiable parameters. The weights are normalized to a real number in
+the range 0 through 1, where 0 is the minimum and 1 the maximum value.
+In order to discourage misuse of this feature, HTTP/1.1 applications
+MUST NOT generate more than three digits after the decimal point. User
+configuration of these values SHOULD also be limited in this fashion.
+
+ qvalue = ( "0" [ "." 0*3DIGIT ] )
+ | ( "1" [ "." 0*3("0") ] )
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+"Quality values" is a slight misnomer, since these values actually
+measure relative degradation in perceived quality. Thus, a value of
+"0.8" represents a 20% degradation from the optimum rather than a
+statement of 80% quality.
+
+
+7.10 Language Tags
+A language tag identifies a natural language spoken, written, or
+otherwise conveyed by human beings for communication of information to
+other human beings. Computer languages are explicitly excluded. HTTP
+uses language tags within the Accept-Language, and Content-Language
+fields.
+
+The syntax and registry of HTTP language tags is the same as that
+defined by RFC 1766 . In summary, a language tag is composed of 1 or
+more parts: A primary language tag and a possibly empty series of
+subtags:
+
+ language-tag = primary-tag *( "-" subtag )
+
+ primary-tag = 1*8ALPHA
+ subtag = 1*8ALPHA
+
+Whitespace is not allowed within the tag and all tags are case-
+insensitive. The name space of language tags is administered by the
+IANA. Example tags include:
+
+ en, en-US, en-cockney, i-cherokee, x-pig-latin
+
+where any two-letter primary-tag is an ISO 639 language abbreviation and
+any two-letter initial subtag is an ISO 3166 country code. (The last
+three tags above are not registered tags; all but the last are examples
+of tags which could be registered in future.)
+
+
+7.11 Entity Tags
+Entity tags are quoted strings whose internal structure is not visible
+to clients or caches. Entity tags are used as cache validators in
+HTTP/1.1.
+
+ entity-tag = strong-entity-tag | weak-entity-tag
+ | null-entity-tag
+ strong-entity-tag = quoted-string
+ weak-entity-tag = quoted-string "/W"
+ null-entity-tag = <"> <">
+
+ Note that the "/W" tag is considered part of a weak entity tag; it
+ MUST NOT be removed by any cache or client.
+
+There are two comparison functions on validators:
+
+ . The strong comparison function: in order to be considered equal,
+ both validators must be identical in every way, and neither may be
+ weak.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . The weak comparison function: in order to be considered equal, both
+ validators must be identical in every way, except for the presence
+ or absence of a "weak" tag.
+The weak comparison function MAY be used for simple (non-subrange) GET
+requests. The strong comparison function MUST be used in all other
+cases.
+
+The null validator is a special value, defined as never matching the
+current validator of an existing resource entity, and always matching
+the "current" validator of a resource entity that does not exist.
+
+
+7.12 Variant IDs
+A cache stores instances of resource entities, not instances of generic
+resources per se. Therefore, the URI of a generic resource is not
+sufficient for use as an identifier for a specific resource entity. In
+certain interactions between a cache and an origin server, it is
+convenient to encode that identifier using a more compact
+representation than the full set of selecting request headers (which may
+not even be possible if the selection criteria are not known to the
+cache).
+
+For these reasons, the HTTP protocol provides an optional mechanism for
+identifying a specific entity source of a generic resource, called a
+variant-ID.
+
+Variant-IDs are used to identify specific variants of a generic
+resource; see section 16.5.3 for how they are used.
+
+ variant-id = quoted-string
+
+Variant-IDs are compared using string octet-equality; case is
+significant.
+
+All responses from generic resources SHOULD include variant-IDs. If
+these are not present, the resource author can expect caches to
+correctly handle requests on the generic resource, but cannot expect the
+caching to be efficient.
+
+
+
+
+7.13 Variant Sets
+Validator sets are used for doing conditional retrievals on generic
+resources; see section 16.5.3.
+
+ variant-set = 1#variant-set-item
+ variant-set-item = opaque-validator ";" variant-id
+
+
+7.14 Range Protocol Parameters
+This section defines certain HTTP protocol parameters used in range
+requests and related responses.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+7.14.1 Range Units
+A resource entity may be broken down into subranges according to various
+structural units.
+
+ range-unit = bytes-unit | other-range-unit
+
+ bytes-unit = "bytes"
+ other-range-unit = token
+
+The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
+implementations may ignore ranges specified using other units.
+
+
+7.14.2 Byte Ranges
+Since all HTTP entities are represented in HTTP messages as sequences of
+bytes, the concept of a byte range is meaningful for any HTTP entity.
+(However, not all clients and servers need to support byte-range
+operations.)
+
+Byte range specifications in HTTP apply to the sequence of bytes that
+would be transferred by the protocol if no transfer-coding were being
+applied.
+
+ This means that if Content-coding is applied to the data, the byte
+ range specification applies to the resulting content-encoded byte
+ stream, not to the unencoded byte stream. It also means that if
+ the entity-body's media-type is a composite type (e.g., multipart/*
+ and message/rfc822), then the composite's body-parts may have their
+ own content-encoding and content-transfer-encoding, and the byte
+ range applies to the result of the those encodings.
+
+A byte range operation may specify a single range of bytes, or a set of
+ranges within a single entity.
+
+ ranges-specifier = byte-ranges-specifier
+
+ byte-ranges-specifier = bytes-unit "=" byte-range-set
+
+ byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
+
+ byte-range-spec = first-byte-pos "-" [last-byte-pos]
+
+ first-byte-pos = 1*DIGIT
+
+ last-byte-pos = 1*DIGIT
+
+The first-byte-pos value in a byte-range-spec gives the byte-offset of
+the first byte in a range. The last-byte-pos value gives the byte-
+offset of the last byte in the range; that is, the byte positions
+specified are inclusive. Byte offsets start at zero.
+
+If the last-byte-pos value is present, it must be greater than or equal
+to the first-byte-pos in that byte-range-spec, or the byte-range-spec is
+invalid. The recipient of an invalid byte-range-spec must ignore it.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 29]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+If the last-byte-pos value is absent, it is assumed to be equal to the
+current length of the entity in bytes.
+
+If the last-byte-pos value is larger than the current length of the
+entity, it is assumed to be equal to the current length of the entity.
+
+ suffix-byte-range-spec = "-" suffix-length
+
+ suffix-length = 1*DIGIT
+
+A suffix-byte-range-spec is used to specify the suffix of the entity, of
+a length given by the suffix-length value. (That is, this form
+specifies the last N bytes of an entity.) If the entity is shorter than
+the specified suffix-length, the entire entity is used.
+
+Examples of byte-ranges-specifier values (assuming an entity of length
+10000):
+
+ . The first 500 bytes (byte offsets 0-499, inclusive):
+ bytes=0-499
+
+ . The second 500 bytes (byte offsets 500-999, inclusive):
+ bytes=500-999
+
+ . The final 500 bytes (byte offsets 9500-9999, inclusive):
+ bytes=-500
+
+ . Or
+ bytes=9500-
+
+ . The first and last bytes only (bytes 0 and 9999):
+ bytes=0-0,-1
+
+ . Several legal but not canonical specifications of the second 500
+ bytes (byte offsets 500-999, inclusive):
+ bytes=500-600,601-999
+
+ bytes=500-700,601-999
+
+
+7.14.3 Content Ranges
+When a server returns a partial response to a client, it must describe
+both the extent of the range covered by the response, and the length of
+the entire entity.
+
+ content-range-spec = byte-content-range-spec
+
+ byte-content-range-spec = bytes-unit SP first-byte-pos "-"
+ last-byte-pos "/" entity-length
+
+ entity-length = 1*DIGIT
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 30]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Unlike byte-ranges-specifier values, a byte-content-range-spec may only
+specify one range, and must contain absolute byte positions for both the
+first and last byte of the range.
+
+A byte-content-range-spec whose last-byte-pos value is less than its
+first-byte-pos value, or whose entity-length value is less than or equal
+to its last-byte-pos value, is invalid. The recipient of an invalid
+byte-content-range-spec MUST ignore it and any content transferred along
+with it.
+
+Examples of byte-content-range-spec values, assuming that the entity
+contains a total of 1234 bytes:
+
+ . The first 500 bytes:
+ bytes 0-499/1234
+
+ . The second 500 bytes:
+ bytes 500-999/1234
+
+ . All except for the first 500 bytes:
+ bytes 500-1233/1234
+
+ . The last 500 bytes:
+ bytes 734-1233/1234
+
+
+8 HTTP Message
+
+8.1 Message Types
+HTTP messages consist of requests from client to server and responses
+from server to client.
+
+ HTTP-message = Full-Request ; HTTP/1.1 messages
+ | Full-Response
+
+Full-Request and Full-Response use the generic message format of RFC 822
+for transferring entities. Both messages may include optional header
+fields (also known as "headers") and an entity body. The entity body is
+separated from the headers by a null line (i.e., a line with nothing
+preceding the CRLF).
+
+
+8.2 Message Headers
+HTTP header fields, which include General-Header (Section 8.3),
+Request-
+Header (Section 9.2), Response-Header (Section 10.2), and Entity-Header
+(Section 11.1) fields, follow the same generic format as that given in
+Section 3.1 of RFC 822 . Each header field consists of a name followed
+by a colon (":") and the field value. Field names are case-insensitive.
+The field value may be preceded by any amount of LWS, though a single SP
+is preferred. Header fields can be extended over multiple lines by
+preceding each extra line with at least one SP or HT.
+
+ HTTP-header = field-name ":" [ field-value ] CRLF
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ field-name = token
+ field-value = *( field-content | LWS )
+
+ field-content = <the OCTETs making up the field-value
+ and consisting of either *TEXT or combinations
+ of token, tspecials, and quoted-string>
+
+The order in which header fields with differing field names are received
+is not significant. However, it is "good practice" to send General-
+Header fields first, followed by Request-Header or Response-Header
+fields, and ending with the Entity-Header fields.
+
+Multiple HTTP-header fields with the same field-name may be present in a
+message if and only if the entire field-value for that header field is
+defined as a comma-separated list [i.e., #(values)]. It MUST be possible
+to combine the multiple header fields into one "field-name:
+field-value"
+pair, without changing the semantics of the message, by appending each
+subsequent field-value to the first, each separated by a comma. Thus,
+the order in which multiple header fields with the same field-name are
+received may be significant to the interpretation of the combined
+field-
+value.
+
+
+8.3 General Header Fields
+There are a few header fields which have general applicability for both
+request and response messages, but which do not apply to the entity
+being transferred. These headers apply only to the message being
+transmitted.
+
+ General-Header = Cache-Control ; Section 18.10
+ | Connection ; Section 18.11
+ | Date ; Section 18.20
+ | Via ; Section 18.47
+ | Keep-Alive ; Section 23.5.2.5.1
+ | Pragma ; Section 18.34
+ | Upgrade ; Section 18.44
+
+General header field names can be extended reliably only in combination
+with a change in the protocol version. However, new or experimental
+header fields may be given the semantics of general header fields if all
+parties in the communication recognize them to be general header
+fields.
+Unrecognized header fields are treated as Entity-Header fields.
+
+
+9 Request
+A request message from a client to a server includes, within the first
+line of that message, the method to be applied to the resource, the
+identifier of the resource, and the protocol version in use. For
+backwards compatibility with the more limited HTTP/0.9 protocol, there
+are two valid formats for an HTTP request:
+
+ Request = Full-Request
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ Full-Request = Request-Line ; Section 9.1
+ *( General-Header ; Section 8.3
+ | Request-Header ; Section 9.2
+ | Entity-Header ) ; Section 11.1
+ CRLF
+ [ Entity-Body ] ; Section 11.2
+
+
+
+
+9.1 Request-Line
+The Request-Line begins with a method token, followed by the
+Request-URI
+and the protocol version, and ending with CRLF. The elements are
+separated by SP characters. No CR or LF are allowed except in the final
+CRLF sequence.
+
+ Request-Line = CRLF | Method SP Request-URI SP HTTP-Version CRLF
+
+In the interest of robustness, HTTP/1.1 servers SHOULD ignore null
+request lines (ones that comprise just CRLF). An HTTP/1.1 client MUST
+NOT preface a request with CRLF.
+
+
+9.1.1 Method
+The Method token indicates the method to be performed on the resource
+identified by the Request-URI. The method is case-sensitive.
+
+ Method = "OPTIONS" ; Section 13.1
+ | "GET" ; Section 13.2
+ | "HEAD" ; Section 13.3
+ | "POST" ; Section 13.4
+ | "PUT" ; Section 13.5
+ | "DELETE" ; Section 13.6
+ | "TRACE" ; Section 13.7
+ | extension-method
+
+ extension-method = token
+
+The list of methods acceptable by a plain resource can be specified in
+an Allow header field (section 18.7). However, the client is always
+notified through the return code of the response whether a method is
+currently allowed on a plain resource, as this can change dynamically.
+Servers SHOULD return the status code 405 (method not allowed) if the
+method is known by the server but not allowed for the requested
+resource, and 501 (not implemented) if the method is unrecognized or not
+implemented by the server. The list of methods known by a server can be
+listed in a Public response header field (section 18.37).
+
+The methods GET and HEAD MUST be supported by all general-purpose
+servers. Servers which provide Last-Modified dates for resources MUST
+also support the conditional GET method. All other methods are
+optional;
+however, if the above methods are implemented, they MUST be implemented
+with the same semantics as those specified in section 13.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+9.1.2 Request-URI
+The Request-URI is a Uniform Resource Identifier (section 7.2) and
+identifies the resource upon which to apply the request.
+
+ Request-URI = "*" | absoluteURI | abs_path
+
+The three options for Request-URI are dependent on the nature of the
+request. The asterisk "*" means that the request does not apply to a
+particular resource, but to the server itself, and is only allowed when
+the Method used does not necessarily apply to a resource. One example
+would be
+
+ OPTIONS * HTTP/1.1
+
+The absoluteURI form is required when the request is being made to a
+proxy. The proxy is requested to forward the request or service it from
+a valid cache, and return the response.. Note that the proxy MAY forward
+the request on to another proxy or directly to the server specified by
+the absoluteURI. In order to avoid request loops, a proxy MUST be able
+to recognize all of its server names, including any aliases, local
+variations, and the numeric IP address. An example Request-Line would
+be:
+
+ GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+
+To allow for transition to absoluteURIs in all requests in future
+versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form
+in requests, even though HTTP/1.1 clients will only generate them in
+requests to proxies. The Host request-header field MUST be ignored in
+requests using an absoluteURL as the Request-URI.
+
+The most common form of Request-URI is that used to identify a resource
+on an origin server or gateway. In this case the absolute path of the
+URI MUST be transmitted (see 7.2.1, abs_path) as the Request-URI, and
+the network location of the URI (net_loc) MUST be transmitted in a Host
+header field.. For example, a client wishing to retrieve the resource
+above directly from the origin server would create a TCP connection to
+port 80 of the host "www.w3.org" and send the lines:
+
+ GET /pub/WWW/TheProject.html HTTP/1.1
+ Host:www.w3.org
+
+followed by the remainder of the Full-Request. Note that the absolute
+path cannot be empty; if none is present in the original URI, it MUST be
+given as "/" (the server root).
+
+If a proxy receives a request without any path in the Request-URI and
+the method specified is capable of supporting the asterisk form of
+request, then the last proxy on the request chain MUST forward the
+request with "*" as the final Request-URI. For example, the request
+
+ OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
+
+would be forwarded by the proxy as
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 34]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ OPTIONS * HTTP/1.1
+ Host: www.ics.uci.edu:8001
+
+after connecting to port 8001 of host "www.ics.uci.edu".
+
+The Request-URI is transmitted as an encoded string, where some
+characters may be escaped using the "% HEX HEX" encoding defined by RFC
+1738 . The origin server MUST decode the Request-URI in order to
+properly interpret the request. In requests that they forward, proxies
+MUST NOT rewrite the "abs_path" part of a Request-URI in any way except
+as noted above to replace a null abs_path with "*". Illegal
+Request-URIs
+SHOULD be responded to with an appropriate status code. Proxies MAY
+transform the Request-URI for internal processing purposes, but SHOULD
+NOT send such a transformed Request-URI in forwarded requests.
+
+ The main reason for this rule is to make sure that the form of
+ Request-URI is well specified, to enable future extensions without
+ fear that they will break in the face of some rewritings. Another
+ is that one consequence of rewriting the Request-URI is that
+ integrity or authentication checks by the server may fail; since
+ rewriting MUST be avoided in this case, it may as well be
+ proscribed in general. Implementers should be aware that some pre-
+ HTTP/1.1 proxies do some rewriting.
+
+
+9.2 The Resource Identified by a Request
+HTTP/1.1 origin servers SHOULD be aware that the exact resource
+identified by an Internet request is determined by examining both the
+Request-URI and the Host header field. An origin server that does not
+allow resources to differ by the requested host MAY ignore the Host
+header field. An origin server that does differentiate resources based
+on the host requested (sometimes referred to as virtual hosts or vanity
+hostnames) MUST use the following rules for determining the requested
+resource on an HTTP/1.1 request:.
+
+ 1. If Request-URI is an absoluteURI, the host is included in the
+ Request-URI. Any Host header field in the request MUST be
+ignored.
+ 2. If the Request-URI is not an absoluteURI, and the request includes
+ a Host header field, the host is determined by the Host header
+ field.
+ 3. If the request-URI is not an absoluteURI and no Host header field
+ is present (or does not represent a valid host on that server),
+ the response MUST be a 400 (Bad Request) error message.
+Recipients of an HTTP/1.0 request lacking a Host header field MAY
+attempt to use heuristics (e.g., examination of the URI path for
+something unique to a particular host) in order to determine what exact
+resource is being requested.
+
+
+9.3 Request Header Fields
+The request header fields allow the client to pass additional
+information about the request, and about the client itself, to the
+server. These fields act as request modifiers, with semantics
+equivalent
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+to the parameters on a programming language method (procedure)
+invocation.
+
+ Request-Header = Accept ; Section 18.1
+ | Accept-Charset ; Section 18.2
+ | Accept-Encoding ; Section 18.3
+ | Accept-Language ; Section 18.4
+ | Authorization ; Section 18.8
+ | From ; Section 18.23
+ | Host ; Section 18.24
+ | If-Modified-Since ; Section 18.25
+ | If-Range ; Section 18.28
+ | Proxy-Authorization ; Section 18.36
+ | Range ; Section 18.38
+ | Referer ; Section 18.39
+ | User-Agent ; Section 18.45
+ | Max-Forwards ; Section 18.32
+
+Request-Header field names can be extended reliably only in combination
+with a change in the protocol version. However, new or experimental
+header fields MAY be given the semantics of request header fields if all
+parties in the communication recognize them to be request header
+fields.
+Unrecognized header fields are treated as Entity-Header fields.
+
+
+10 Response
+After receiving and interpreting a request message, a server responds in
+the form of an HTTP response message.
+
+ Response = Full-Response
+
+ Full-Response = Status-Line ; Section 10.1
+ *( General-Header ; Section 8.3
+ | Response-Header ; Section 10.2
+ | Entity-Header ) ; Section 11.1
+ CRLF
+ [ Entity-Body ] ; Section 11.2
+
+
+10.1 Status-Line
+The first line of a Full-Response message is the Status-Line, consisting
+of the protocol version followed by a numeric status code and its
+associated textual phrase, with each element separated by SP
+characters.
+No CR or LF is allowed except in the final CRLF sequence.
+
+ Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+
+10.1.1 Status Code and Reason Phrase
+The Status-Code element is a 3-digit integer result code of the attempt
+to understand and satisfy the request. The Reason-Phrase is intended to
+give a short textual description of the Status-Code. The Status-Code is
+intended for use by automata and the Reason-Phrase is intended for the
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+human user. The client is not required to examine or display the
+Reason-
+Phrase.
+
+The first digit of the Status-Code defines the class of response. The
+last two digits do not have any categorization role. There are 5 values
+for the first digit:
+
+
+ . 1xx: Informational - Request received, continuing process
+
+ . 2xx: Success - The action was successfully received, understood,
+ and accepted
+
+ . 3xx: Redirection - Further action must be taken in order to
+ complete the request
+
+ . 4xx: Client Error - The request contains bad syntax or cannot be
+ fulfilled
+
+ . 5xx: Server Error - The server failed to fulfill an apparently
+ valid request
+The individual values of the numeric status codes defined for HTTP/1.1,
+and an example set of corresponding Reason-Phrase's, are presented
+below. The reason phrases listed here are only recommended -- they may
+be replaced by local equivalents without affecting the protocol. These
+codes are fully defined in section 12.
+
+ Status-Code = "100" ; Continue
+ | "101" ; Switching Protocols
+ | "200" ; OK
+ | "201" ; Created
+ | "202" ; Accepted
+ | "203" ; Non-Authoritative Information
+ | "204" ; No Content
+ | "205" ; Reset Content
+ | "206" ; Partial Content
+ | "300" ; Multiple Choices
+ | "301" ; Moved Permanently
+ | "302" ; Moved Temporarily
+ | "303" ; See Other
+ | "304" ; Not Modified
+ | "305" ; Use Proxy
+ | "400" ; Bad Request
+ | "401" ; Unauthorized
+ | "402" ; Payment Required
+ | "403" ; Forbidden
+ | "404" ; Not Found
+ | "405" ; Method Not Allowed
+ | "406" ; Not Acceptable
+ | "407" ; Proxy Authentication Required
+ | "408" ; Request Time-out
+ | "409" ; Conflict
+ | "410" ; Gone
+ | "411" ; Length Required
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ | "412" ; Precondition Failed
+ | "413" ; Request Entity Too Large
+ | "414" ; Request URI Too Large
+ | "415" ; Unsupported Media Type
+ | "500" ; Internal Server Error
+ | "501" ; Not Implemented
+ | "502" ; Bad Gateway
+ | "503" ; Service Unavailable
+ | "504" ; Gateway Time-out
+ | "505" ; HTTP Version not supported
+ | extension-code
+
+ extension-code = 3DIGIT
+
+ Reason-Phrase = *<TEXT, excluding CR, LF>
+
+HTTP status codes are extensible. HTTP applications are not required to
+understand the meaning of all registered status codes, though such
+understanding is obviously desirable. However, applications MUST
+understand the class of any status code, as indicated by the first
+digit, and treat any unrecognized response as being equivalent to the
+x00 status code of that class, with the exception that an unrecognized
+response MUST NOT be cached. For example, if an unrecognized status code
+of 431 is received by the client, it can safely assume that there was
+something wrong with its request and treat the response as if it had
+received a 400 status code. In such cases, user agents SHOULD present to
+the user the entity returned with the response, since that entity is
+likely to include human-readable information which will explain the
+unusual status.
+
+
+10.2 Response Header Fields
+The response header fields allow the server to pass additional
+information about the response which cannot be placed in the Status-
+Line. These header fields give information about the server and about
+further access to the resource identified by the Request-URI.
+
+ Response-Header = Location ; Section 18.31
+ | Proxy-Authenticate ; Section 18.35
+ | Public ; Section 18.37
+ | Retry-After ; Section 18.40
+ | Server ; Section 18.41
+ | WWW-Authenticate ; Section 18.46
+
+Response-Header field names can be extended reliably only in combination
+with a change in the protocol version. However, new or experimental
+header fields MAY be given the semantics of response header fields if
+all parties in the communication recognize them to be response header
+fields. Unrecognized header fields are treated as Entity-Header fields.
+
+
+11 Entity
+Full-Request and Full-Response messages MAY transfer an entity within
+some requests and responses. An entity consists of Entity-Header fields
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+and (usually) an Entity-Body. In this section, both sender and recipient
+refer to either the client or the server, depending on who sends and who
+receives the entity.
+
+
+11.1 Entity Header Fields
+Entity-Header fields define optional metainformation about the Entity-
+Body or, if no body is present, about the resource identified by the
+request.
+
+ Entity-Header = Allow ; Section 18.7
+ | Content-Base ; Section 18.12
+ | Content-Encoding ; Section 18.3
+ | Content-Language ; Section 18.14
+ | Content-Length ; Section 18.15
+ | Content-Location ; Section 18.16
+ | Content-MD5 ; Section 0
+ | Content-Range ; Section 18.18
+ | Content-Type ; Section 18.19
+ | Expires ; Section 18.22
+ | Last-Modified ; Section 18.30
+ | Title ; Section 18.42
+ | Transfer-Encoding ; Section 18.43
+ | extension-header
+
+ extension-header = HTTP-header
+
+The extension-header mechanism allows additional Entity-Header fields to
+be defined without changing the protocol, but these fields cannot be
+assumed to be recognizable by the recipient. Unrecognized header fields
+SHOULD be ignored by the recipient and forwarded by proxies.
+
+
+11.2 Entity Body
+The entity body (if any) sent with an HTTP request or response is in a
+format and encoding defined by the Entity-Header fields.
+
+ Entity-Body = *OCTET
+
+An entity body MUST ONLY be included with a request message when the
+request method calls for one. The presence of an entity body in a
+request is signaled by the inclusion of a Content-Length and/or
+Content-
+Type header field in the request message headers.
+
+For response messages, whether or not an entity body is included with a
+message is dependent on both the request method and the response code.
+All responses to the HEAD request method MUST NOT include a body, even
+though the presence of entity header fields may lead one to believe they
+do. All 1xx (informational), 204 (no content), and 304 (not modified)
+responses MUST NOT include a body. All other responses MUST include an
+entity body or a Content-Length header field defined with a value of
+zero (0).
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+11.2.1 Type
+When an entity body is included with a message, the data type of that
+body is determined via the header fields Content-Type,
+Content-Encoding,
+and Transfer-Encoding. These define a three-layer, ordered encoding
+model:
+
+ entity-body :=
+ Transfer-Encoding( Content-Encoding( Content-Type( data ) ) )
+
+The default for both encodings is none (i.e., the identity function).
+Content-Type specifies the media type of the underlying data. Content-
+Encoding may be used to indicate any additional content codings applied
+to the type, usually for the purpose of data compression, that are a
+property of the resource entity requested. Transfer-Encoding may be
+used to indicate any additional transfer codings applied by an
+application to ensure safe and proper transfer of the message. Note that
+Transfer-Encoding is a property of the message, not of the resource
+entity.
+
+Any HTTP/1.1 message containing an entity body SHOULD include a
+Content-
+Type header field defining the media type of that body. If and only if
+the media type is not given by a Content-Type header, the recipient may
+attempt to guess the media type via inspection of its content and/or the
+name extension(s) of the URL used to identify the resource. If the media
+type remains unknown, the recipient SHOULD treat it as type
+"application/octet-stream".
+
+
+11.2.2 Length
+When an entity body is included with a message, the length of that body
+may be determined in one of several ways. If a Content-Length header
+field is present, its value in bytes represents the length of the entity
+body. Otherwise, the body length is determined by the Transfer-Encoding
+(if the "chunked" transfer coding has been applied) or by the server
+closing the connection.
+
+ Note: Any response message which MUST NOT include an entity body
+ (such as the 1xx, 204, and 304 responses and any response to a HEAD
+ request) is always terminated by the first empty line after the
+ header fields, regardless of the entity header fields present in
+ the message.
+
+Closing the connection cannot be used to indicate the end of a request
+body, since it leaves no possibility for the server to send back a
+response. For compatibility with HTTP/1.0 applications, HTTP/1.1
+requests containing an entity body MUST include a valid Content-Length
+header field unless the server is known to be HTTP/1.1 compliant.
+HTTP/1.1 servers MUST accept the "chunked" transfer coding (section
+7.6), thus allowing this mechanism to be used for a request when
+Content-Length is unknown.
+
+If a request contains an entity body and Content-Length is not
+specified, the server SHOULD respond with 400 (bad request) if it cannot
+determine the length of the request message's content, or with 411
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+(length required) if it wishes to insist on receiving a valid Content-
+Length.
+
+Messages MUST NOT include both a Content-Length header field and the
+"chunked" transfer coding. If both are received, the Content-Length MUST
+be ignored.
+
+When a Content-Length is given in a message where an entity body is
+allowed, its field value MUST exactly match the number of OCTETs in the
+entity body. HTTP/1.1 user agents MUST notify the user when an invalid
+length is received and detected.
+
+
+12 Status Code Definitions
+Each Status-Code is described below, including a description of which
+method(s) it can follow and any metainformation required in the
+response.
+
+
+12.1 Informational 1xx
+This class of status code indicates a provisional response, consisting
+only of the Status-Line and optional headers, and is terminated by an
+empty line. Since HTTP/1.0 did not define any 1xx status codes, servers
+MUST NOT send a 1xx response to an HTTP/1.0 client except under
+experimental conditions.
+
+
+12.1.1.1 100 Continue
+The client may continue with its request. This interim response is used
+to inform the client that the initial part of the request has been
+received and has not yet been rejected by the server. The client SHOULD
+continue by sending the remainder of the request or, if the request has
+already been completed, ignore this response. The server MUST send a
+final response after the request has been completed.
+
+
+12.1.1.2 101 Switching Protocols
+The server understands and is willing to comply with the client's
+request, via the Upgrade message header field (section 18.44), for a
+change in the application protocol being used on this connection. The
+server will switch protocols to those defined by the response's Upgrade
+header field immediately after the empty line which terminates the 101
+response.
+
+The protocol should only be switched when it is advantageous to do so.
+For example, switching to a newer version of HTTP is advantageous over
+older versions, and switching to a real-time, synchronous protocol may
+be advantageous when delivering resources that use such features.
+
+
+12.2 Successful 2xx
+This class of status code indicates that the client's request was
+successfully received, understood, and accepted.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.2.1.1 200 OK
+The request has succeeded. The information returned with the response is
+dependent on the method used in the request, as follows:
+
+
+GET
+ an entity corresponding to the requested resource is sent in the
+ response;
+
+HEAD
+ the response MUST only contain the header information and no Entity-
+ Body;
+
+POST
+ an entity describing or containing the result of the action;
+
+TRACE
+ an entity containing the request message as received by the end
+ server;
+
+otherwise,
+ an entity describing the result of the action;
+If the entity corresponds to a resource, the response MAY include a
+Content-Location header field giving the actual location of that plain
+resource for later reference.
+
+
+12.2.1.2 201 Created
+The request has been fulfilled and resulted in a new resource being
+created. The newly created resource can be referenced by the URI(s)
+returned in the entity of the response, with the most specific URL for
+the resource given by a Location header field. The origin server SHOULD
+create the resource before returning this status code. If the action
+cannot be carried out immediately, the server MUST include in the
+response body a description of when the resource will be available;
+otherwise, the server SHOULD respond with 202 (Accepted).
+
+
+12.2.1.3 202 Accepted
+The request has been accepted for processing, but the processing has not
+been completed. The request MAY or MAY NOT eventually be acted upon, as
+it MAY be disallowed when processing actually takes place. There is no
+facility for re-sending a status code from an asynchronous operation
+such as this.
+
+The 202 response is intentionally non-committal. Its purpose is to allow
+a server to accept a request for some other process (perhaps a batch-
+oriented process that is only run once per day) without requiring that
+the user agent's connection to the server persist until the process is
+completed. The entity returned with this response SHOULD include an
+indication of the request's current status and either a pointer to a
+status monitor or some estimate of when the user can expect the request
+to be fulfilled.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 42]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.2.1.4 203 Non-Authoritative Information
+The returned metainformation in the Entity-Header is not the definitive
+set as available from the origin server, but is gathered from a local or
+a third-party copy. The set presented MAY be a subset or superset of the
+original version. For example, including local annotation information
+about the resource MAY result in a superset of the metainformation known
+by the origin server. Use of this response code is not required and is
+only appropriate when the response would otherwise be 200 (OK).
+
+
+12.2.1.5 204 No Content
+The server has fulfilled the request but there is no new information to
+send back. If the client is a user agent, it SHOULD NOT change its
+document view from that which caused the request to be generated. This
+response is primarily intended to allow input for actions to take place
+without causing a change to the user agent's active document view. The
+response MAY include new metainformation in the form of entity headers,
+which SHOULD apply to the document currently in the user agent's active
+view.
+
+The 204 response MUST NOT include an entity body, and thus is always
+terminated by the first empty line after the header fields.
+
+
+12.2.1.6 205 Reset Content
+The server has fulfilled the request and the user agent SHOULD reset the
+document view which caused the request to be generated. This response is
+primarily intended to allow input for actions to take place via user
+input, followed by a clearing of the form in which the input is given so
+that the user can easily initiate another input action. The response
+MUST include a Content-Length with a value of zero (0) and no entity
+body.
+
+
+12.2.1.7 206 Partial Content
+The server has fulfilled the partial GET request for the resource. The
+request MUST have included a Range header field (section 18.38)
+indicating the desired range. The response MUST include a Content-Range
+header field (section 18.18) indicating the range included with this
+response. All entity header fields in the response MUST describe the
+partial entity transmitted rather than what would have been transmitted
+in a full response. In particular, the Content-Length header field in
+the response MUST match the actual number of OCTETs transmitted in the
+entity body. It is assumed that the client already has the complete
+entity's header field data.
+
+
+12.3 Redirection 3xx
+This class of status code indicates that further action needs to be
+taken by the user agent in order to fulfill the request. The action
+required MAY be carried out by the user agent without interaction with
+the user if and only if the method used in the second request is GET or
+HEAD. A user agent SHOULD NOT automatically redirect a request more than
+5 times, since such redirections usually indicate an infinite loop.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 43]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.3.1.1 300 Multiple Choices
+This status code is reserved for future use by a planned content
+negotiation mechanism. HTTP/1.1 user agents receiving a 300 response
+which includes a Location header field can treat this response as they
+would treat a 303 (See Other) response. If no Location header field is
+included, the appropriate action is to display the entity enclosed in
+the response to the user.
+
+
+12.3.1.2 301 Moved Permanently
+The requested resource has been assigned a new permanent URI and any
+future references to this resource SHOULD be done using one of the
+returned URIs. Clients with link editing capabilities SHOULD
+automatically re-link references to the Request-URI to one or more of
+the new references returned by the server, where possible. This response
+is cachable unless indicated otherwise.
+
+If the new URI is a location, its URL MUST be given by the Location
+field in the response. Unless it was a HEAD request, the Entity-Body of
+the response SHOULD contain a short hypertext note with a hyperlink to
+the new URI(s).
+
+If the 301 status code is received in response to a request other than
+GET or HEAD, the user agent MUST NOT automatically redirect the request
+unless it can be confirmed by the user, since this might change the
+conditions under which the request was issued.
+
+ Note: When automatically redirecting a POST request after receiving
+ a 301 status code, some existing HTTP/1.0 user agents will
+ erroneously change it into a GET request.
+
+
+12.3.1.3 302 Moved Temporarily
+The requested resource resides temporarily under a different URI. Since
+the redirection may be altered on occasion, the client SHOULD continue
+to use the Request-URI for future requests. This response is only
+cachable if indicated by a Cache-Control or Expires header field.
+
+If the new URI is a location, its URL MUST be given by the Location
+field in the response. Unless it was a HEAD request, the Entity-Body of
+the response SHOULD contain a short hypertext note with a hyperlink to
+the new URI(s).
+
+If the 302 status code is received in response to a request other than
+GET or HEAD, the user agent MUST NOT automatically redirect the request
+unless it can be confirmed by the user, since this might change the
+conditions under which the request was issued.
+
+ Note: When automatically redirecting a POST request after receiving
+ a 302 status code, some existing HTTP/1.0 user agents will
+ erroneously change it into a GET request.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 44]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.3.1.4 303 See Other
+The response to the request can be found under a different URI and
+SHOULD be retrieved using a GET method on that resource. This method
+exists primarily to allow the output of a POST-activated script to
+redirect the user agent to a selected resource. The new resource is not
+a update reference for the original Request-URI. The 303 response is not
+cachable, but the response to the second request MAY be cachable.
+
+If the new URI is a location, its URL MUST be given by the Location
+field in the response. Unless it was a HEAD request, the Entity-Body of
+the response SHOULD contain a short hypertext note with a hyperlink to
+the new URI(s).
+
+
+12.3.1.5 304 Not Modified
+If the client has performed a conditional GET request and access is
+allowed, but the document has not been modified since the date and time
+specified in the If-Modified-Since field, the server MUST respond with
+this status code and not send an Entity-Body to the client. Header
+fields contained in the response SHOULD only include information which
+is relevant to cache managers or which MAY have changed independently of
+the entity's Last-Modified date. Examples of relevant header fields
+include: Date, Server, Content-Length, Content-MD5, Content-Version,
+Cache-Control and Expires.
+
+A cache SHOULD update its cached entity to reflect any new field values
+given in the 304 response. If the new field values indicate that the
+cached entity differs from the current resource entity (as would be
+indicated by a change in Content-Length, Content-MD5, or Content-
+Version), then the cache MUST disregard the 304 response and repeat the
+request without an If-Modified-Since field.
+
+The 304 response MUST NOT include an entity body, and thus is always
+terminated by the first empty line after the header fields.
+
+
+12.3.1.6 305 Use Proxy
+The requested resource MUST be accessed through the proxy given by the
+Location field in the response. In other words, this is a proxy
+redirect.
+
+
+12.4 Client Error 4xx
+The 4xx class of status code is intended for cases in which the client
+seems to have erred. If the client has not completed the request when a
+4xx code is received, it SHOULD immediately cease sending data to the
+server. Except when responding to a HEAD request, the server SHOULD
+include an entity containing an explanation of the error situation, and
+whether it is a temporary or permanent condition. These status codes are
+applicable to any request method.
+
+ Note: If the client is sending data, server implementations using
+ TCP SHOULD be careful to ensure that the client acknowledges
+ receipt of the packet(s) containing the response prior to closing
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ the input connection. If the client continues sending data to the
+ server after the close, the server's controller will send a reset
+ packet to the client, which may erase the client's unacknowledged
+ input buffers before they can be read and interpreted by the HTTP
+ application.
+
+
+12.4.1.1 400 Bad Request
+The request could not be understood by the server due to malformed
+syntax. The client SHOULD NOT repeat the request without modifications.
+
+
+12.4.1.2 401 Unauthorized
+The request requires user authentication. The response MUST include a
+WWW-Authenticate header field (section 18.46) containing a challenge
+applicable to the requested resource. The client MAY repeat the request
+with a suitable Authorization header field (section 18.8). If the
+request already included Authorization credentials, then the 401
+response indicates that authorization has been refused for those
+credentials. If the 401 response contains the same challenge as the
+prior response, and the user agent has already attempted authentication
+at least once, then the user SHOULD be presented the entity that was
+given in the response, since that entity MAY include relevant diagnostic
+information. HTTP access authentication is explained in section 14.
+
+
+12.4.1.3 402 Payment Required
+This code is reserved for future use.
+
+
+12.4.1.4 403 Forbidden
+The server understood the request, but is refusing to fulfill it.
+Authorization will not help and the request SHOULD not be repeated. If
+the request method was not HEAD and the server wishes to make public why
+the request has not been fulfilled, it SHOULD describe the reason for
+the refusal in the entity body. This status code is commonly used when
+the server does not wish to reveal exactly why the request has been
+refused, or when no other response is applicable.
+
+
+12.4.1.5 404 Not Found
+The server has not found anything matching the Request-URI. No
+indication is given of whether the condition is temporary or permanent.
+If the server does not wish to make this information available to the
+client, the status code 403 (Forbidden) can be used instead. The 410
+(Gone) status code SHOULD be used if the server knows, through some
+internally configurable mechanism, that an old resource is permanently
+unavailable and has no forwarding address.
+
+
+12.4.1.6 405 Method Not Allowed
+The method specified in the Request-Line is not allowed for the resource
+identified by the Request-URI. The response MUST include an Allow header
+containing a list of valid methods for the requested resource.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 46]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.4.1.7 406 Not Acceptable
+The resource identified by the request is only capable of generating
+response entities which have content characteristics not acceptable
+according to the accept headers sent in the request.
+
+HTTP/1.1 servers are allowed to return responses which are not
+acceptable according to the accept headers sent in the request. In some
+cases, this may even be preferable to sending a 406 response. User
+agents are encouraged to inspect the headers of an incoming response to
+determine if it is acceptable. If the response is not acceptable, user
+agents SHOULD interrupt the receipt of the response if doing so would
+save network resources. If it is unknown whether an incoming response
+would be acceptable, a user agent SHOULD temporarily stop receipt of
+more data and query the user for a decision on furtheractions.
+
+
+12.4.1.8 407 Proxy Authentication Required
+This code is similar to 401 (Unauthorized), but indicates that the
+client MUST first authenticate itself with the proxy. The proxy MUST
+return a Proxy-Authenticate header field (section 18.35) containing a
+challenge applicable to the proxy for the requested resource. The client
+MAY repeat the request with a suitable Proxy-Authorization header field
+(section 18.36). HTTP access authentication is explained in section 14.
+
+
+12.4.1.9 408 Request Timeout
+The client did not produce a request within the time that the server was
+prepared to wait. The client MAY repeat the request without
+modifications at any later time.
+
+
+12.4.1.10 409 Conflict
+The request could not be completed due to a conflict with the current
+state of the resource. This code is only allowed in situations where it
+is expected that the user MAY be able to resolve the conflict and
+resubmit the request. The response body SHOULD include enough
+information for the user to recognize the source of the conflict.
+Ideally, the response entity would include enough information for the
+user or user-agent to fix the problem; however, that MAY not be possible
+and is not required.
+
+Conflicts are most likely to occur in response to a PUT request. If
+versioning is being used and the entity being PUT includes changes to a
+resource which conflict with those made by an earlier (third-party)
+request, the server MAY use the 409 response to indicate that it can't
+complete the request. In this case, the response entity SHOULD contain a
+list of the differences between the two versions in a format defined by
+the response Content-Type.
+
+
+12.4.1.11 410 Gone
+The requested resource is no longer available at the server and no
+forwarding address is known. This condition SHOULD be considered
+permanent. Clients with link editing capabilities SHOULD delete
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+references to the Request-URI after user approval. If the server does
+not know, or has no facility to determine, whether or not the condition
+is permanent, the status code 404 (Not Found) SHOULD be used instead.
+This response is cachable unless indicated otherwise.
+
+The 410 response is primarily intended to assist the task of web
+maintenance by notifying the recipient that the resource is
+intentionally unavailable and that the server owners desire that remote
+links to that resource be removed. Such an event is common for limited-
+time, promotional services and for resources belonging to individuals no
+longer working at the server's site. It is not necessary to mark all
+permanently unavailable resources as "gone" or to keep the mark for any
+length of time -- that is left to the discretion of the server owner.
+
+
+12.4.1.12 411 Length Required
+The server refuses to accept the request without a defined Content-
+Length. The client MAY repeat the request if it adds a valid Content-
+Length header field containing the length of the entity body in the
+request message.
+
+
+12.4.1.13 412 Precondition Failed
+The precondition given in one or more of the request header fields
+evaluated to false when it was tested on the server. This response code
+allows the client to place preconditions on the current resource
+metainformation (header field data) and thus prevent the requested
+method from being applied to a resource other than the one intended.
+
+
+12.4.1.14 413 Request Entity Too Large
+The server is refusing to process a request because it considers the
+request entity to be larger than it is willing or able to process. The
+server SHOULD close the connection if that is necessary to prevent the
+client from continuing the request.
+
+If the client manages to read the 413 response, it MUST honor it and
+SHOULD reflect it to the user.
+
+If this restriction is considered temporary, the server MAY include a
+Retry-After header field to indicate that it is temporary and after what
+time the client MAY try again.
+
+
+12.4.1.15 414 Request-URI Too Long
+The server is refusing to service the request because the Request-URI is
+longer than the server is willing to interpret. This rare condition is
+only likely to occur when a client has improperly converted a POST
+request to a GET request with long query information, when the client
+has descended into a URL "black hole" of redirection (e.g., a redirected
+URL prefix that points to a suffix of itself), or when the server is
+under attack by a client attempting to exploit security holes present in
+some servers using fixed-length buffers for reading or manipulating the
+Request-URI.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.4.1.16 415 Unsupported Media Type
+The server is refusing to service the request because the entity body of
+the request is in a format not supported by the requested resource for
+the requested method.
+
+
+12.5 Server Error 5xx
+Response status codes beginning with the digit "5" indicate cases in
+which the server is aware that it has erred or is incapable of
+performing the request. If the client has not completed the request when
+a 5xx code is received, it SHOULD immediately cease sending data to the
+server. Except when responding to a HEAD request, the server SHOULD
+include an entity containing an explanation of the error situation, and
+whether it is a temporary or permanent condition. These response codes
+are applicable to any request method and there are no required header
+fields.
+
+
+12.5.1.1 500 Internal Server Error
+The server encountered an unexpected condition which prevented it from
+fulfilling the request.
+
+
+12.5.1.2 501 Not Implemented
+The server does not support the functionality required to fulfill the
+request. This is the appropriate response when the server does not
+recognize the request method and is not capable of supporting it for any
+resource.
+
+
+12.5.1.3 502 Bad Gateway
+The server, while acting as a gateway or proxy, received an invalid
+response from the upstream server it accessed in attempting to fulfill
+the request.
+
+
+12.5.1.4 503 Service Unavailable
+The server is currently unable to handle the request due to a temporary
+overloading or maintenance of the server. The implication is that this
+is a temporary condition which will be alleviated after some delay. If
+known, the length of the delay MAY be indicated in a Retry-After
+header.
+If no Retry-After is given, the client SHOULD handle the response as it
+would for a 500 response.
+
+ Note: The existence of the 503 status code does not imply that a
+ server must use it when becoming overloaded. Some servers MAY wish
+ to simply refuse the connection.
+
+
+12.5.1.5 504 Gateway Timeout
+The server, while acting as a gateway or proxy, did not receive a timely
+response from the upstream server it accessed in attempting to complete
+the request.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 49]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+12.5.1.6 505 HTTP Version Not Supported
+The server does not support, or refuses to support, the HTTP protocol
+version that was used in the request message. The server is indicating
+that it is unable or unwilling to complete the request using the same
+major version as the client, as described in section 7.1, other than
+with this error message. The response SHOULD contain an entity
+describing why that version is not supported and what other protocols
+are supported by that server.
+
+
+13 Method Definitions
+The set of common methods for HTTP/1.1 is defined below. Although this
+set can be expanded, additional methods cannot be assumed to share the
+same semantics for separately extended clients and servers.
+
+The Host request-header field (section 18.24) MUST accompany all
+HTTP/1.1 requests.
+
+
+13.1 OPTIONS
+The OPTIONS method represents a request for information about the
+communication options available on the request/response chain identified
+by the Request-URI. This method allows the client to determine the
+options and/or requirements associated with a resource, or the
+capabilities of a server, without implying a resource action or
+initiating a resource retrieval.
+
+Unless the server's response is an error, the response MUST NOT include
+entity information other than what can be considered as communication
+options (e.g., Allow is appropriate, but Content-Type is not) and MUST
+include a Content-Length with a value of zero (0). Responses to this
+method are not cachable.
+
+If the Request-URI is an asterisk ("*"), the OPTIONS request is intended
+to apply to the server as a whole. A 200 response SHOULD include any
+header fields which indicate optional features implemented by the server
+(e.g., Public), including any extensions not defined by this
+specification, in addition to any applicable general or response header
+fields. As described in section 9.1.2, an "OPTIONS *" request can be
+applied through a proxy by specifying the destination server in the
+Request-URI without any path information.
+
+If the Request-URI is not an asterisk, the OPTIONS request applies only
+to the options that are available when communicating with that
+resource.
+A 200 response SHOULD include any header fields which indicate optional
+features implemented by the server and applicable to that resource
+(e.g., Allow), including any extensions not defined by this
+specification, in addition to any applicable general or response header
+fields. If the OPTIONS request passes through a proxy, the proxy MUST
+edit the response to exclude those options known to be unavailable
+through that proxy.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 50]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+13.2 GET
+The GET method means retrieve whatever information (in the form of an
+entity) is identified by the Request-URI. If the Request-URI refers to a
+data-producing process, it is the produced data which shall be returned
+as the entity in the response and not the source text of the process,
+unless that text happens to be the output of the process.
+
+The semantics of the GET method change to a "conditional GET" if the
+request message includes an If-Modified-Since header field. A
+conditional GET method requests that the identified resource entity be
+transferred only if it has been modified since the date given by the
+If-
+Modified-Since header, as described in section 18.25. The conditional
+GET method is intended to reduce unnecessary network usage by allowing
+cached entities to be refreshed without requiring multiple requests or
+transferring data already held by the client.
+
+The semantics of the GET method change to a "partial GET" if the request
+message includes a Range header field. A partial GET requests that only
+part of the identified resource entity be transferred, as described in
+section 18.38. The partial GET method is intended to reduce unnecessary
+network usage by allowing partially-retrieved entities to be completed
+without transferring data already held by the client.
+
+The response to a GET request may be cachable if and only if it meets
+the requirements for HTTP caching described in section 16.
+
+
+13.3 HEAD
+The HEAD method is identical to GET except that the server MUST NOT
+return any Entity-Body in the response. The metainformation contained in
+the HTTP headers in response to a HEAD request SHOULD be identical to
+the information sent in response to a GET request. This method can be
+used for obtaining metainformation about the resource entity identified
+by the Request-URI without transferring the Entity-Body itself. This
+method is often used for testing hypertext links for validity,
+accessibility, and recent modification.
+
+The response to a HEAD request may be cachable in the sense that the
+information contained in the response may be used to update a previously
+cached entity from that resource. If the new field values indicate that
+the cached entity differs from the current resource entity (as would be
+indicated by a change in Content-Length, Content-MD5, or Content-
+Version), then the cache MUST mark the cache entry stale.
+
+There is no "conditional HEAD" or "partial HEAD" request analogous to
+those associated with the GET method. If an If-Modified-Since and/or
+Range header field is included with a HEAD request, they SHOULD be
+ignored.
+
+
+13.4 POST
+The POST method is used to request that the destination server accept
+the entity enclosed in the request as a new subordinate of the resource
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 51]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+identified by the Request-URI in the Request-Line. POST is designed to
+allow a uniform method to cover the following functions:
+
+
+ . Annotation of existing resources;
+
+ . Posting a message to a bulletin board, newsgroup, mailing list, or
+ similar group of articles;
+
+ . Providing a block of data, such as the result of submitting a form
+ , to a data-handling process;
+
+ . Extending a database through an append operation.
+The actual function performed by the POST method is determined by the
+server and is usually dependent on the Request-URI. The posted entity is
+subordinate to that URI in the same way that a file is subordinate to a
+directory containing it, a news article is subordinate to a newsgroup to
+which it is posted, or a record is subordinate to a database.
+
+For compatibility with HTTP/1.0 applications, all POST requests MUST
+include a valid Content-Length header field unless the server is known
+to be HTTP/1.1 compliant. When sending a POST request to an HTTP/1.1
+server, a client MUST use a valid Content-Length or the "chunked"
+Transfer-Encoding. The server SHOULD respond with a 400 (bad request)
+message if it cannot determine the length of the request message's
+content, or with 411 (length required) if it wishes to insist on
+receiving a valid Content-Length.
+
+A successful POST does not require that the entity be created as a
+resource on the origin server or made accessible for future reference.
+That is, the action performed by the POST method might not result in a
+resource that can be identified by a URI. In this case, either 200 (OK)
+or 204 (no content) is the appropriate response status, depending on
+whether or not the response includes an entity that describes the
+result.
+
+If a resource has been created on the origin server, the response SHOULD
+be 201 (Created) and contain an entity (preferably of type "text/html")
+which describes the status of the request and refers to the new
+resource.
+
+Responses to this method are not cachable. However, the 303 (See Other)
+response can be used to direct the user agent to retrieve a cachable
+resource.
+
+POST requests must obey the entity transmission requirements set out in
+section 13.4.1.
+
+
+13.4.1 SLUSHY: Entity Transmission Requirements
+Editor's Note: The issues here around reliable transmission of large
+entities to servers, particularly HTTP/1.0 servers, are complicated and
+subtle, particularly since we'd like optimistic transmission to be the
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+normal situation. We would like it if we can redraft this section to be
+simpler in the next draft
+
+General requirements:
+
+ . HTTP/1.1 servers should maintain persistent connections and use
+ TCP's flow control mechanisms to resolve temporary overloads,
+ rather than terminating connections with the expectation that
+ clients will retry. The latter technique can exacerbate network
+ congestion.
+ . An HTTP/1.1 (or later) client doing a PUT-like method SHOULD
+ monitor the network connection for an error status while it is
+ transmitting the request. If the client sees an error status, it
+ should immediately cease transmitting the body. If the body is
+ being sent using a "Chunked" encoding, a zero length chunk is used
+ to mark the end of the message. If the body was preceded by a
+ Content-length header, the client MUST close the connection.
+ . An HTTP/1.1 (or later) client MUST be prepared to accept a "100
+ Continue" status followed by a regular response.
+ . An HTTP/1.1 (or later) server that receives a request from a
+ HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
+ response; it SHOULD either wait for the request to be completed
+ normally (thus avoiding an interrupted request) or close the
+ connection prematurely.
+Upon receiving a method subject to these requirements from an HTTP/1.1
+(or later) client, an HTTP/1.1 (or later) server MUST either immediately
+respondwith 100 (continue) and continue to read from the input stream,
+or respond with an error status. If it responds with an error status,
+it MAY close the transport (TCP) connection or it MAY continue to read
+and discard the rest of the request. It MUST NOT perform the requested
+method if it returns an error status.
+
+If an HTTP/1.1 client has seen an HTTP/1.1 or later response from the
+server (clients SHOULD remember the version number of at least the most
+recently used server), and it sees the connection close before receiving
+any status from the server, the client SHOULD retry the request. If the
+client does retry the request,
+
+ . it MUST first send the request headers,
+ . and then MUST wait for the server to respond with either a 100
+ (continue) response, in which case the client should continue, or
+ with an error status.
+If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
+the server, it should assume that the server implements HTTP/1.0 or
+older and will not use the 100 (Continue) response. If in this case the
+client sees the connection close before receiving any status from the
+server, the client SHOULD retry the request. If the client does retry
+the request, it should use the following "binary exponential backoff"
+algorithm to be assured of obtaining a reliable response:
+
+ 1.
+ Initiate a new connection to the server
+ 2.
+ Transmit the request headers
+ 3.
+ Initialize a variable R to the estimated round-trip time to the
+ server (e.g., based on the time it took to establish the
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ connection), or to a constant value of 5 seconds if the round-trip
+ time is not available.
+ 4.
+ Compute T = R * (2**N), where N is the number of previous retries
+ of this request.
+ 5.
+ Wait either for an error response from the server, or for T seconds
+ (whichever comes first)
+ 6.
+ If no error response is received, after T seconds transmit the body
+ of the request.
+ 7.
+ If client sees that the connection is closed prematurely, repeat
+ from step 1 until the request is accepted, an error response is
+ received, or the user becomes impatient.
+No matter what the server version, if an error status is received,
+
+ . the client MUST NOT continue and
+ . MUST close the connection if it has not already completed sending
+ the full request body including any encoding mechanism used to
+ transmit the body.
+An HTTP/1.1 (or later) client that sees the connection close after
+receiving a 100 (continue) but before receiving any other status SHOULD
+retry the request, and need not wait for 100 (continue) response (but
+MAY do so if this simplifies the implementation).
+
+
+13.5 PUT
+The PUT method requests that the enclosed entity be stored under the
+supplied Request-URI. If the Request-URI refers to an already existing
+resource, the enclosed entity SHOULD be considered as a modified version
+of the one residing on the origin server. If the Request-URI does not
+point to an existing resource, and that URI is capable of being defined
+as a new resource by the requesting user agent, the origin server can
+create the resource with that URI. If a new resource is created, the
+origin server MUST inform the user agent via the 201 (created)
+response.
+If an existing resource is modified, either the 200 (OK) or 204 (No
+Content) response codes SHOULD be sent to indicate successful completion
+of the request. If the resource could not be created or modified with
+the Request-URI, an appropriate error response SHOULD be given that
+reflects the nature of the problem.
+
+If the request passes through a cache and the Request-URI identifies a
+currently cached entity, that entity MUST be removed from the cache.
+Responses to this method are not cachable.
+
+The fundamental difference between the POST and PUT requests is
+reflected in the different meaning of the Request-URI. The URI in a POST
+request identifies the resource that will handle the enclosed entity as
+an appendage. That resource may be a data-accepting process, a gateway
+to some other protocol, or a separate entity that accepts annotations.
+In contrast, the URI in a PUT request identifies the entity enclosed
+with the request -- the user agent knows what URI is intended and the
+server MUST NOT attempt to apply the request to some other resource. If
+the server desires that the request be applied to a different URI, it
+MUST send a 301 (Moved Permanently) response; the user agent MAY then
+make its own decision regarding whether or not to redirect the request.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 54]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+A single resource MAY be identified by many different URIs. For
+example,
+an article may have a URI for identifying "the current version" which is
+separate from the URI identifying each particular version. In this
+case,
+a PUT request on a general URI may result in several other URIs being
+defined by the origin server.
+
+For compatibility with HTTP/1.0 applications, all PUT requests MUST
+include a valid Content-Length header field unless the server is known
+to be HTTP/1.1 compliant. When sending a PUT request to an HTTP/1.1
+server, a client MUST use a valid Content-Length or the "chunked"
+Transfer-Encoding. The server SHOULD respond with a 400 (bad request)
+message if it cannot determine the length of the request message's
+content, or with 411 (length required) if it wishes to insist on
+receiving a valid Content-Length.
+
+The actual method for determining how the resource entity is placed, and
+what happens to its predecessor, is defined entirely by the origin
+server.
+
+PUT requests must obey the entity transmission requirements set out in
+section 13.4.1.
+
+
+13.6 DELETE
+The DELETE method requests that the origin server delete the resource
+identified by the Request-URI. This method MAY be overridden by human
+intervention (or other means) on the origin server. The client cannot be
+guaranteed that the operation has been carried out, even if the status
+code returned from the origin server indicates that the action has been
+completed successfully. However, the server SHOULD not indicate success
+unless, at the time the response is given, it intends to delete the
+resource or move it to an inaccessible location.
+
+A successful response SHOULD be 200 (OK) if the response includes an
+entity describing the status, 202 (Accepted) if the action has not yet
+been enacted, or 204 (No Content) if the response is OK but does not
+include an entity.
+
+If the request passes through a cache and the Request-URI identifies a
+currently cached entity, that entity MUST be removed from the cache.
+Responses to this method are not cachable.
+
+
+13.7 TRACE
+The TRACE method is used to invoke a remote, application-layer
+loop-back
+of the request message. The final recipient of the request SHOULD
+reflect the message received back to the client as the entity body of a
+200 (OK) response. The final recipient is either the origin server or
+the first proxy or gateway to receive a Max-Forwards value of zero (0)
+in the request (see section 18.32). A TRACE request MUST NOT include an
+entity.
+
+TRACE allows the client to see what is being received at the other end
+of the request chain and use that data for testing or diagnostic
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 55]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+information. The value of the Via header field (section 18.47) is of
+particular interest, since it acts as a trace of the request chain. Use
+of the Max-Forwards header field allows the client to limit the length
+of the request chain, which is useful for testing a chain of proxies
+forwarding messages in an infinite loop.
+
+If successful, the response SHOULD contain the entire request message in
+the entity body, with a Content-Type of "message/http",
+"application/http", or "text/plain". Responses to this method MUST NOT
+be cached.
+
+
+14 Access Authentication
+HTTP provides a simple challenge-response authentication mechanism which
+MAY be used by a server to challenge a client request and by a client to
+provide authentication information. It uses an extensible, case-
+insensitive token to identify the authentication scheme, followed by a
+comma-separated list of attribute-value pairs which carry the parameters
+necessary for achieving authentication via that scheme.
+
+ auth-scheme = token
+
+ auth-param = token "=" quoted-string
+
+The 401 (Unauthorized) response message is used by an origin server to
+challenge the authorization of a user agent. This response MUST include
+a WWW-Authenticate header field containing at least one challenge
+applicable to the requested resource.
+
+ challenge = auth-scheme 1*SP realm *( "," auth-param )
+
+ realm = "realm" "=" realm-value
+ realm-value = quoted-string
+
+The realm attribute (case-insensitive) is required for all
+authentication schemes which issue a challenge. The realm value (case-
+sensitive), in combination with the canonical root URL of the server
+being accessed, defines the protection space. These realms allow the
+protected resources on a server to be partitioned into a set of
+protection spaces, each with its own authentication scheme and/or
+authorization database. The realm value is a string, generally assigned
+by the origin server, which may have additional semantics specific to
+the authentication scheme.
+
+A user agent that wishes to authenticate itself with a server--usually,
+but not necessarily, after receiving a 401 or 411 response--MAY do so by
+including an Authorization header field with the request. The
+Authorization field value consists of credentials containing the
+authentication information of the user agent for the realm of the
+resource being requested.
+
+ credentials = basic-credentials
+ | auth-scheme 0#auth-param
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The domain over which credentials can be automatically applied by a user
+agent is determined by the protection space. If a prior request has been
+authorized, the same credentials MAY be reused for all other requests
+within that protection space for a period of time determined by the
+authentication scheme, parameters, and/or user preference. Unless
+otherwise defined by the authentication scheme, a single protection
+space cannot extend outside the scope of its server.
+
+If the server does not wish to accept the credentials sent with a
+request, it SHOULD return a 401 (Unauthorized) response. The response
+MUST include a WWW-Authenticate header field containing the (possibly
+new) challenge applicable to the requested resource and an entity
+explaining the refusal.
+
+The HTTP protocol does not restrict applications to this simple
+challenge-response mechanism for access authentication. Additional
+mechanisms MAY be used, such as encryption at the transport level or via
+message encapsulation, and with additional header fields specifying
+authentication information. However, these additional mechanisms are not
+defined by this specification.
+
+Proxies MUST be completely transparent regarding user agent
+authentication. That is, they MUST forward the WWW-Authenticate and
+Authorization headers untouched, and MUST NOT cache the response to a
+request containing Authorization.
+
+HTTP/1.1 allows a client to pass authentication information to and from
+a proxy via the Proxy-Authenticate and Proxy-Authorization headers.
+
+
+14.1 Basic Authentication Scheme
+The "basic" authentication scheme is based on the model that the user
+agent must authenticate itself with a user-ID and a password for each
+realm. The realm value should be considered an opaque string which can
+only be compared for equality with other realms on that server. The
+server will service the request only if it can validate the user-ID and
+password for the protection space of the Request-URI. There are no
+optional authentication parameters.
+
+Upon receipt of an unauthorized request for a URI within the protection
+space, the server SHOULD respond with a challenge like the following:
+
+ WWW-Authenticate: Basic realm="WallyWorld"
+
+where "WallyWorld" is the string assigned by the server to identify the
+protection space of the Request-URI.
+
+To receive authorization, the client sends the user-ID and password,
+separated by a single colon (":") character, within a base64 encoded
+string in the credentials.
+
+ basic-credentials = "Basic" SP basic-cookie
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 57]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ basic-cookie = <base64 [7] encoding of user-pass,
+ except not limited to 76 char/line>
+
+ user-pass = userid ":" password
+
+ userid = [ token ]
+
+ password = *TEXT
+
+If the user agent wishes to send the user-ID "Aladdin" and password
+"open sesame", it would use the following header field:
+
+ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+
+The basic authentication scheme is a non-secure method of filtering
+unauthorized access to resources on an HTTP server. It is based on the
+assumption that the connection between the client and the server can be
+regarded as a trusted carrier. As this is not generally true on an open
+network, the basic authentication scheme should be used accordingly. In
+spite of this, clients SHOULD implement the scheme in order to
+communicate with servers that use it.
+
+
+14.2 Digest Authentication Scheme
+The "digest" authentication scheme is [currently described in an expired
+Internet-Draft, and this description will have to be improved to
+reference a new draft or include the old one].
+
+
+15 Content Negotiation
+A generic resource has multiple entities associated with it, all of
+which are representations of the content of the resource. Content
+negotiation is the process of selecting the best representation when a
+GET or HEAD request is made on the generic resource. HTTP/1.1 has
+provisions for two kinds of content negotiation: opaque negotiation and
+transparent negotiation.
+
+With opaque negotiation, the selection of the best representation is
+done by an algorithm located at the origin server, and unknown to the
+proxies and user agents involved. Selection is based on the contents of
+particular header fields in the request message, or on other information
+pertaining to the request, like the network address of the sending
+client. A typical example of opaque negotiation would be the selection
+of a text/html response in a particular language based on the contents
+of the Accept-Language request header field. A disadvantage of opaque
+negotiation is that the request headers may not always contain enough
+information to allow for selection. If the Accept header
+
+ Accept: text/*: q=0.3, text/html, */*: q=0.5
+
+is sent in a request on a generic resource which has a video/mpeg and a
+video/quicktime representation, the selection algorithm in the origin
+server will either have to make a default choice, or return an error
+response which allows the user to decide on further actions.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 58]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+With transparent negotiation, the selection of the best representation
+is done by a distributed algorithm which can perform computation steps
+in the origin server, in proxies, or in the user agent. Transparent
+negotiation guarantees that, if the user agent supports the transparent
+negotiation algorithm and is correctly configured, the request will
+always correctly yield either the video/mpeg representation, the
+video/quicktime representation, or an error message indicating that the
+resource cannot be displayed by the user agent.
+
+
+15.1 Negotiation Facilities Defined in this Specification
+This specification defines all protocol facilities for opaque
+negotiation, but does not define the distributed algorithm for
+transparent negotiation. This specification only defines the basic
+facilities (Vary, Alternates, Accept) in the core protocol allowing
+requests on transparently negotiated resources to be correctly handled
+by HTTP/1.1 caches. All other information about transparent content
+negotiation is found in a separate document[29].
+
+If a generic resource is opaquely negotiated, successful responses to
+requests on the resource will always include a Vary header. If a
+generic resource is transparently negotiated, successful responses to
+requests on the resource will always include an Alternates header. If a
+successful response contains an Alternates header, it will also always
+contain a Content-Location header. A future specification may allow a
+combination of opaque and transparent negotiation that would lead to the
+inclusion of both a Vary header and an Alternates header in a response.
+
+
+16 Caching in HTTP
+The World Wide Web is a distributed system, and so its performance can
+be improved by the use of caches. These caches are typically placed at
+proxies and in the clients themselves. The HTTP/1.1 protocol includes a
+number of elements intended to make caching work as well as possible.
+Because these elements are inextricable from other aspects of the
+protocol, and because they interact with each other, it is useful to
+describe the basic caching design of HTTP separately from the detailed
+descriptions of methods, headers, response codes, etc.
+
+
+16.1 Semantic Transparency
+Requirements for performance, availability, and disconnected operation
+require us to be able to relax the goal of semantic transparency. The
+HTTP/1.1 protocol allows origin servers, caches, and clients to
+explicitly reduce transparency when necessary. However, because non-
+transparent operation may confuse non-expert users, and may be
+incompatible with certain server applications (such as those for
+ordering merchandise), the protocol requires that transparency may not
+be relaxed
+
+ . without an explicit protocol-level request (when relaxed by client
+ or origin server)
+ . without a means for warning the end user (when relaxed by cache or
+ client)
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 59]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Therefore, the HTTP/1.1 protocol provides these important elements:
+
+ 1. Protocol features that provide full semantic transparency when this
+ is desired by all parties.
+ 2. Protocol features that allow an origin server or end-user client to
+ explicitly request and control non-transparent operation.
+ 3. Protocol features that allow a cache to attach warnings to
+ responses that do not preserve semantic transparency.
+A basic principle is that it must be possible for the clients to detect
+any potential breakdown of semantic transparency.
+
+Caching would be useless if it did not significantly improve
+performance. The goal of caching in HTTP/1.1 is to eliminate the need to
+send requests in many cases, and to eliminate the need to send full
+responses in many other cases. The former reduces the number of network
+round-trips required for many operations; we use an "expiration"
+mechanism for this purpose (see section 16.1.2). The latter reduces
+network bandwidth requirements; we use a "validation" mechanism for this
+purpose (see section 13.3).
+
+The server, cache, or client implementer may be faced with design
+decisions not explicitly discussed in this specification. If a decision
+may affect semantic transparency, the implementer ought to err on the
+side of maintaining transparency unless a careful and complete analysis
+shows significant benefits in breaking transparency.
+
+
+16.1.1 Cache Correctness
+If the cache can communicate with the origin-server, then a correct
+cache MUST respond to a request with a response that meets all the
+following conditions:
+
+ 1. its end-to-end headers (see section 16.4.1) and entity-body value
+ are equivalent to what the server would have returned for that
+ request if the resource had not been modified since the response
+ was cached. This may be accomplished by revalidating the response
+ with the origin server, if is not fresh.
+ 2. it is "fresh enough" (see section 16.1.2). In the default case,
+ this means it meets the least restrictive freshness requirement of
+ the client, server, and cache (see section 18.10); if the origin-
+ server so specifies, it is the freshness requirement of the
+origin-
+ server alone.
+ 3. it includes a warning if the freshness demand of the client or the
+ origin-server is violated (see section 16.1.5 and 18.48).
+ 4. it is the most up-to-date response appropriate to the request the
+ cache has seen (see section 16.2.6, 16.2.8, and 16.13).
+If the cache can not communicate with the origin server, then a correct
+cache SHOULD respond as above if the response can be correctly served
+from the cache; if not it MUST return an error or warning indicating
+that there was a communication.
+
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 60]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+16.1.2 Cache-control Mechanisms
+The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+times and validators) are implicit directives to caches. In some cases,
+a server or client may need to provide explicit directives to the HTTP
+caches. We use the Cache-Control header for this purpose.
+
+The Cache-Control header allows a client or server to transmit a variety
+of directives in either requests or responses. These directives
+typically override the default caching algorithms. As a general rule, if
+there is any apparent conflict between header values, the most
+restrictive interpretation should be applied (that is, the one that is
+most likely to preserve semantic transparency). However, in some cases,
+Cache-Control directives are explicitly specified as weakening semantic
+transparency (for example, "max-stale" or "public").
+
+The Cache-Control directives are described in detail in section 18.10.
+
+
+16.1.3 Warnings
+Whenever a cache returns a response that is not semantically
+transparent, it must attach a warning to that effect, using a Warning
+response header. This warning allows clients and user agents to take
+appropriate action.
+
+Warnings may be used for other purposes, both cache-related and
+otherwise. The use of a warning, rather than an error status code,
+distinguish these responses from true failures.
+
+Warnings are always cachable, because they never weaken the transparency
+of a response. This means that warnings can be passed to HTTP/1.0 caches
+without danger; such caches will simply pass the warning along as a
+entity header in the response.
+
+Warnings are assigned numbers between 0 and 99. This specification
+defines the code numbers and meanings of each warning, allowing a client
+or cache to take automated action in some (but not all) cases.
+
+Warnings also carry a warning message text in any appropriate natural
+language (perhaps based on the client's Accept headers), and an optional
+indication of what language and character set are used.
+
+Multiple warning messages may be attached to a response (either by the
+origin server or by a cache), including multiple warnings with the same
+code number. For example, a server may provide the same warning with
+texts in both English and Basque.
+
+When multiple warnings are attached to a response, it may not be
+practical or reasonable to display all of them to the user. This version
+of HTTP does not specify strict priority rules for deciding which
+warnings to display and in what order, but does suggest some
+heuristics.
+
+The Warning header and the currently defined warnings are described in
+section 18.48.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+16.1.4 Explicit User Agent Warnings
+Many user agents make it possible for users to override the basic
+caching mechanisms. For example, the user agent may allow the user to
+specify that cached entities (even explicitly stale ones) are never
+validated. Or the user agent might habitually add "Cache-Control: max-
+stale=3600" or "Cache-Control: reload" to every request. We recognize
+that there may be situations which require such overrides, although user
+agents SHOULD NOT default to any behavior contrary to the HTTP/1.1
+specification. That is, the user should have to explicitly request
+either non-transparent behavior, or behavior that results in abnormally
+ineffective caching.
+
+If the user has overridden the basic caching mechanisms, the user agent
+should explicitly indicate to the user whenever this results in the
+display of information that might not meet the server's transparency
+requirements (in particular, if the displayed entity is known to be
+stale). Since the protocol normally allows the user agent to determine
+if responses are stale or not, this indication need only be displayed
+when this actually happens. The indication need not be a dialog box; it
+could be an icon (for example, a picture of a rotting fish) or some
+other visual indicator.
+
+If the user has overridden the caching mechanisms in a way that would
+abnormally reduce the effectiveness of caches, the user agent should
+continually display an indication (for example, a picture of currency in
+flames) so that the user does not inadvertently consume excess resources
+or suffer from excessive latency.
+
+
+16.1.5 Exceptions to the Rules and Warnings
+In some cases, the operator of a cache may choose to configure it to
+return stale responses even when not requested by clients. This decision
+not be made lightly, but may be necessary for reasons of availability or
+performance, especially when the cache is poorly connected to the origin
+server. Whenever a cache returns a stale response, it MUST mark it as
+such (using a Warning header). This allows the client software to alert
+the user that there may be a potential problem.
+
+It also allows the user to take steps to obtain a firsthand or fresh
+response, if the user so desires. For this reason, a cache MUST NOT
+return a stale response if the client explicitly requests a first-hand
+or fresh one, unless it is impossible to comply.
+
+
+16.1.6 Client-controlled Behavior
+While the origin server (and to a lesser extent, intermediate caches, by
+their contribution to the age of a response) are the primary source of
+expiration information, in some cases the client may need to control a
+cache's decision about whether to return a cached response without
+validating it. Clients do this using several directives of the Cache-
+Control header.
+
+A client's request may specify the maximum age it is willing to accept
+for an unvalidated response; specifying a value of zero forces the
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+cache(s) to revalidate all responses. A client may also specify the
+minimum time remaining before a response expires. Both of these options
+increase constraints on the behavior of caches, and so cannot decrease
+semantic transparency.
+
+A client may also specify that it will accept stale responses, up to
+some maximum amount of staleness. This loosens the constraints on the
+caches, and so may violate semantic transparency, but may be necessary
+to support disconnected operation, or high availability in the face of
+poor connectivity.
+
+
+16.2 Expiration Model
+
+16.2.1 Server-Specified Expiration
+HTTP caching works best when caches can entirely avoid making requests
+to the origin server. The primary mechanism for avoiding requests is for
+an origin server to provide an explicit expiration time in the future,
+indicating that a response may be used to satisfy subsequent requests.
+In other words, a cache can return a fresh response without first
+contacting the server.
+
+Our expectation is that servers will assign future explicit expiration
+times to responses in the belief that the entity is not likely to
+change, in a semantically significant way, before the expiration time is
+reached. This normally preserves semantic transparency, as long as the
+server's expiration times are carefully chosen.
+
+If an origin server wishes to force a semantically transparent cache to
+validate every request, it may assign an explicit expiration time in the
+past. This means that the response is always stale, and so the cache
+SHOULD validate it before using it for subsequent requests. (See
+section 18.10.4 for a more restrictive way to force revalidation).
+
+ Note that a firsthand response MUST always be returned to the
+ requesting client, independent of its expiration time, unless the
+ connection to the client is lost.
+
+If an origin server wishes to force any HTTP/1.1 cache, no matter how it
+is configured, to validate every request, it should use the "must-
+revalidate" Cache-Control directive. See section 18.10.
+
+Servers specify explicit expiration times using either the Expires
+header, or the max-age directive of the Cache-Control header.
+
+
+16.2.2 Limitations on the Effect of Expiration Times
+An expiration time cannot be used to force a user agent to refresh its
+display or reload a resource entity; its semantics apply only to caching
+mechanisms, and such mechanisms need only check a resource's expiration
+status when a new request for that resource is initiated.
+
+User agents often have history mechanisms, such as "Back" buttons and
+history lists, which can be used to redisplay an entity retrieved
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 63]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+earlier in a session. By default, an expiration time does not apply to
+history mechanisms. If the entity is still in storage, a history
+mechanism should display it even if the entity has expired, unless the
+user has specifically configured the agent to refresh expired history
+documents.
+
+
+16.2.3 Heuristic Expiration
+Since origin servers do not always provide explicit expiration times,
+HTTP caches typically assign heuristic expiration times, employing
+algorithms that use other header values (such as the Last-Modified
+time)
+to estimate a plausible expiration time. The HTTP/1.1 specification does
+not provide specific algorithms, but does impose worst-case constraints
+on their results. Since heuristic expiration times may compromise
+semantic transparency, they should be used cautiously, and we encourage
+origin servers to provide explicit expiration times as much as
+possible.
+
+
+16.2.4 Age Calculations
+In order to know if a cached entry is fresh, a cache needs to know if
+its age exceeds its freshness lifetime. We discuss how to calculate the
+latter in section 0; this section describes how to calculate the age of
+a response or cache entry.
+
+In this discussion, we use the term "now" to mean "the current value of
+the clock at the host performing the calculation." All HTTP
+implementations, but especially origin servers and caches, should use
+NTP [RFC1305] or some similar protocol to synchronize their clocks to a
+globally accurate time standard.
+
+Also note that HTTP/1.1 requires origin servers to send a Date header
+with every response, giving the time at which the response was
+generated. We use the term "date_value" to denote a representation of
+the value of the Date header, in a form appropriate for arithmetic
+operations.
+
+HTTP/1.1 uses the "Age" response header to help convey age information
+between caches. The Age header value is the sender's estimate of the
+amount of time since the response was generated at the origin server. In
+the case of a cached response that has been revalidated with the origin
+server, the Age value is based on the time of revalidation, not of the
+original response.
+
+In essence, the Age value is the sum of the time that the response has
+been resident in each of the caches along the path from the origin
+server, plus the amount of time it has been in transit along network
+paths.
+
+We use the term "age_value" to denote a representation of the value of
+the Age header, in a form appropriate for arithmetic operations.
+
+An response's age can be calculated in two entirely independent ways:
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ 1. now - date_value, if the local clock is reasonably well
+ synchronized to the origin server's clock. If the result is
+ negative, this is replaced by zero.
+ 2. age_value, if all of the caches along the response path implement
+ HTTP/1.1.
+Given that we have two independent ways to compute the age of a response
+when it is received, we can combine these as
+
+ corrected_received_age = max(now - date_value, age_value)
+
+and as long as we have either nearly synchronized clocks or
+all-HTTP/1.1
+paths, one gets a reliable (conservative) result.
+
+Note that this correction is applied at each HTTP/1.1 cache along the
+path, so that if there is an HTTP/1.0 cache in the path, the correct
+received age is computed as long as the receiving cache's clock is
+nearly in sync. We don't need end-to-end clock synchronization
+(although
+it is good to have), and there is no explicit clock synchronization
+step.
+
+Because of network-imposed delays, some significant interval may pass
+from the time that a server generates a response, and the time it is
+received at the next outbound cache or client. If uncorrected, this
+delay could result in improperly low ages.
+
+Because the request that resulted in the returned Age value must have
+been initiated prior to that Age value's generation, we can correct for
+delays imposed by the network by recording the time at which the request
+was initiated. Then, when an Age value is received, it MUST be
+interpreted relative to the time the request was initiated, not the time
+that the response was received. This algorithm results in conservative
+behavior no matter how much delay is experienced. So, we compute:
+
+ corrected_initial_age = corrected_received_age
+ + (now - request_time)
+
+where "request_time" is the time (according to the local clock) when the
+request that elicited this response was sent.
+
+Summary of age calculation algorithm, when a cache receives a response:
+
+ /*
+ * age_value
+ * is the value of Age: header received by the cache with
+ * this response.
+ * date_value
+ * is the value of the origin server's Date: header
+ * request_time
+ * is the (local) time when the cache made the request
+ * that resulted in this cached response
+ * response_time
+ * is the (local) time when the cache received the
+ * response
+ * now
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ * is the current (local) time
+ */
+ apparent_age = max(0, now - date_value);
+ corrected_received_age = max(apparent_age, age_value);
+ response_delay = now - request_time;
+ corrected_initial_age = corrected_received_age + response_delay;
+ resident_time = now - response_time;
+ current_age = corrected_initial_age + resident_time;
+
+When a cache sends a response, it must add to the corrected_initial_age
+the amount of time that the response was resident locally. It must then
+transmit this total age, using the Age header, to the next recipient
+cache.
+
+ Note that a client can usually tell if a response is firsthand by
+ comparing the Date to its local request-time, and hoping that the
+ clocks are not badly skewed.
+
+
+
+
+16.2.5 Expiration Calculations
+In order to decide whether a response is fresh or stale, we need to
+compare its freshness lifetime to its age. The age is calculated as
+described in section 16.2.4; this section describes how to calculate the
+freshness lifetime, and to determine if a response has expired.
+
+We use the term "expires_value" to denote a representation of the value
+of the Expires header, in a form appropriate for arithmetic operations.
+We use the term "max_age_value" to denote an appropriate representation
+of the number of seconds carried by the max-age directive of the Cache-
+Control header in a response (see section 18.11).
+
+The max-age directive takes priority over Expires, so if max-age is
+present in a response, the calculation is simply:
+
+ freshness_lifetime = max_age_value
+
+Otherwise, if Expires is present in the response, the calculation is:
+
+ freshness_lifetime = expires_value - date_value
+
+Note that neither of these calculations is vulnerable to clock skew,
+since all of the information comes from the origin server.
+
+If neither Expires nor Cache-Control max-age appears in the response,
+and the response does not include other restrictions on caching, the
+cache MAY compute a freshness lifetime using a heuristic. This heuristic
+is subject to certain limitations; the minimum value may be zero, and
+the maximum value MUST be no more than 24 hours.
+
+Also, if the response does have a Last-Modified time, the heuristic
+expiration value SHOULD be no more than some fraction of the interval
+since that time. A typical setting of this fraction might be 10%.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 66]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The calculation to determine if a response has expired is quite simple:
+
+ response_is_fresh = (freshness_lifetime > current_age)
+
+
+16.2.6 Scope of Expiration
+HTTP/1.1's expiration model is that as soon as any variant of a URI
+becomes stale, all variants becomes stale as well. Thus, "freshness"
+applies to all the variants of URI, rather than any particular variant.
+Dates and expires etc. apply to any cached variant that a proxy might
+have with a URI and not just the one particular entity.
+
+Editor's note: This restriction may be dropped in the next draft; there
+are still discussions about whether this restriction is needed.
+
+
+16.2.7 Disambiguating Expiration Values
+Because expiration values are assigned optimistically, it is possible
+that two caches may contain fresh values for the same resource that are
+different.
+
+If a client performing a retrieval receives a non-firsthand response for
+a resource entity that was already fresh in its own cache, and the Date
+header in its existing cache entry is newer than the Date on the new
+response, then the client MAY ignore the response. If so, it MAY retry
+the request with a "Cache-Control: max-age=0" directive (see section
+18.10), to force a check with the origin server.
+
+If a cache that is pooling cached responses from other caches sees two
+fresh responses for the same resource entity with different validators,
+it SHOULD use the one with the newer Date header.
+
+
+16.2.8 Disambiguating Multiple Responses
+Because a client may be receiving responses via multiple paths, so that
+some responses flow through one set of caches and other responses flow
+through a different set of caches, a client may receive responses in an
+order different from that in which the origin server generated them. We
+would like the client to use the most recently generated response, even
+if older responses are still apparently fresh.
+
+Neither the entity tag nor the expiration value can impose an ordering
+on responses, since it is possible that a later response intentionally
+carries an earlier expiration time. However, the HTTP/1.1 specification
+requires the transmission of Date headers on every response, and the
+Date values are ordered to a granularity of one second.
+
+If a client performs a request for a resource entity that it already has
+in its cache, and the response it receives contains a Date header that
+appears to be older than the one it already has in its cache, then the
+client SHOULD repeat the request unconditionally, and include
+
+ Cache-Control: max-age=0
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 67]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+to force any intermediate caches to validate their copies directly with
+the origin server, or
+
+ Cache-Control: no-cache
+
+to force any intermediate caches to obtain a new copy from the origin
+server. This prevents certain paradoxes arising from the use of multiple
+caches.
+
+If the Date values are equal, then the client may use either response
+(or may, if it is being extremely prudent, request a new response).
+Servers MUST NOT depend on clients being able to choose
+deterministically between responses generated during the same second, if
+their expiration times overlap.
+
+
+16.3 Validation Model
+When a cache has a stale entry that it would like to use as a response
+to a client's request, it first has to check with the origin server (or
+possibly an intermediate cache with a fresh response) to see if its
+cached entry is still usable. We call this "validating" the cache
+entry.
+Since we do not want to have to pay the overhead of retransmitting the
+full response if the cached entry is good, and we do not want to pay the
+overhead of an extra round trip if the cached entry is invalid, the
+HTTP/1.1 protocol supports the use of conditional methods.
+
+The key protocol features for supporting conditional methods are those
+concerned with "cache validators." When an origin server generates a
+full response, it attaches some sort of validator to it, which is kept
+with the cache entry. When a client (end-user or cache) makes a
+conditional request for a resource for which it has a cache entry, it
+includes the associated validator in the request.
+
+The server then checks that validator against the current validator for
+the resource entity, and, if they match, it responds with a special
+status code (usually, "304 Not Modified") and no entity body.
+Otherwise,
+it returns a full response (including entity body). Thus, we avoid
+transmitting the full response if the validator matches, and we avoid an
+extra round trip if it does not match.
+
+ Note: the comparison functions used to decide if validators match
+ are defined in section 16.3.3.
+
+In HTTP/1.1, a conditional request looks exactly the same as a normal
+request for the same resource, except that it carries a special header
+(which includes the validator) that implicitly turns the method
+(usually, GET) into a conditional.
+
+The protocol includes both positive and negative senses of cache-
+validating conditions. That is, it is possible to request either that a
+method be performed if and only if the validators match, or if and only
+if the validators do not match.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ Note: a response that lacks a cache validator may still be cached,
+ and served from cache until it expires, unless this is explicitly
+ prohibited by a Cache-Control directive. However, a cache cannot do
+ a conditional retrieval if it does not have a cache validator for
+ the entity, which means it will not be refreshable after it
+ expires.
+
+
+
+
+16.3.1 Last-modified Dates
+In HTTP/1.0, the only cache validator is the Last-Modified time carried
+by a response. Clients validate entities using the If-Modified-Since
+header. In simple terms, a cache entry is considered to be valid if the
+actual resource entity has not been modified since the original response
+was generated.
+
+
+16.3.2 Entity Tags
+HTTP/1.1 introduces the possibility of using an "opaque" validator,
+called an "entity tag," for situations where the Last-Modified date is
+not appropriate. This may include server implementations where it is not
+convenient to store modification dates, or where the one-second
+resolution of HTTP date values is insufficient, or where the origin
+server wishes to avoid certain paradoxes that may arise from the use of
+modification dates.
+
+An entity tag is simply a string of octets whose internal structure is
+not known to clients or caches. Caches store entity tags and return them
+when making conditional requests. Also, when a cache receives a
+conditional request for a resource for which it has a fresh cache
+entry,
+it may compare entity tags using strict octet-equality. Otherwise,
+entity tags have no semantic value to clients or caches.
+
+To preserve compatibility with HTTP/1.0 clients and caches, and because
+the Last-Modified date may be useful for purposes other than cache
+validation, HTTP/1.1 servers SHOULD send Last-Modified whenever
+feasible.
+
+The headers used to convey entity tags are described in sections Error!
+Reference source not found., Error! Reference source not found., 18.26,
+and 18.46.
+
+
+16.3.3 Weak and Strong Validators
+Since both origin servers and caches will compare two validator values
+to decide if they represent the same or different resource entities, one
+normally would expect that if the resource entity (the entity body or
+any entity headers) changes in any way, then the associated validator
+would change as well. If this is true, then we call this validator a
+"strong validator."
+
+However, there may be cases when a server prefers to change the
+validator only on semantically significant changes, and not when
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 69]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+insignificant aspects of the resource entity change. A validator that
+does not always change when the resource changes is a "weak validator."
+
+One can think of a strong validator as one that changes whenever the
+bits of an entity changes, while a weak value changes whenever the
+meaning of an entity changes. Alternatively, one can think of a strong
+validator as part of an identifier for a specific entity, while a weak
+validator is part of an identifier for a set of semantically equivalent
+entities.
+
+ Note: One example of a strong validator is an integer that is
+ incremented in stable storage every time an entity is changed.
+
+ An entity's modification time, if represented with one-second
+ resolution, could be a weak validator, since it is possible that
+ the resource entity may be modified twice during a single second.
+
+Entity tags are normally "strong validators," but the protocol provides
+a mechanism to tag an entity tag as "weak."
+
+A "use" of a validator is either when a client generates a request and
+includes the validator in a validating header field, or when a server
+compares two validators.
+
+Strong validators are usable in any context. Weak validators are only
+usable in contexts that do not depend on exact equality of an entity.
+For example, either kind is usable for a conditional GET of a full
+entity. However, only a strong validator is usable for a sub-range
+retrieval, since otherwise the client may end up with an internally
+inconsistent entity body.
+
+The only function that the HTTP/1.1 protocol defines on validators is
+comparison. There are two validator comparison functions, depending on
+whether the comparison context allows the use of weak validators or
+not:
+
+ . The strong comparison function: in order to be considered equal,
+ both validators must be identical in every way, and neither may be
+ weak.
+ . The weak comparison function: in order to be considered equal, both
+ validators must be identical in every way, but either or both of
+ them may be tagged as "weak" without affecting the result.
+The weak comparison function SHOULD be used for simple (non-subrange)
+GET requests. The strong comparison function MUST be used in all other
+cases.
+
+An entity tag is strong unless it is explicitly tagged as weak. Section
+16.3 gives the syntax for entity tags.
+
+A Last-Modified time, when used as a validator in a request, is
+implicitly weak unless it is possible to deduce that it is strong, using
+the following rules:
+
+ . The validator is being compared by an origin server to the actual
+ current validator for the entity and,
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . That origin server reliably knows that the associated entity did
+ not change twice during the second covered by the presented
+ validator. or
+
+ . The validator is about to be used by a client in an If-Modified-
+ Since or If-Unmodified-Since header, because the client has a cache
+ entry for the associated entity, and
+ . That cache entry includes a Date value, which gives the time when
+ the origin server generated the original response, and
+ . The presented Last-Modified time is at least 60 seconds before the
+ Date value. or
+
+ . The validator is being compared by an intermediate cache to the
+ validator stored in its cache entry for the entity, and
+ . That cache entry includes a Date value, which gives the time when
+ the origin server generated the original response, and
+ . The presented Last-Modified time is at least 60 seconds before the
+ Date value.
+This method relies on the fact that if two different responses were
+generated by the origin server during the same second, but both had the
+same Last-Modified time, then at least one of those responses would have
+a Date value equal to its Last-Modified time. The arbitrary 60-second
+limit guards against the possibility that the Date and Last-Modified
+values are generated from different clocks, or at somewhat different
+times during the preparation of the response. An implementation may use
+a value larger than 60 seconds, if it is believed that 60 seconds is too
+short.
+
+If a client wishes to perform a sub-range retrieval on a value for which
+it has only a Last-Modified time and no opaque validator, it may do this
+only if the Last-Modified time is strong in the sense described here.
+
+A cache or origin server receiving a cache-conditional request, other
+than a full-body GET request, must use the strong comparison function to
+evaluate the condition.
+
+These rules allow HTTP/1.1 caches and clients to safely perform sub-
+range retrievals on values that have been obtained from HTTP/1.0
+servers.
+
+
+16.3.4 Rules for When to Use Entity Tags and Last-modified Dates
+We adopt a set of rules and recommendations for origin servers,
+clients,
+and caches regarding when various validator types should be used, and
+for what purposes.
+
+HTTP/1.1 origin servers:
+
+ . SHOULD send an entity tag validator unless performance
+ considerations support the use of weak entity tags, or unless it is
+ unfeasible to send a strong entity tag.
+ . MAY send a weak entity tag instead of a strong one.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . MAY send no entity tag if it is not feasible to generate one.
+ . SHOULD send a Last-Modified value if it is feasible to send one,
+ unless the risk of a breakdown in semantic transparency that could
+ result from using this date in an If-Modified-Since header would
+ lead to serious problems.
+In other words, the preferred behavior for an HTTP/1.1 origin server is
+to send both a strong entity tag and a Last-Modified value.
+
+In order to be legal, a strong entity tag MUST change whenever the
+associated entity value changes in any way. A weak entity tag SHOULD
+change whenever the associated entity changes in a semantically
+significant way.
+
+ Note: in order to provide semantically transparent caching, an
+ origin server should avoid reusing a specific strong entity tag
+ value for two different resource entities, or reusing a specific
+ weak entity tag value for two semantically different instances of a
+ resource entity. Cache entries may persist for arbitrarily long
+ periods, regardless of expiration times, so it may be inappropriate
+ to expect that a cache will never again attempt to validate an
+ entry using a validator that it obtained at some point in the past.
+
+HTTP/1.1 clients:
+
+ . If an entity tag has been provided by the origin server, MUST use
+ that entity tag in any cache-conditional request (using If-Match or
+ If-NoneMatch).
+ . If only a Last-Modified value has been provided by the origin
+ server, SHOULD use that value in non-subrange cache-conditional
+ requests (using If-Modified-Since).
+ . If only a Last-Modified value has been provided by an HTTP/1.0
+ origin server, MAY use that value in subrange cache-conditional
+ requests (using If-Unmodified-Since:). The user agent should
+ provide a way to disable this, in case of difficulty.
+ . If both an entity tag and a Last-Modified value have been provided
+ by the origin server, SHOULD use both validators in cache-
+ conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches
+ to respond appropriately.
+An HTTP/1.1 cache, upon receiving a request, MUST use the most
+restrictive validator when deciding whether the client's cache entry
+matches the cache's own cache entry. This is only an issue when the
+request contains both an entity tag and a last-modified-date validator
+(If-Modified-Since or If-Unmodified-Since).
+
+ A note on rationale: The general principle behind these rules is
+ that HTTP/1.1 servers and clients should transmit as much non-
+ redundant information as is available in their responses and
+ requests. HTTP/1.1 systems receiving this information will make the
+ most conservative assumptions about the validators they receive.
+
+ HTTP/1.0 clients and caches will ignore entity tags. Generally,
+ last-modified values received or used by these systems will support
+ transparent and efficient caching, and so HTTP/1.1 origin servers
+ should provide Last-Modified values. In those rare cases where the
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 72]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ use of a Last-Modified value as a validator by an HTTP/1.0 system
+ could result in a serious problem, then HTTP/1.1 origin servers
+ should not provide one.
+
+
+16.3.5 Non-validating Conditionals
+The principle behind entity tags is that only the service author knows
+the semantics of a resource well enough to select an appropriate cache
+validation mechanism, and the specification of any validator comparison
+function more complex than byte-equality would open up a can of worms.
+Thus, comparisons of any other headers (except Last-Modified, for
+compatibility with HTTP/1.0) are never used for purposes of validating a
+cache entry.
+
+
+16.4 Constructing Responses From Caches
+The purpose of an HTTP cache is to store information received in
+response to requests, for use in responding to future requests. In many
+cases, a cache simply returns the appropriate parts of a response to the
+requester. However, if the cache holds a cache entry based on a previous
+response, it may have to combine parts of a new response with what is
+held in the cache entry.
+
+
+16.4.1 End-to-end and Hop-by-hop Headers
+For the purpose of defining the behavior of caches and non-caching
+proxies, we divide HTTP headers into two categories:
+
+ . End-to-end headers, which must be transmitted to the ultimate
+ recipient of a request or response. End-to-end headers in responses
+ must be stored as part of a cache entry and transmitted in any
+ response formed from a cache entry.
+ . Hop-by-hop headers, which are meaningful only for a single
+ transport-level connection, and are not stored by caches or
+ forwarded by proxies.
+The following HTTP/1.1 headers are hop-by-hop headers:
+
+ . Connection
+ . Keep-Alive
+ . Upgrade
+ . Public
+ . Proxy-Authenticate
+ . Transfer-Encoding
+All other headers defined by HTTP/1.1 are end-to-end headers.
+
+Hop-by-hop headers introduced in future versions of HTTP MUST be listed
+in a Connection header, as described in section 18.11.
+
+
+16.4.2 Non-modifiable Headers
+Some features of the HTTP/1.1 protocol, such as Digest Authentication,
+depend on the value of certain end-to-end headers. A cache or non-
+caching proxy SHOULD NOT modify an end-to-end header unless the
+definition of that header requires or specifically allows that.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+A cache or non-caching proxy MUST NOT modify any of the following fields
+in a request or response, nor may it add any of these fields if not
+already present:
+
+ . Content-Type
+ . Content-Encoding
+ . Content-Length
+ . Expires
+ . Last-Modified
+ . Content-Range
+ . Content-Location
+ Warning: unnecessary modification of end-to-end headers may cause
+ authentication failures if stronger authentication mechanisms are
+ introduced in later versions of HTTP. Such authentication
+ mechanisms may rely on the values of header fields not listed here.
+
+
+
+
+16.4.3 Combining Headers
+When a cache makes a validating request to a server, and the server
+provides a 304 Not Modified response, the cache must construct a
+response to send to the requesting client. The cache uses the entity-
+body stored in the cache entry as the entity-body of this outgoing
+response. It uses the end-to-end headers from the incoming response, not
+from the cache entry. Unless it decides to remove the cache entry, it
+must also replace the end-to-end headers stored with the cache entry
+with those received in the incoming response.
+
+In other words, the complete set of end-to-end headers received in the
+incoming response overrides all end-to-end headers stored with the cache
+entry. The cache may add Warning headers (see section 18.48) to this
+set.
+
+A cache MUST preserve the order of all headers as received in an
+incoming response.
+
+These rule allows an origin server to completely control the response
+seen by the client of a cache when the cache revalidates an entry, and
+may be necessary for preserving semantic transparency or for certain
+kinds of security mechanisms or future extensions.
+
+
+16.4.4 Combining Byte Ranges
+A response may transfer only a subrange of the bytes of an entity,
+either because the request included one or more Range specifications, or
+because a connection was broken prematurely. After several such
+transfers, a cache may have received several ranges of the same entity.
+
+If a cache has a stored non-empty set of subranges for an entity, and an
+incoming response transfers another subrange, the cache MAY combine the
+new subrange with the existing set if both the following conditions are
+met:
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 74]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . Both the incoming response and the cache entry must have a cache
+ validator.
+ . The two cache validators must match using the strong comparison
+ function (see section 16.3.3).
+If either requirement is not meant, the cache must use only the most
+recent partial response (based on the Date values transmitted with every
+response, and using the incoming response if these values are equal or
+missing), and must discard the other partial information.
+
+
+16.5 Caching and Generic Resources
+Generic resources interacts with caching in several ways:
+
+ . A generic resource (one subject to content negotiation) may be
+ bound to more than one entity. Each of these entities is called a
+ "variant" of the resource.
+ . The request-URI may be only one part of the cache key.
+
+16.5.1 Vary Header Use
+Origin servers may respond to requests for generic resources use the
+Vary header (see section 18.46 for a full description) to inform the
+cache which header fields of the request were used to select the variant
+returned in the response. A cache can use that response to reply to a
+subsequent request only if the two requests not only specify the same
+URI, but also have the same value for all headers specified in the Vary
+response-header.
+
+The Vary header may also inform the cache that the variant was selected
+using criteria not limited to the request headers; in this case, the
+response MUST NOT be used in a reply to a subsequent request except if
+the cache relays the new request to the origin server in a conditional
+request, and the origin server responds with 304 (Not Modified) and
+includes the same variant-ID (see 13.8.3).
+
+
+16.5.2 Alternates Header Use
+The Alternates header is present in the HTTP/1.1 to enable caching of
+entities from the planned content negotiation facilities. If a cache
+receives an Alternates header in a response from the origin server (and
+implement these planned facilities), it should act as if the response
+carried a "Vary:{accept-headers}" header. This means that the response
+may be returned in reply to a subsequent request with Accept-* headers
+identical to those in the current request.
+
+
+16.5.3 Variant-ID Use
+If an origin server chooses to use the variant-ID mechanism, it assigns
+a variant-ID (see section 7.12) to each distinct resource entity
+(variant). This assignment can only be made by the origin server. It
+then returns the appropriate variant-ID with each response that applies
+to a specific resource entity (variant), using the ETag header (see
+Error! Reference source not found.).
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+When sending an entity derived from a particular variant in a response,
+an origin server SHOULD include a variant-ID identifying the variant in
+the ETag header (see section Error! Reference source not found.). This
+variant-ID can be used for cache replacement and in conditional requests
+on the generic resource. When a cache receives a successful response
+with a variant-ID, it SHOULD use this information to replace any
+existing cache entries for the same variant of the corresponding URI.
+That is, it forms a cache key using the URI of the request and the
+variant-ID of the response. If this key matches the key of an existing
+cache entry, it SHOULD replace the existing entry with the new response
+(subject to all of the other rules on caching). See section Error!
+Reference source not found. for more details on update.
+
+When a cache performs a conditional request on a generic resource, and
+it has one or more cache entries for the resource that include variant-
+IDs, the cache MUST transmit the (cache-validator, variant-ID) tuples in
+the conditional request, using the variant-set mechanism (see section
+7.13). This tells the server which variants are currently in the
+requester's cache.
+
+ The client MAY choose to transmit only a subset of the (cache-
+ validator, variant-ID) tuples corresponding to its cache entries
+ for this resource.
+
+When a server receives a conditional request that includes a variant-
+set, and the server is able to reply with an appropriate variant
+(either
+because it is the origin server, or because it is an intermediate cache
+that can properly implement the variant selection algorithm), once it
+has selected the variant it should examine the elements of the supplied
+variant-set. If one of these matches the variant-ID of the selected
+variant, and if the cache validators match, the server SHOULD reply with
+a 304 (Not Modified) response, including the variant-ID of the selected
+variant. Otherwise, the server should reply as if the request were
+unconditional.
+
+The server may optionally use the variant-set information in its
+selection algorithm. For example, if the selection algorithm yields
+several variants with equal preference, and one of these is already in
+the requester's cache, the server could select that variant and avoid an
+extra data transfer. This is a performance optimization; otherwise, the
+variant-selection mechanism is orthogonal to the variant-ID mechanism.
+
+
+16.6 Shared and Non-Shared Caches
+For reasons of security and privacy, it is necessary to make a
+distinction between "shared" and "non-shared" caches. A non-shared cache
+is one that is accessible only to a single user. Accessibility in this
+case SHOULD be enforced by appropriate security mechanisms. All other
+caches are considered to be "shared." Other sections of this
+specification place certain constraints on the operation of shared
+caches in order to prevent loss of privacy or failure of access controls
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+16.7 Selecting a Cached Response
+When a cache receives a request it tries to see if it has a cached
+response appropriate for that request, using the matching rules in this
+section. If such a response exists, then the cache can decide if it is
+fresh enough (using the expiration model in section 16.1.2 and the
+freshness requirements of client and origin-server expressed in the
+Cache-Control headers of the request and cached response) to return in
+reply to the request.
+If on a cache lookup there are two or more fresh entries that appear to
+match the request, then the one with the most recent Date value MUST be
+used.
+16.7.1 Plain Resources
+If the cached response was for a plain resource (that is, the response
+includes no Vary or Alternates headers), it matches if the Request-URI
+of the request matches the Request-URI of the of the request that caused
+the cached response to be stored. Request-URIs match if their canonical
+forms (see section 7.2.3) are equal.
+
+16.7.2 Generic Resources
+If the cached response was for a generic resource (that is, the response
+includes Vary, or Alternates headers), it matches if the Request-URI of
+the request matches the Request-URI of the request that caused the
+cached response to be stored, and the selecting request header field
+values of the request match those of the request that caused the cached
+response to be stored. (See section 18.46 on Vary, which defines the
+canonical form for selecting request headers and the matching rules for
+them.)
+If the response contains "Vary: {other}", then the selecting request
+header field values for its request are defined as never matching a set
+of request headers.
+
+16.8 Errors or Incomplete Response Cache Behavior
+A cache that receives an incomplete response (for example, with fewer
+bytes of data than specified in a Content-length: header) may store the
+response. However, the cache MUST treat this as a partial response.
+Partial responses may be combined as described in section 16.4.4; the
+result might be a full response or might still be partial. A cache MUST
+NOT return a partial response to a client without explicitly marking it
+as such, using the 206 (Partial Content) status code. A cache MUST NOT
+return a partial response using a status code of 200 (OK).
+
+A cache that receives a response with a zero-length Entity-body and no
+explicit indication that the correct length is zero (such as "Content-
+Length: 0") MUST NOT store the response. The same rule applies to a
+response of any length received without an explicit length indication if
+the transport connection was terminated in any unusual way.
+
+If a cache receives a response carrying Retry-After header (see section
+18.40), it may either forward this response to the requesting client, or
+act as if the server failed to respond. In the latter case, it MAY
+return a previously received response, although it MUST follow all of
+the rules applying to stale responses. In particular, it MUST NOT
+override the "must-revalidate" Cache-Control directive (see section
+18.10).
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 77]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+16.8.1 Caching and Status Codes
+A response received with a status code of 200 or 206 may be stored by a
+cache and used in reply to a subsequent request, subject to the
+expiration mechanism, unless a Cache-control directive prohibits
+caching.
+
+A response received with any other status code MUST NOT be returned in a
+reply to a subsequent request unless it carries at least one of the
+following:
+
+ . an Expires header
+ . a max-age Cache-control directive
+ . a must-revalidate Cache-control directive
+ . a public Cache-control directive
+
+16.8.2 Handling of Retry-After
+If a cache receives a response carrying a Retry-After header (see
+section 18.40), it may either forward this response to the requesting
+client, or act as if the server failed to respond. In the latter case,
+it MAY return a previously received response, although it MUST follow
+all of the rules applying to stale responses. In particular, it MUST
+NOT override the "must-revalidate" Cache-Control directive (see section
+18.10).
+
+
+16.9 Side Effects of GET and HEAD
+Unless the origin server explicitly prohibits the caching of their
+responses, the application of GET and HEAD methods to any resources
+SHOULD NOT have side effects that would lead to erroneous behavior if
+these responses are taken from a cache. They may still have side
+effects, but a cache is not required to consider such side effects in
+its caching decisions. Caches are always expected to observe an origin
+server's explicit restrictions on caching.
+
+We note one exception to this rule: since some applications have
+traditionally used GETs and HEADs with query URLs (those containing a
+"?" in the rel_path part) to perform operations with significant side
+effects, caches MUST NOT treat responses to such URLs as fresh unless
+the server provides an explicit expiration time.
+
+This specifically means that responses from HTTP/1.0 servers for such
+URIs should not be taken from a cache.
+
+See section 19.2 for related information.
+
+
+16.10 Invalidation After Updates or Deletions
+The effect of certain methods at the origin server may cause one or more
+existing cache entries to become non-transparently invalid. That is,
+although they may continue to be "fresh," they do not accurately reflect
+what the origin server would return for a new request.
+
+There is no way for the HTTP protocol to guarantee that all such cache
+entries are marked invalid. For example, the request that caused the
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 78]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+change at the origin server may not have gone through the proxy where a
+cache entry is stored. However, several rules help reduce the
+likelihood of erroneous behavior.
+
+In this section, the phrase "invalidate an entity" means that the cache
+should either remove all instances of that entity from its storage, or
+should mark these as "invalid" and in need of a mandatory revalidation
+before they can be returned in response to a subsequent request.
+
+Some HTTP methods invalidate a single entity. This is either the entity
+referred to by the Request-URI, or by the Location or Content-Location
+response headers (if present). These methods are:
+
+ . PUT
+ . DELETE
+ . POST
+In order to prevent denial of service attacks, an invalidation based on
+the URI in a Location or Content-Location header MUST only be performed
+if the host part is the same as in the Request-URI.
+
+
+16.11 Write-Through Mandatory
+All methods that may be expected to cause modifications to the origin
+server's resources MUST be written through to the origin server. This
+currently includes all methods except for GET and HEAD. A cache MUST NOT
+reply to such a request from a client before having transmitted the
+request to the inbound server, and having received a corresponding
+response from the inbound server.
+
+The alternative (known as "write-back" or "copy-back" caching) is not
+allowed in HTTP/1.1, due to the difficulty of providing consistent
+updates and the problems arising from server, cache, or network failure
+prior to write-back.
+
+
+16.12 Generic Resources and HTTP/1.0 Proxy Caches
+If the correct handling of responses from a generic resource (Section
+15) by HTTP/1.0 proxy caches in the response chain is important,
+HTTP/1.1 origin servers can include the following Expires (Section
+18.22) response header in all responses from the generic resource:
+
+ Expires: Thu, 01 Jan 1980 00:00:00 GMT
+
+If this Expires header is included, the server should usually also
+include a Cache-Control header for the benefit of HTTP/1.1 caches, for example
+
+ Cache-Control: max-age=604800
+
+which overrides the freshness lifetime of zero seconds specified by the
+included Expires header.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+16.13 Cache Replacement
+If a new cacheable response (see sections 18.10.2, 16.2.6, 16.2.8 and
+16.8) is received from a plain resource while any existing responses for
+the same resource are cached, the cache MUST NOT return any of those
+older responses to any future requests for the resource.
+
+ Note: a new response that has an older Date header value than
+ existing cached responses is not cacheable.
+
+If a new cacheable response is received from a generic resource with a
+certain variant-ID while any old responses with the same variant-ID for
+the same resource are cached, the cache MUST NOT return any of those old
+responses to any future requests for the resource.
+
+ Note: In some cases, this may mean that the cache chooses to delete
+ the old response(s) from cache storage to recover space. However,
+ note that there will never be a new response to signal that a
+ variant-ID is no longer in use. It is expected that the cache's
+ update heuristics will eventually cause such old responses to be
+ deleted.
+
+The cache SHOULD use the new response to reply to the current request.
+It may insert it into cache storage and may, if it meets all other
+requirements, use it to respond to any future requests that would
+previously have caused the old response to be returned. If it inserts
+the new response into cache storage it should follow the rules in
+section 16.4.3.
+
+
+16.14 Caching of Negative Responses
+Caching of negative responses has often been a significant performance
+advantage in distributed systems. In some future draft or specification
+we may have more to say about negative caching.
+
+
+16.15 History Lists
+History lists as implemented in many user agents and caches are
+different. In particular history lists SHOULD NOT try to show a
+semantically transparent view of the current state of a resource
+entity.
+Rather, a history list is meant to show exactly what the user saw at the
+time when the resource was retrieved .
+
+This should not be construed to prohibit the history mechanism from
+telling the user that a view may be stale.
+
+
+17 Persistent Connections
+
+17.1 Purpose
+HTTP's greatest strength and its greatest weakness has been its
+simplicity. Prior to persistent connections, a separate TCP connection
+was established to fetch each URL, increasing the load on HTTP servers,
+and causing congestion on the Internet. The use of inline images and
+other associated data often requires a client to make multiple requests
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 80]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+of the same server in a short amount of time. An excellent analysis of
+these performance problems is available [30]; analysis and results from
+a prototype implementation are in [33], [34].
+
+ Persistent HTTP connections have a number of advantages:
+
+ . By opening and closing fewer TCP connections, CPU time is saved,
+ and memory used for TCP protocol control blocks is also saved
+ . HTTP requests and responses can be pipe-lined on a connection.
+ Pipe-lining allows a client to make multiple requests without
+ waiting for each response, allowing a single TCP connection to be
+ used much more efficiently, with much lower elapsed time.
+ . Network congestion is reduced by reducing the number of packets
+ caused by TCP opens, and by allowing TCP sufficient time to
+ determine the congestion state of the network.
+ . HTTP can evolve more gracefully; since errors can be reported
+ without the penalty of closing the TCP connection. Clients using
+ future versions of HTTP might optimistically try a new feature, but
+ if communicating with an older server, retry with old semantics
+ after an error is reported.
+HTTP implementations SHOULD implement persistent connections.
+
+
+17.2 Overall Operation
+Persistent connections provides a mechanism by which a client and a
+server can negotiate the use of a TCP connection for an extended
+conversation. This negotiation takes place using the Connection and
+Persist header fields. Once this option has been negotiated, the client
+can make multiple HTTP requests over a single transport connection.
+
+
+17.2.1 Negotiation
+To request the use of persistent connections, a client sends a
+Connection header with a connection-token "Persist". If the server
+wishes to accept persistent connections, it will respond with the same
+connection-token. Both the client and server MUST send this connection-
+token with every request and response for the duration of the persistent
+connection. If either the client or the server omits the Persist token
+from the Connection header, that request becomes the last one for the
+connection.
+
+A server MUST NOT establish a persistent connection with an HTTP/1.0
+client that uses the above form of the Persist header due to problems
+with the interactions between HTTP/1.1 clients and HTTP/1.0 proxy
+servers. (See section 23.5.2.5 for more information on backwards
+compatibility with HTTP/1.0 clients.)
+
+
+17.2.2 Pipe-lining
+Clients and servers which support persistent connections MAY
+"pipe-line"
+their requests and responses. When pipe-lining, a client will send
+multiple requests without waiting for the responses. The server MUST
+then send all of the responses in the same order that the requests were
+made.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 81]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+A client MAY assume that a server supports persistent connections if the
+same server has accepted persistent connections within the past 24
+hours. Clients which assume persistent connections and pipeline
+immediately SHOULD be prepared to retry their connection if the first
+pipe-lined attempt fails. If a client does such a retry, it MUST NOT
+pipeline without first receiving an explicit Persist token from the
+server. Clients MUST also be prepared to resend their requests if the
+server closes the connection before sending all of the corresponding
+responses.
+
+
+17.2.3 Delimiting Entity-Bodies
+When using persistent connections, both the client and the server MUST
+mark the exact endings of transmitted entity-bodies using one of the
+following three techniques:
+
+ 1. Send a Content-length field in the header with the exact number of
+ bytes in the entity-body.
+ 2. Send the message using chunked Transfer Coding as described in
+ section 7.6. Chunked Transfer Coding allows the server to transmit
+ the data to the client a piece at a time while still communicating
+ an exact ending of the entity-body.
+ 3. Close the transport connection after the entity body.
+Sending the Content-length is the preferred technique. Chunked encoding
+SHOULD be used when the size of the entity-body is not known before
+beginning to transmit the entity-body. Finally, the connection MAY be
+closed and fall back to non-persistent connections, if neither 1 or 2
+are possible.
+
+Clients and servers that support persistent connections MUST correctly
+support receiving via all three techniques.
+
+
+17.3 Proxy Servers
+It is especially important that proxies correctly implement the
+properties of the Connection header field as specified in 14.2.1.
+
+The proxy server MUST negotiate persistent connections separately with
+its clients and the origin servers (or other proxy servers) that it
+connects to. Each persistent connection applies to only one transport
+link.
+
+A proxy server MUST NOT establish a persistent connection with an
+HTTP/1.0 client.
+
+
+17.4 Interaction with Security Protocols
+It is expected that persistent connections will operate with both SHTTP
+[31] and SSL [32]. When used in conjunction with SHTTP, the SHTTP
+request is prepared normally and the persist connection-token is placed
+in the outermost request block (the one containing the "Secure"
+method).
+When used in conjunction with SSL, a SSL session is started as normal
+and the first HTTP request made using SSL contains the persistent
+connection header.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 82]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+17.5 Practical Considerations
+Servers will usually have some time-out value beyond which they will no
+longer maintain an inactive connection. Proxy servers might make this a
+higher value since it is likely that the client will be making more
+connections through the same server. The use of persistent connections
+places no requirements on the length of this time-out for either the
+client or the server.
+
+When a client or server wishes to time-out it SHOULD issue a graceful
+close on the transport connection. Clients and servers SHOULD both
+constantly watch for the other side of the transport close, and respond
+to it as appropriate. If a client or server does not detect the other
+side's close promptly it could cause unnecessary resource drain on the
+network.
+
+A client, server, or proxy MAY close the transport connection at any
+time. For example, a client MAY have started to send a new request at
+the same time that the server has decided to close the "idle"
+connection. From the server's point of view, the connection is being
+closed while it was idle, but from the client's point of view, a request
+is in progress.
+
+This means that clients, servers, and proxies MUST be able to recover
+from asynchronous close events. Client software SHOULD reopen the
+transport connection and retransmit the aborted request without user
+interaction. However, this automatic retry SHOULD NOT be repeated if the
+second request fails.
+
+Servers SHOULD always respond to at least one request per connection, if
+at all possible. Servers SHOULD NOT close a connection in the middle of
+transmitting a response, unless a network or client failure is
+suspected.
+
+It is suggested that clients which use persistent connections SHOULD
+limit the number of simultaneous connections that they maintain to a
+given server. A single-user client SHOULD maintain AT MOST 2 connections
+with any server of proxy. A proxy SHOULD use up to 2*N connections to
+another server or proxy, where N is the number of simultaneously active
+users. These guidelines are intended to improve HTTP response times and
+avoid congestion of the Internet or other networks.
+
+
+18 Header Field Definitions
+This section defines the syntax and semantics of all standard HTTP/1.1
+header fields. For Entity-Header fields, both sender and recipient refer
+to either the client or the server, depending on who sends and who
+receives the entity.
+
+
+18.1 Accept
+The Accept request-header field can be used to specify certain media
+types which are acceptable for the response. Accept headers can be used
+to indicate that the request is specifically limited to a small set of
+desired types, as in the case of a request for an in-line image.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 83]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The field MAY be folded onto several lines and more than one occurrence
+of the field is allowed, with the semantics being the same as if all the
+entries had been in one field value.
+
+ Accept = "Accept" ":" #(
+ media-range
+ [ ( ":" | ";" )
+
+ range-parameter
+
+ *( ";" range-parameter ) ]
+
+ | extension-token )
+
+ media-range = ( "*/*"
+ | ( type "/" "*" )
+ | ( type "/" subtype )
+ ) *( ";" parameter )
+
+ range-parameter = ( "q" "=" qvalue )
+ | extension-range-parameter
+
+ extension-range-parameter = ( token "=" token )
+
+ extension-token = token
+
+The asterisk "*" character is used to group media types into ranges,
+with "*/*" indicating all media types and "type/*" indicating all
+subtypes of that type. The range-parameter q is used to indicate the
+media type quality factor for the range, which represents the user's
+preference for that range of media types. The default value is q=1. In
+Accept headers generated by HTTP/1.1 clients, the character separating
+media-ranges from range-parameters SHOULD be a ":". HTTP/1.1 servers
+SHOULD be tolerant of use of the ";" separator by HTTP/1.0 clients.
+
+The example
+
+ Accept: audio/*: q=0.2, audio/basic
+
+SHOULD be interpreted as "I prefer audio/basic, but send me any audio
+type if it is the best available after an 80% mark-down in quality."
+
+If no Accept header is present, then it is assumed that the client
+accepts all media types. If Accept headers are present, and if the
+server cannot send a response which is acceptable according to the
+Accept headers, then the server SHOULD send an error response with the
+406 (not acceptable) status code, though the sending of an unacceptable
+response is also allowed.
+
+A more elaborate example is
+
+ Accept: text/plain: q=0.5, text/html,
+ text/x-dvi: q=0.8, text/x-c
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 84]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Verbally, this would be interpreted as "text/html and text/x-c are the
+preferred media types, but if they do not exist, then send the text/x-
+dvi entity, and if that does not exist, send the text/plain entity."
+
+Media ranges can be overridden by more specific media ranges or specific
+media types. If more than one media range applies to a given type, the
+most specific reference has precedence. For example,
+
+ Accept: text/*, text/html, text/html;level=1, */*
+
+have the following precedence:
+
+ 1) text/html;level=1
+ 2) text/html
+ 3) text/*
+ 4) */*
+
+The media type quality factor associated with a given type is determined
+by finding the media range with the highest precedence which matches
+that type. For example,
+
+ Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1,
+ */*:q=0.5
+
+would cause the following values to be associated:
+
+ text/html;level=1 = 1
+ text/html = 0.7
+ text/plain = 0.3
+ image/jpeg = 0.5
+ text/html;level=3 = 0.7
+
+ Note: A user agent MAY be provided with a default set of quality
+ values for certain media ranges. However, unless the user agent is
+ a closed system which cannot interact with other rendering agents,
+ this default set SHOULD be configurable by the user.
+
+
+
+
+18.2 Accept-Charset
+The Accept-Charset request-header field can be used to indicate what
+character sets are acceptable for the response. This field allows
+clients capable of understanding more comprehensive or special-purpose
+character sets to signal that capability to a server which is capable of
+representing documents in those character sets. The ISO-8859-1 character
+set can be assumed to be acceptable to all user agents.
+
+ Accept-Charset = "Accept-Charset" ":"
+
+ 1#( charset [ ";" "q" "=" qvalue ] )
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 85]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Character set values are described in section 7.4. Each charset may be
+given an associated quality value which represents the user's preference
+for that charset. The default value is q=1. An example is
+
+ Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+
+If no Accept-Charset header is present, the default is that any
+character set is acceptable. If an Accept-Charset header is present, and
+if the server cannot send a response which is acceptable according to
+the Accept-Charset header, then the server SHOULD send an error response
+with the 406 (not acceptable) status code, though the sending of an
+unacceptable response is also allowed.
+
+
+
+
+18.3 Accept-Encoding
+The Accept-Encoding request-header field is similar to Accept, but
+restricts the content-coding values (18.13) which are acceptable in the
+response.
+
+ Accept-Encoding = "Accept-Encoding" ":"
+ #( content-coding )
+
+An example of its use is
+
+ Accept-Encoding: compress, gzip
+
+If no Accept-Encoding header is present in a request, the server MAY
+assume that the client will accept any content coding. If an Accept-
+Encoding header is present, and if the server cannot send a response
+which is acceptable according to the Accept-Encoding header, then the
+server SHOULD send an error response with the 406 (not acceptable)
+status code.
+
+
+18.4 Accept-Language
+The Accept-Language request-header field is similar to Accept, but
+restricts the set of natural languages that are preferred as a response
+to the request.
+
+ Accept-Language = "Accept-Language" ":"
+ 1#( language-range [ ";" "q" "=" qvalue ] )
+
+ language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) )
+ | "*" )
+
+Each language-range MAY be given an associated quality value which
+represents an estimate of the user's comprehension of the languages
+specified by that range. The quality value defaults to "q=1" (100%
+comprehension).For example,
+
+ Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 86]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+would mean: "I prefer Danish, but will accept British English (with 80%
+comprehension) and other types of English(with 70% comprehension)." A
+language-range matches a language-tag if it exactly equals the tag, or
+if it exactly equals a prefix (a sub-sequence starting at the first
+character) of the tag such that the first tag character following the
+prefix is "-". The special range "*", if present in the
+Accept-Language
+field, matches every tag not matched by any other ranges present in the
+Accept-Language field.
+
+ Note: This use of a prefix matching rule does not imply that
+ language tags are assigned to languages in such a way that it is
+ always true that if a user understands a language with a certain
+ tag, then this user will also understand all languages with tags
+ for which this tag is a prefix. The prefix rule simply allows the
+ use of prefix tags if this is the case.
+
+The language quality factor assigned to a language-tag by the Accept-
+Language field is the quality value of the longest language-range in the
+field that matches the language-range. If no language-range in the
+field matches the tag, the language quality factor assigned is 0. If no
+Accept-Language header is present in the request, the server SHOULD
+assume that all languages are equally acceptable. If an
+Accept-Language
+header is present, then all languages which are assigned a quality
+factor greater than 0 are acceptable. If the server cannot generate a
+response for an audience capable of understanding at least one
+acceptable language, it can send a response that uses one or more un-
+accepted languages.
+
+It may be contrary to the privacy expectations of the user to send an
+Accept-Language header with the complete linguistic preferences of the
+user in every request. For a discussion of this issue, see section
+19.7.
+
+ Note: As intelligibility is highly dependent on the individual
+ user, it is recommended that client applications make the choice of
+ linguistic preference available to the user. If the choice is not
+ made available, then the Accept-Language header field MUST NOT be
+ given in the request.
+
+
+
+
+18.5 Accept-Ranges
+In some cases, a client may want to know if the server accepts range
+requests using a certain range unit. The server may indicate its
+acceptance of range requests for a resource entity by providing this
+header in a response for that resource:
+
+ Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
+
+ acceptable-ranges = 1#range-unit | "none"
+
+Origin servers that accept byte-range requests MAY send
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 87]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ Accept-Ranges: bytes
+
+but are not required to do so. Clients MAY generate byte-range requests
+without having received this header for the plain resource involved, but
+the server MAY ignore such requests.
+
+Origin servers that do not accept any kind of range request for a plain
+resource MAY send
+
+ Accept-Ranges: none
+
+to advise the client not to attempt a range request.
+
+
+18.6 Age
+Caches transmit age values using:
+
+ Age = "Age" ":" age-value
+
+ age-value = delta-seconds
+
+Age values are non-negative decimal integers, representing time in
+seconds.
+
+If a cache receives a value larger than the largest positive integer it
+can represent, or if any of its age calculations overflows, it MUST
+transmit an Age header with a value of 2147483648 (2^31). Otherwise,
+HTTP/1.1 caches MUST send an Age header in every response. Caches
+SHOULD use a representation with at least 31 bits of range..
+
+
+18.7 Allow
+The Allow entity-header field lists the set of methods supported by the
+resource identified by the Request-URI. The purpose of this field is
+strictly to inform the recipient of valid methods associated with the
+resource. An Allow header field MUST be present in a 405 (method not
+allowed) response. The Allow header field is not permitted in a request
+using the POST method, and thus SHOULD be ignored if it is received as
+part of a POST entity.
+
+ Allow = "Allow" ":" 1#method
+
+Example of use:
+
+ Allow: GET, HEAD, PUT
+
+This field cannot prevent a client from trying other methods. However,
+the indications given by the Allow header field value SHOULD be
+followed. The actual set of allowed methods is defined by the origin
+server at the time of each request.
+
+The Allow header field MAY be provided with a PUT request to recommend
+the methods to be supported by the new or modified resource. The server
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 88]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+is not required to support these methods and SHOULD include an Allow
+header in the response giving the actual supported methods.
+
+A proxy MUST NOT modify the Allow header field even if it does not
+understand all the methods specified, since the user agent MAY have
+other means of communicating with the origin server.
+
+The Allow header field does not indicate what methods are implemented at
+the server level. Servers MAY use the Public response header field
+(section 18.37) to describe what methods are implemented on the server
+as a whole.
+
+
+18.8 Alternates
+The Alternates response-header field is used by origin servers to signal
+that the resource identified by the current request has the capability
+to send different responses depending on the accept headers in the
+request message. This has an important effect on cache management,
+particularly for caching proxies which service a diverse set of user
+agents. This effect is covered in section 18.46.
+
+ Alternates = "Alternates" ":" opaque-field
+
+ opaque-field = field-value
+
+The Alternates header is included into HTTP/1.1 to make HTTP/1.1 caches
+compatible with a planned content negotiation mechanism. HTTP/1.1
+allows a future content negotiation standard to define the format of the
+Alternates header field-value, as long as the defined format satisfies
+the general rules in section 18.8.
+
+To ensure compatibility with future experimental or standardized
+software, caching HTTP/1.1 clients MUST treat all Alternates headers in
+a response as synonymous to the following Vary header:
+
+ Vary: {accept-headers}
+
+and follow the caching rules associated with the presence of this Vary
+header, as covered in Section 18.46. HTTP/1.1 allows origin servers to
+send Alternates headers under experimental conditions.
+
+
+18.9 Authorization
+A user agent that wishes to authenticate itself with a server--usually,
+but not necessarily, after receiving a 401 response--MAY do so by
+including an Authorization request-header field with the request. The
+Authorization field value consists of credentials containing the
+authentication information of the user agent for the realm of the
+resource being requested.
+
+ Authorization = "Authorization" ":" credentials
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 89]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+HTTP access authentication is described in section 14. If a request is
+authenticated and a realm specified, the same credentials SHOULD be
+valid for all other requests within this realm.
+
+When a shared cache (see section 16.6) receives a request containing an
+Authorization field, it MUST NOT return the corresponding response as a
+reply to any other request, unless one of the following specific
+exceptions holds:
+
+ 1. If the response includes the "proxy-revalidate" Cache-Control
+ directive, the cache MAY use that response in replying to a
+ subsequent request, but a proxy cache MUST first revalidate it with
+ the origin server, using the request headers from the new request
+ to allow the origin server to authenticate the new request.
+ 2. If the response includes the "must-revalidate" Cache-Control
+ directive, the cache MAY use that response in replying to a
+ subsequent request, but all caches MUST first revalidate it with
+ the origin server, using the request headers from the new request
+ to allow the origin server to authenticate the new request.
+ 3. If the response includes the "public" Cache-Control directive, it
+ may be returned in reply to any subsequent request.
+
+18.10 Cache-Control
+The Cache-Control general-header field is used to specify directives
+that MUST be obeyed by all caching mechanisms along the
+request/response
+chain. The directives specify behavior intended to prevent caches from
+adversely interfering with the request or response. . These directives
+typically override the default caching algorithms. Cache directives are
+unidirectional in that the presence of a directive in a request does not
+imply that the same directive should be given in the response.
+
+Cache directives must be passed through by a proxy or gateway
+application, regardless of their significance to that application, since
+the directives may be applicable to all recipients along the
+request/response chain. It is not possible to specify a cache-directive
+for a specific cache.
+
+ Cache-Control = "Cache-Control" ":" 1#cache-directive
+
+ cache-directive = "public"
+ | "private" [ "=" <"> 1#field-name <"> ]
+ | "no-cache" [ "=" <"> 1#field-name <"> ]
+ | "no-store"
+ | "no-transform"
+ | "must-revalidate"
+ | "proxy-revalidate"
+ | "only-if-cached"
+ | "max-age" "=" delta-seconds
+ | "max-stale" "=" delta-seconds
+ | "min-fresh" "=" delta-seconds
+ | "min-vers" "=" HTTP-Version
+
+When a directive appears without any 1#field-name parameter, the
+directive applies to the entire request or response. When such a
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 90]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+directive appears with a 1#field-name parameter, it applies only to the
+named field or fields, and not to the rest of the request or response.
+This mechanism supports extensibility; implementations of future
+versions of the HTTP protocol may apply these directives to header
+fields not defined in HTTP/1.1.
+
+The cache-control directives can be broken down into these general
+categories:
+
+ . Restrictions on what is cachable; these may only be imposed by the
+ origin server.
+ . Restrictions on what may be stored by a cache; these may be imposed
+ by either the origin server or the end-user client.
+ . Modifications of the basic expiration mechanism; these may be
+ imposed by either the origin server or the end-user client.
+ . Controls over cache revalidation and reload; these may only be
+ imposed by an end-user client.
+ . Restrictions on the number of times a cache entry may be used, and
+ related demographic reporting mechanisms.
+ . Miscellaneous restrictions
+Caches never add or remove Cache-Control directives to requests or
+responses.
+
+Check: is this true?
+
+
+18.10.1 Cache-Control Restrictions on What is Cachable
+Unless specifically constrained by a Cache-Control directive, a caching
+system may always store a successful response (see section 16.8) as a
+cache entry, may return it without validation if it is fresh, and may
+return it after successful validation. If there is neither a cache
+validator nor an explicit expiration time associated with a response, we
+do not expect it to be cached, but certain caches may violate this
+expectation (for example, when little or no network connectivity is
+available). A client can usually detect that such a response was taken
+from a cache by comparing the Date header to the current time.
+
+ Note that some HTTP/1.0 caches are known to violate this
+ expectation without providing any Warning.
+
+However, in some cases it may be inappropriate for a cache to retain a
+resource entity, or to return it in response to a subsequent request.
+This may be because absolute semantic transparency is deemed necessary
+by the service author, or because of security or privacy
+considerations.
+Certain Cache-Control directives are therefore provided so that the
+server can indicate that certain resource entities, or portions
+thereof,
+may not be cached regardless of other considerations.
+
+Note that section 18.8 normally prevents a shared cache from saving and
+returning a response to a previous request if that request included an
+Authorization header.
+
+The following Cache-Control response directives add or remove
+restrictions on what is cachable:
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 91]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+public
+ Overrides the restriction in section 18.8 that prevents a shared
+ cache from saving and returning a response to a previous request if
+ that request included an Authorization header. However, any other
+ constraints on caching still apply.
+ private
+ Indicates that all or part of the response message is intended for a
+ single user and MUST NOT be cached by a shared cache. This allows an
+ origin server to state that the specified parts of the response are
+ intended for only one user and are not a valid response for requests
+ by other users. A private (non-shared) cache may ignore this
+ directive.
+ Note: This usage of the word "private" only controls where the
+ response may be cached, and cannot ensure the privacy of the
+ message content. Note in particular that HTTP/1.0 caches will not
+ recognize or obey this directive.
+
+
+no-cache
+ indicates that all or partof the response message MUST NOT be cached
+ anywhere. This allows an origin server to prevent caching even by
+ caches that have been configured to return stale responses to client
+ requests.
+ Note: HTTP/1.0 caches will not recognize or obey this directive.
+
+TBS: precedence relations between public, private, and no-cache.
+
+
+18.10.2 What May be Stored by Caches
+The "no-store" directive applies to the entire message, and may be sent
+either in a response or in a request. If sent in a request, a cache MUST
+NOT store any part of either this request or any response to it. If sent
+in a response, a cache MUST NOT store any part of either this response
+or the request that elicited it. This directive applies to both non-
+shared and shared caches.
+
+Even when this directive is associated with a response, users may
+explicitly store such a response outside of the caching system (e.g.,
+with a "Save As" dialog). History buffers may store such responses as
+part of their normal operation.
+
+The purpose of this directive is to meet the stated requirements of
+certain users and service authors who are concerned about accidental
+releases of information via unanticipated accesses to cache data
+structures. While the use of this directive may improve privacy in some
+cases, we caution that it is NOT in any way a reliable or sufficient
+mechanism for ensuring privacy. In particular, HTTP/1.0 caches will not
+recognize or obey this directive, malicious or compromised caches may
+not recognize or obey this directive, and communications networks may be
+vulnerable to eavesdropping.
+
+The "min-vers" directive applies to the entire message, and may be sent
+either in a response or in a request. If sent in a request, a cache
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 92]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+whose HTTP version number is less than the specified version MUST NOT
+store any part of either this request or any response to it. If sent in
+a response, a cache whose HTTP version number is less than the specified
+version MUST NOT store any part of either this response or the request
+that elicited it, nor may any cache transmit a stored (non-firsthand)
+copy of the response to any client with a lower HTTP version number.
+This directive applies to both non-shared and shared caches, and is made
+mandatory to allow for future protocol extensions that may affect
+caching.
+
+ Note that the lowest version that can be sensibly included in a
+ "min-vers" directive is HTTP/1.1, since HTTP/1.0 caches do not obey
+ it.
+
+
+18.10.3 Modifications of the Basic Expiration Mechanism
+The expiration time of a resource entity may be specified by the origin
+server using the Expires header (see section 18.22). Alternatively, it
+may be specified using the "max-age" directive in a response.
+
+If a response includes both an Expires header and a max-age directive,
+the max-age directive overrides the Expires header, even if the Expires
+header is more restrictive. This rule allows an origin server to
+provide, for a given response, a longer expiration time to an HTTP/1.1
+(or later) cache than to an HTTP/1.0 cache. This may be useful if
+certain HTTP/1.0 caches improperly calculate ages or expiration times,
+perhaps due to synchronized clocks.
+
+Other directives allow an end-user client to modify the basic expiration
+mechanism, making it either stricter or looser. These directives may be
+specified on a request:
+
+
+max-age
+ Indicates that the client is willing to accept a response whose age
+ is no greater than the specified time in seconds. Unless "max-stale"
+ is also included, the client is not willing to accept a stale
+ response. This directive overrides any policy of the cache.
+
+min-fresh
+ Indicates that the client is willing to accept a response whose
+ freshness lifetime is no less than its current age plus the specified
+ time in seconds. That is, the client wants a that response will still
+ be fresh for at least the specified number of seconds.
+
+max-stale
+ Indicates that the client is willing to accept a response that has
+ exceeded its expiration time by no more than the specified number of
+ seconds. If a cache returns a stale response in response to such a
+ request, it MUST mark it as stale using the Warning header.
+ Note that HTTP/1.0 caches will ignore these directives.
+
+If a cache returns a stale response, either because of a max-stale
+directive on a request, or because the cache is configured to override
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 93]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+the expiration time of a response, the cache MUST attach a Warning
+header to the stale response, using Warning 10 (Response is stale).
+
+
+18.10.4 Cache Revalidation and Reload Controls
+Sometimes an end-user client may want or need to insist that a cache
+revalidate its cache entry with the origin server (and not just with the
+next cache along the path to the origin server), or to reload its cache
+entry from the origin server. End-to-end revalidation may be necessary
+if either the cache or the origin server has overestimated the
+expiration time of the cached response. End-to-end reload may be
+necessary if the cache entryhas become corrupted for some reason, and
+the fact that its validator is up-to-date is irrelevant.
+
+End-to-end revalidation may be requested either when the client does not
+have its own local cached copy, in which case we call it "unspecified
+end-to-end revalidation", or when the client does have a local cached
+copy, in which case we call it "specific end-to-end revalidation."
+
+The client can specify these three kinds of action using Cache-Control
+request directives:
+
+
+End-to-end reload
+ The request includes "Cache-Control: no-cache" or, for compatibility
+ with HTTP/1.0 clients, "Pragma: no-cache". No field names may be
+ included with the "no-cache" directive in a request. The server MUST
+ NOT use a cached copy when responding to such a request.
+
+Specific end-to-end revalidation
+ The request includes "Cache-Control: max-age=0", which forces each
+ cache along the path to the origin server to revalidate its own
+ entry, if any, with the next cache or server. The initial request
+ includes a cache-validating conditional with the client's current
+ validator.
+
+Unspecified end-to-end revalidation
+ The request includes "Cache-Control: max-age=0", which forces each
+ cache along the path to the origin server to revalidate its own
+ entry, if any, with the next cache or server. The initial request
+ does not include a cache-validating conditional; the first cache
+ along the path (if any) that holds a cache entry for this resource
+ includes a cache-validating conditional with its current validator.
+ Note that HTTP/1.0 caches will ignore these directives, except
+ perhaps for "Pragma: no-cache".
+
+When an intermediate cache is forced, by means of a "max-age=0"
+directive, to revalidate its own cache entry, and the client has
+supplied its own validator in the request, the supplied validator may
+differ from the validator currently stored with the cache entry. In this
+case, the cache may use either validator in making its own request
+without affecting semantic transparency.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 94]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+However, the choice of validator may affect performance. The best
+approach is for the intermediate cache to use its own validator when
+making its request. If the server replies with 304 (Not Modified), then
+the cache should return its now validated copy to the client with a 200
+(OK) response. If the server replies with a new Entity-body and cache
+validator, however, the intermediate cache should compare the returned
+validator with the one provided in the client's request, using the
+strong comparison function. If the client's validator is equal to the
+origin server's, then the intermediate cache simply returns 304 (Not
+Modified). Otherwise, it returns the new Entity-body with a 200 (OK)
+response.
+
+If a request includes the "no-cache" directive, it should not include
+"min-fresh", "max-stale", or "max-age".
+
+In some cases, such as times of extremely poor network connectivity, a
+client may want a cache to return only those responses that it currently
+has stored, and not to reload or revalidate with the origin server. To
+do this, the client may include the "only-if-cached" directive in a
+request. If it receives this directive, a cache SHOULD either respond
+using a cached entry that is consistent with the other constraints of
+the request, or respond with a 504 (Gateway Timeout) status. However, if
+a group of caches is being operated as a unified system with good
+internal connectivity, such a request MAY be forwarded within that group
+of caches.
+
+Because a cache may be configured to ignore a server's specified
+expiration time, and because a client request may include a max-stale
+directive, which has a similar effect, the protocol also includes a
+mechanism for the origin server to require revalidation of a cache entry
+on any subsequent use. When the "must-revalidate" directive is present
+in a response received by a cache, that cache MUST NOT use the entry
+after it becomes stale to respond to a subsequent request without first
+revalidating it with the origin server. (I.e., the cache must do an
+end-
+to-end revalidation every time, if, based solely on the origin server's
+Expires or max-age value, the cached response is stale.)
+
+The "must-revalidate" directive is necessary to support reliable
+operation for certain protocol features. In all circumstances an
+HTTP/1.1 cache MUST obey the "must-revalidate" directive; in
+particular,
+if the cache cannot reach the origin server for any reason, it MUST
+generate a 504 (Gateway Timeout) response. Note that HTTP/1.0 caches
+will ignore this directive.
+
+Servers should send the "must-revalidate" directive if and only if
+failure to revalidate a request on the entity could result in incorrect
+operation, such as a silently unexecuted financial transaction.
+Recipients MUST NOT take any automated action that violates this
+directive, and MUST NOT automatically provide an unvalidated copy of the
+entity if revalidation fails.
+
+Although this is not recommended, user agents operating under severe
+connectivity constraints may violate this directive but, if so, MUST
+explicitly warn the user that an unvalidated response has been
+provided.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 95]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The warning MUST be provided on each unvalidated access, and SHOULD
+require explicit user confirmation.
+
+The "proxy-revalidate" directive has the same meaning as the "must-
+revalidate" directive, except that it does not apply to user-agent
+caches.
+
+
+18.10.5 Miscellaneous Restrictions
+In certain circumstances, an intermediate cache (proxy) may find it
+useful to convert the encoding of an entity body. For example, a proxy
+might use a compressed content-coding to transfer the body to a client
+on a slow link.
+
+Because end-to-end authentication of entity bodies and/or entity headers
+relies on the specific encoding of these values, such transformations
+may cause authentication failures. Therefore, an intermediate cache MUST
+NOT change the encoding of an entity body if the response includes the
+"no-transform" directive.
+
+ Note: the use of hop-by-hop compression in conjunction with Range
+ retrievals may require additional specification in a subsequent
+ draft.
+
+
+18.11 Connection
+HTTP version 1.1 provides a new request and response header field called
+"Connection". This header field allows the client and server to specify
+options which should only exist over that particular connection and MUST
+NOT be communicated by proxies over further connections. The connection
+header field MAY have multiple tokens separated by commas (referred to
+as connection-tokens).
+
+HTTP version 1.1 proxies MUST parse the Connection header field and for
+every connection-token in this field, remove a corresponding header
+field from the request before the request is forwarded. The use of a
+connection option is specified by the presence of a connection token in
+the Connection header field, not by the corresponding additional header
+field (which may not be present).
+
+When a client wishes to establish a persistent connection it MUST send a
+"Persist" connection-token:
+
+ Connection: persist
+
+The Connection header has the following grammar:
+
+ Connection-header = "Connection" ":" 1#(connection-token)
+ connection-token = token
+
+
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 96]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+18.12 Content-Base
+The Content-Base entity-header field may be used to specify the base URI
+for resolving relative URLs within the entity. This header field is
+described as "Base" in RFC 1808 , which is expected to be revised soon.
+
+ Content-Base = "Content-Base" ":" absoluteURI
+
+If no Content-Base field is present, the base URI of an entity is
+defined either by its Content-Location or the URI used to initiate the
+request, in that order of precedence. Note, however, that the base URI
+of the contents within the entity body may be redefined within that
+entity body.
+
+
+18.13 Content-Encoding
+The Content-Encoding entity-header field is used as a modifier to the
+media-type. When present, its value indicates what additional content
+codings have been applied to the resource entity, and thus what decoding
+mechanisms MUST be applied in order to obtain the media-type referenced
+by the Content-Type header field. Content-Encoding is primarily used to
+allow a document to be compressed without losing the identity of its
+underlying media type.
+
+ Content-Encoding = "Content-Encoding" ":"
+1#content-coding
+
+Content codings are defined in section 7.5. An example of its use is
+
+ Content-Encoding: gzip
+
+The Content-Encoding is a characteristic of the resource entity
+identified by the Request-URI. Typically, the resource entity is stored
+with this encoding and is only decoded before rendering or analogous
+usage.
+
+If multiple encodings have been applied to a resource entity, the
+content codings MUST be listed in the order in which they were applied.
+Additional information about the encoding parameters MAY be provided by
+other Entity-Header fields not defined by this specification.
+
+
+18.14 Content-Language
+The Content-Language entity-header field describes the natural
+language(s) of the intended audience for the enclosed entity. Note that
+this may not be equivalent to all the languages used within the entity.
+
+ Content-Language = "Content-Language" ":" 1#language-tag
+
+Language tags are defined in section 7.10. The primary purpose of
+Content-Language is to allow a selective consumer to identify and
+differentiate resource variants according to the consumer's own
+preferred language. Thus, if the body content is intended only for a
+Danish-literate audience, the appropriate field is
+
+ Content-Language: dk
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 97]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+If no Content-Language is specified, the default is that the content is
+intended for all language audiences. This may mean that the sender does
+not consider it to be specific to any natural language, or that the
+sender does not know for which language it is intended.
+
+Multiple languages MAY be listed for content that is intended for
+multiple audiences. For example, a rendition of the "Treaty of
+Waitangi," presented simultaneously in the original Maori and English
+versions, would call for
+
+ Content-Language: mi, en
+
+However, just because multiple languages are present within an entity
+does not mean that it is intended for multiple linguistic audiences. An
+example would be a beginner's language primer, such as "A First Lesson
+in Latin," which is clearly intended to be used by an English-literate
+audience. In this case, the Content-Language should only include "en".
+
+Content-Language MAY be applied to any media type -- it SHOULD not be
+limited to textual documents.
+
+
+18.15 Content-Length
+The Content-Length entity-header field indicates the size of the
+Entity-
+Body, in decimal number of octets, sent to the recipient or, in the case
+of the HEAD method, the size of the Entity-Body that would have been
+sent had the request been a GET.
+
+ Content-Length = "Content-Length" ":" 1*DIGIT
+
+An example is
+
+ Content-Length: 3495
+
+Applications SHOULD use this field to indicate the size of the Entity-
+Body to be transferred, regardless of the media type of the entity. It
+must be possible for the recipient to reliably determine the end of a
+HTTP/1.1 request method containing an entity body, e.g., because the
+request has a valid Content-Length field, uses Transfer-Encoding:
+chunked or a multipart body.
+
+Any Content-Length greater than or equal to zero is a valid value.
+Section 11.2.2 describes how to determine the length of an Entity-Body
+if a Content-Length is not given.
+
+ Note: The meaning of this field is significantly different from the
+ corresponding definition in MIME, where it is an optional field
+ used within the "message/external-body" content-type. In HTTP, it
+ SHOULD be used whenever the entity's length can be determined prior
+ to being transferred.
+
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 98]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+18.16 Content-Location
+The Content-Location entity-header field is used to define the location
+of the plain resource associated with the entity enclosed in the
+message. A server SHOULD provide a Content-Location if, when including
+an entity in response to a GET request on a generic resource, the entity
+corresponds to a specific, non-negotiated location which can be accessed
+via the Content-Location URI. A server SHOULD provide a
+Content-Location
+with any 200 (OK) response which was internally (not visible to the
+client) redirected to a resource other than the one identified by the
+request and for which correct interpretation of that resource MAY
+require knowledge of its actual location.
+
+ Content-Location = "Content-Location" ":" absoluteURI
+
+If no Content-Base header field is present, the value of Content-
+Location also defines the base URL for the entity (see Section 18.12).
+
+ Note that the Content-Location information is advisory, and that
+ there is no guarantee that the URI of the Content-Location actually
+ corresponds in any way to the original request URI. For example, a
+ cache cannot reliably assume that the data returned as a result of
+ the request can be returned from a new request on any URI other
+ than the original request. See section 19.9.
+
+
+18.17 Content-MD5
+The Content-MD5 entity-header field is an MD5 digest of the
+entity-body,
+as defined in RFC 1864 [], for the purpose of providing an end-to-end
+message integrity check (MIC) of the entity-body. (Note: an MIC is good
+for detecting accidental modification of the entity-body in transit, but
+is not proof against malicious attacks.)
+
+ ContentMD5 = "Content-MD5" ":" md5-digest
+
+ md5-digest = <base64 of 128 bit MD5 digest as per RFC
+1864>
+
+The Content-MD5 header may be generated by an origin server to function
+as an integrity check of the entity-body. Only origin-servers may
+generate the Content-MD5 header field; proxies and gateways MUST NOT
+generate it, as this would defeat its value as an end-to-end integrity
+check. Any recipient of the entity-body, including gateways and
+proxies,
+MAY check that the digest value in this header field matches that of the
+entity-body as received.
+
+The MD5 digest is computed based on the content of the entity body,
+including any Content-Encoding that has been applied, but not including
+any Transfer-Encoding. If the entity is received with a Transfer-
+Encoding, that encoding must be removed prior to checking the Content-
+MD5 value against the received entity.
+
+This has the result that the digest is computed on the octets of the
+entity body exactly as, and in the order that, they would be sent if no
+Transfer-Encoding were being applied.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 99]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+HTTP extends RFC 1864 to permit the digest to be computed for MIME
+composite media-types (e.g., multipart/* and message/rfc822), but this
+does not change how the digest is computed as defined in the preceding
+paragraph.
+
+ Note: There are several consequences of this. The entity-body for
+ composite types may contain many body-parts, each with its own MIME
+ and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
+ and Content-Encoding headers). If a body-part has a Content-
+ Transfer-Encoding or Content-Encoding header, it is assumed that
+ the content of the body-part has had the encoding applied, and the
+ body-part is included in the Content-MD5 digest as is -- i.e.,
+ after the application. Also, the HTTP Transfer-Encoding header
+ makes no sense within body-parts; if it is present, it is ignored -
+ - i.e. treated as ordinary text.
+
+ Note: while the definition of Content-MD5 is exactly the same for
+ HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
+ in which the application of Content-MD5 to HTTP entity-bodies
+ differs from its application to MIME entity-bodies. One is that
+ HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
+ use Transfer-Encoding and Content-Encoding. Another is that HTTP
+ more frequently uses binary content types than MIME, so it is worth
+ noting that in such cases, the byte order used to compute the
+ digest is the transmission byte order defined for the type. Lastly,
+ HTTP allows transmission of text types with any of several line
+ break conventions and not just the canonical form using CRLF.
+ Conversion of all line breaks to CRLF should not be done before
+ computing or checking the digest: the line break convention used in
+ the text actually transmitted should be left unaltered when
+ computing the digest.
+
+
+
+
+18.18 Content-Range
+The Content-Range header is sent with a partial entity body to specify
+where in the full entity body the partial body should be inserted. It
+also indicates the total size of the entity.
+
+ Content-Range = "Content-Range" ":" content-range-spec
+
+When an HTTP message includes the content of a single range (for
+example, a response to a request for a single range, or to request for a
+set of ranges that overlap without any holes), this content is
+transmitted with a Content-Range header, and a Content-Length header
+showing the number of bytes actually transferred. For example,
+
+ HTTP/1.0 206 Partial content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-Range: 21010-47021/47022
+ Content-Length: 26012
+ Content-Type: image/gif
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 100]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+18.18.1 MIME multipart/byteranges Content-type
+When an HTTP message includes the content of multiple ranges (for
+
+example, a response to a request for multiple non-overlapping ranges),
+these are transmitted as a multipart MIME message. The multipart MIME
+content-type used for this purpose is defined in this specification to
+be "multipart/byteranges".
+
+The MIME multipart/byteranges content-type includes two or more parts,
+each with its own Content-Type and Content-Range fields. The parts are
+separated using a MIME boundary parameter.
+
+For example:
+
+ HTTP/1.0 206 Partial content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-type: multipart/byteranges;
+boundary=THIS_STRING_SEPARATES
+
+ --THIS_STRING_SEPARATES
+ Content-type: application/pdf
+ Content-range: bytes 500-999/8000
+
+ ...the first range...
+ --THIS_STRING_SEPARATES
+ Content-type: application/pdf
+ Content-range: bytes 7000-7999/8000
+
+ ...the second range
+ --THIS_STRING_SEPARATES_
+
+
+18.18.2 Additional Rules for Content-Range
+A client that cannot decode a MIME multipart/byteranges message should
+not ask for multiple byte-ranges in a single request.
+
+When a client requests multiple byte-ranges in one request, the server
+SHOULD return them in the order that they appeared in the request.
+
+If the server ignores a byte-range-spec because it is invalid, the
+server should treat the request as if the invalid Range header field did
+not exist (normally, this means return a 200 response containing the
+full resource entity). The reason is that the only time a client will
+make such an invalid request is when the resource entity has changed
+(shrunk) since the prior request.
+
+
+18.19 Content-Type
+The Content-Type entity-header field indicates the media type of the
+Entity-Body sent to the recipient or, in the case of the HEAD method,
+the media type that would have been sent had the request been a GET.
+
+ Content-Type = "Content-Type" ":" media-type
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 101]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Media types are defined in section 7.7. An example of the field is
+
+ Content-Type: text/html; charset=ISO-8859-4
+
+Further discussion of methods for identifying the media type of an
+entity is provided in section 11.2.1.
+
+
+18.20 Date
+The Date general-header field represents the date and time at which the
+message was originated, having the same semantics as orig-date in RFC
+822. The field value is an HTTP-date, as described in section 7.3.1.
+
+ Date = "Date" ":" HTTP-date
+
+An example is
+
+ Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+If a message is received via direct connection with the user agent (in
+the case of requests) or the origin server (in the case of responses),
+then the date can be assumed to be the current date at the receiving
+end. However, since the date--as it is believed by the origin--is
+important for evaluating cached responses, origin servers SHOULD always
+include a Date header. Clients SHOULD only send a Date header field in
+messages that include an entity body, as in the case of the PUT and POST
+requests, and even then it is optional. A received message which does
+not have a Date header field SHOULD be assigned one by the recipient if
+the message will be cached by that recipient or gatewayed via a protocol
+which requires a Date.
+
+In theory, the date SHOULD represent the moment just before the entity
+is generated. In practice, the date can be generated at any time during
+the message origination without affecting its semantic value.
+
+ Note: An earlier version of this document incorrectly specified
+ that this field SHOULD contain the creation date of the enclosed
+ Entity-Body. This has been changed to reflect actual (and proper)
+ usage.
+
+Origin servers MUST send a Date field in every response. However, if a
+cache receives a response without a Date field, it SHOULD attach one
+with the cache's best estimate of the time at which the response was
+originally generated.
+
+The format of the Date is an absolute date and time as defined by HTTP-
+date in Section 7.3; it MUST be in RFC1123-date format.
+
+
+
+
+18.21 ETag
+The ETag header is used to transmit entity tags with variant id's in
+HTTP/1.1 responses.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 102]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ ETag = "ETag" ":" etag-info
+ etag-info = entity-tag [ ";" variant-id ]
+
+Examples:
+
+ ETag: "xyzzy"
+ ETag: "xyzzy"/W
+ ETag: "xyzzy";"3"
+ ETag: "xyzzy"/W;"3"
+ ETag: ""
+
+ Note that the variant-id is not part of the entity tag. The ETag
+ field is used to transmit a variant-id simply as a matter of
+ compact representation of responses.
+
+
+18.22 Expires
+The Expires entity-header field gives the date/time after which the
+entity should be considered stale. A stale cache entry may not normally
+be returned by a cache (either a proxy cache or an end-user cache)
+unless it is first validated with the origin server (or with an
+intermediate cache that has a fresh copy of the resource entity). See
+section 16.1.2 for further discussion of the expiration model.
+
+The presence of an Expires field does not imply that the original
+resource will change or cease to exist at, before, or after that time.
+
+The format is an absolute date and time as defined by HTTP-date in
+section 7.3; it MUST be in rfc1123-date format:
+
+ Expires = "Expires" ":" HTTP-date
+
+An example of its use is
+
+ Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+ Note: if a response includes a Cache-Control field with the max-age
+ directive, that directive overrides the Expires field.
+
+HTTP/1.1 clients and caches MUST treat other invalid date formats,
+especially including the value "0", as in the past (i.e., "already
+expired").
+
+To mark a response as "already expired," an origin server should use an
+Expires date that is equal to the Date header value. (See the rules for
+expiration calculations in section 0.)
+
+To mark a response as "never expires," an origin server should use an
+Expires date approximately one year from the time the response is
+generated. HTTP/1.1 servers should not send Expires dates more than one
+year in the future.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 103]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+18.23 From
+The From request-header field, if given, SHOULD contain an Internet e-
+mail address for the human user who controls the requesting user agent.
+The address SHOULD be machine-usable, as defined by mailbox in RFC 822
+(as updated by RFC 1123 ):
+
+ From = "From" ":" mailbox
+
+An example is:
+
+ From: webmaster@w3.org
+
+This header field MAY be used for logging purposes and as a means for
+identifying the source of invalid or unwanted requests. It SHOULD NOT be
+used as an insecure form of access protection. The interpretation of
+this field is that the request is being performed on behalf of the
+person given, who accepts responsibility for the method performed. In
+particular, robot agents SHOULD include this header so that the person
+responsible for running the robot can be contacted if problems occur on
+the receiving end.
+
+The Internet e-mail address in this field MAY be separate from the
+Internet host which issued the request. For example, when a request is
+passed through a proxy the original issuer's address SHOULD be used.
+
+ Note: The client SHOULD not send the From header field without the
+ user's approval, as it may conflict with the user's privacy
+ interests or their site's security policy. It is strongly
+ recommended that the user be able to disable, enable, and modify
+ the value of this field at any time prior to a request.
+
+
+18.24 Host
+The Host request-header field specifies the Internet host and port
+number of the resource being requested, as obtained from the original
+URL given by the user or referring resource (generally an HTTP URL, as
+described in section 7.2.2). The Host field value MUST represent the
+network location of the origin server or gateway given by the original
+URL. This allows the origin server or gateway to differentiate between
+internally-ambiguous URLs, such as the root "/" URL of a server for
+multiple host names on a single IP address.
+
+ Host = "Host" ":" host [ ":" port ] ; Section 7.2.2
+
+A "host" without any trailing port information implies the default port
+for the service requested (e.g., "80" for an HTTP URL). For example, a
+request on the origin server for <http://www.w3.org/pub/WWW/> MUST
+include:
+
+ GET /pub/WWW/ HTTP/1.1
+ Host: www.w3.org
+
+The Host header field MUST be included in all HTTP/1.1 request messages
+on the Internet (i.e., on any message corresponding to a request for a
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 104]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+URL which includes an Internet host address for the service being
+requested). If the Host field is not already present, an HTTP/1.1 proxy
+MUST add a Host field to the request message prior to forwarding it on
+the Internet. All Internet-based HTTP/1.1 servers MUST respond with a
+400 status code to any HTTP/1.1 request message which lacks a Host
+header field.
+
+
+18.25 If-Modified-Since
+The If-Modified-Since request-header field is used with the GET method
+to make it conditional: if the requested resource entity has not been
+modified since the time specified in this field, a copy of the resource
+entity will not be returned from the server; instead, a 304 (not
+modified) response will be returned without any Entity-Body.
+
+ If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+An example of the field is:
+
+ If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+A GET method with an If-Modified-Since header and no Range header
+requests that the identified resource entity be transferred only if it
+has been modified since the date given by the If-Modified-Since header.
+The algorithm for determining this includes the following cases:
+
+
+a)If the request would normally result in anything other than a 200
+ (OK) status, or if the passed If-Modified-Since date is invalid, the
+ response is exactly the same as for a normal GET. A date which is
+ later than the server's current time is invalid.
+
+b)If the resource entity has been modified since the If-Modified-Since
+ date, the response is exactly the same as for a normal GET.
+
+c)If the resource entity has not been modified since a valid If-
+ Modified-Since date, the server MUST return a 304 (not modified)
+ response.
+The purpose of this feature is to allow efficient updates of cached
+information with a minimum amount of transaction overhead.
+
+ Note that the Range request-header field modifies the meaning of
+ If-Modified-Since; see section 18.38 for full details.
+
+ Note that If-Modified-Since is ignored for generic resources.
+
+ Note that If-Modified-Since times are interpreted by the server,
+ whose clock may not be synchronized with the client.
+
+ Note that if a client uses an arbitrary date in the If-Modified-
+ Since header instead of a date taken from the Last-Modified header
+ for the same request, the client should be aware of the fact that
+ this date is interpreted in the server's understanding of time.
+ The client should consider unsynchronized clocks and rounding
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 105]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ problems due to the different representations of time between the
+ client and server. This includes the possibility of race
+ conditions if the document has changed between the time it was
+ first requested and the If-Modified-Since date of a subsequent
+ request, and the possibility of clock-skew-related problems if the
+ If-Modified-Date date is derived from the client's clock without
+ correction to the server's clock. Corrections for different time
+ bases between client and server are at best approximate due to
+ network latency.
+
+
+
+
+18.26 If-Match
+The If-Match request-header field is used with a method to make it
+conditional. A client that has a cache entry for the relevant entity
+supplies the associated entity tag using the If-Match header; if this
+entity tag matches the server's current entity tag for the entity, the
+server SHOULD perform the requested operation as if the If-Match header
+were not present.
+
+If the entity tags do not match, the server MUST NOT perform the
+requested operation, and MUST return a 412 (Precondition failed)
+response with no Entity-Body. This behavior is most useful when the
+client wants to prevent an updating method, such as PUT or POST, from
+modifying a resource entity that has changed since the client last
+checked it.
+
+When the If-Match header is used, the server should use the strong
+comparison function (see section 18.26) to compare entity tags.
+
+If the If-Match header is used to make a conditional request on generic
+resource, it may be used to pass a set of validators. This is done
+using the variant-set mechanism if the client has variant IDs for the
+corresponding cache entries (see sections 16.5.3 and 7.13 ). The server
+selects the appropriate variant based on other request headers; if the
+variant-ID for that resource entity is listed in the If-Match header,
+and if the entity-tag associated with that variant-ID in the header
+matches the current entity-tag of the resource entity, then the
+requested operation SHOULD be performed. Otherwise, it MUST NOT be
+performed.
+
+ If-Match = "If-Match" ":" if-match-rhs
+ if-match-rhs = opaque-validator | variant-set
+
+An updating request (e.g., a PUT or POST) on a generic resource should
+include only one variant-set-item, the one associated with the
+particular variant whose value is being conditionally updated.
+
+Examples of plain resource form:
+
+ If-Match: "xyzzy"
+ If-Match: "xyzzy"/W
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 106]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Examples of generic resource form:
+
+ If-Match: "xyzzy";"4"
+ If-Match: "xyzzy";"3", "r2d2xxxx";"5", "c3piozzzz";"7"
+ If-Match: "xyzzy"/W; "3", "r2d2xxxx"/W; "5", "c3piozzzz"/W; "7"
+
+If the request would, without the If-Match header, result in anything
+other than a 2xx status, then the If-Match header is ignored.
+
+The purpose of this feature is to allow efficient updates of cached
+information with a minimum amount of transaction overhead. It is also
+used, on updating requests, to prevent inadvertent modification of the
+wrong variant of a resource.
+
+
+18.27 If-NoneMatch
+The If-NoneMatch request-header field is used with a method to make it
+conditional. A client that has a cache entry for the relevant entity
+supplies the associated entity tag using the If-NoneMatch header; if
+this entity tag matches the server's current entity tag for the entity,
+the server SHOULD return a 304 (Not Modified) response without any
+Entity-Body.
+
+If the entity tags do not match, the server should treat the request as
+if the If-NoneMatch header was not present.
+
+See section 18.26 for rules on how to determine if two entity tags
+match.
+
+If the If-NoneMatch header is used to make a conditional request on
+generic resource, it may be used to pass a set of validators. This is
+done using the variant-set mechanism if the client has variant IDs for
+the corresponding cache entries (see sections 16.5.3 and 7.13). The
+server selects the appropriate variant based on other request headers;
+if the variant-ID for that resource entity is listed in the
+If-NoneMatch
+header, and if the entity-tag associated with that variant-ID in the
+header matches the current entity-tag of the resource entity, then the
+requested operation SHOULD NOT be performed. Otherwise, it SHOULD be
+performed.
+
+ If-NoneMatch = "If-NoneMatch" ":" if-nonematch-rhs
+ if-nonematch-rhs = opaque-validator | variant-set
+
+Examples of plain resource form:
+
+ If-NoneMatch: "xyzzy"
+ If-NoneMatch: "xyzzy"/W
+
+Examples of generic resource form:
+
+ If-NoneMatch: "xyzzy";"4"
+ If-NoneMatch: "xyzzy";"3", "r2d2xxxx";"5", "c3piozzzz";"7"
+ If-NoneMatch: "xyzzy"/W; "3", "r2d2xxxx"/W; "5", "c3piozzzz"/W;7
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 107]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+If the request would, without the If-NoneMatch header, result in
+anything other than a 2xx status, then the If-NoneMatch header is
+ignored.
+
+The purpose of this feature is to allow efficient updates of cached
+information with a minimum amount of transaction overhead.
+
+
+18.28 If-Range
+If a client has a partial copy of an entity in its cache, and wishes to
+have an up-to-date copy of the entire entity in its cache, it could use
+the Range request header with a conditional GET (using either or both of
+If-Unmodified-Since and If-Match.) However, if the condition fails
+because the entity has been modified, the client would then have to make
+a second request to obtain the entire current entity body.
+
+The If-Range header allows a client to "short-circuit" the second
+request. Informally, its meaning is "if the entity is unchanged, send
+me the part(s) that I am missing; otherwise, send me the entire new
+entity.'"
+
+ Range-If = "Range-If" ":" (if-valid-rhs | HTTP-date)
+
+If the client has no entity tag for a plain resource, but does have a
+Last-Modified date, it may use that date in a If-Range header. (The
+server can detect this because an HTTP-date, unlike any form of if-
+valid-rhs, does not start with a `"' quotation mark.) Dates may only be
+used in If-Range for plain resources, not for generic resources. The
+If-Range header should only be used together with a Range header, and
+must be ignored if the request does not include a Range header, or if
+the server does not support the sub-range operation.
+
+If the entity tag given in the If-Range header matches the current
+entity tag for the entity, then the server should provide the specified
+sub-range of the entity using a 206 (Partial content) response. If the
+entity tag does not match, then the server should return the entire
+entity using a 200 (OK) response.
+
+
+18.29 If-Unmodified-Since
+The If-Unmodified-Since request-header field is used with a method to
+make it conditional. If the requested resource entity has not been
+modified since the time specified in this field, the server should
+perform the requested operation as if the If-Unmodified-Since header
+were not present.
+
+If the requested resource entity has been modified since the specified
+time, the server MUST NOT perform the requested operation, and MUST
+return a 412 (Precondition Failed) response with no Entity-Body.
+
+ If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+An example of the field is:
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 108]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+If the request normally (i.e., without the If-Unmodified-Since header)
+would result in anything other than a 2xx status, the If-Unmodified-
+Since header should be ignored.
+
+If the specified date is invalid, the header is ignored.
+
+
+18.30 Last-Modified
+The Last-Modified entity-header field indicates the date and time at
+which the sender believes the resource entity was last modified. The
+exact semantics of this field are defined in terms of how the recipient
+SHOULD interpret it: if the recipient has a copy of this resource entity
+which is older than the date given by the Last-Modified field, that copy
+SHOULD be considered stale.
+
+ Last-Modified = "Last-Modified" ":" HTTP-date
+
+An example of its use is
+
+ Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+The exact meaning of this header field depends on the implementation of
+the sender and the nature of the original resource. For files, it may be
+just the file system last-modified time. For entities with dynamically
+included parts, it may be the most recent of the set of last-modify
+times for its component parts. For database gateways, it may be the
+last-update time stamp of the record. For virtual objects, it may be the
+last time the internal state changed.
+
+An origin server MUST NOT send a Last-Modified date which is later than
+the server's time of message origination. In such cases, where the
+resource's last modification would indicate some time in the future, the
+server MUST replace that date with the message origination date.
+
+An origin server should obtain the Last-Modified value of the entity as
+close as possible to the time that it generates the Date value of its
+response. This allows a recipient to make an accurate assessment of the
+entity's modification time, especially if the entity changes near the
+time that the response is generated.
+
+
+18.31 Location
+The Location response-header field is used to redirect the recipient to
+a location other than the Request-URI for completion of the request or
+identification of a new resource. For 201 (created) responses, the
+Location is that of the new resource which was created by the request.
+For 3xx responses, the location SHOULD indicate the server's preferred
+URL for automatic redirection to the resource. The field value consists
+of a single absolute URL.
+
+ Location = "Location" ":" absoluteURI
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 109]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+An example is
+
+ Location: http://www.w3.org/pub/WWW/People.html
+
+ Note: The Content-Location header field (section 18.16) differs
+ from Location in that the Content-Location identifies the original
+ location of the entity enclosed in the request. It is therefore
+ possible for a response to contain header fields for both Location
+ and Content-Location.
+
+
+18.32 Max-Forwards
+[JG14]The Max-Forwards general-header field may be used with the TRACE
+method (section 18.32) to limit the number of times that a proxy or
+gateway can forward the request to the next inbound server. This can be
+useful when the client is attempting to trace a request chain which
+appears to be failing or looping in mid-chain.
+
+ Max-Forwards = "Max-Forwards" ":" 1*DIGIT
+
+The Max-Forwards value is a decimal integer indicating the remaining
+number of times this request message may be forwarded.
+
+Each proxy or gateway recipient of a TRACE request containing a Max-
+Forwards header field SHOULD check and update its value prior to
+forwarding the request. If the received value is zero (0), the
+recipient SHOULD NOT forward the request; instead, it SHOULD respond as
+the final recipient with a 200 (OK) response containing the received
+request message as the response entity body (as described in Section
+13.7). If the received Max-Forwards value is greater than zero, then
+the forwarded message SHOULD contain an updated Max-Forwards field with
+a value decremented by one (1).
+
+The Max-Forwards header field SHOULD be ignored for all other methods
+defined by this specification and for any extension methods for which it
+is not explicitly referred to as part of that method definition.
+
+
+18.33 Persist
+When the Persist connection-token has been transmitted with a request or
+a response a Persist header field MAY also be included. The Persist
+header field takes the following form:
+
+ Persist-header = "Persist" ":" 0#pers-param
+
+ pers-param = param-name "=" word
+ param-name = token
+
+The Persist header itself is optional, and is used only if a parameter
+is being sent. HTTP/1.1 does not define any parameters.
+
+If the Persist header is sent, the corresponding connection token MUST
+be transmitted. The Persist header MUST be ignored if received without
+the connection token.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 110]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+18.34 Pragma
+The Pragma general-header field is used to include implementation-
+specific directives that may apply to any recipient along the
+request/response chain. All pragma directives specify optional behavior
+from the viewpoint of the protocol; however, some systems MAY require
+that behavior be consistent with the directives.
+
+ Pragma = "Pragma" ":" 1#pragma-directive
+
+ pragma-directive = "no-cache" | extension-pragma
+ extension-pragma = token [ "=" word ]
+
+When the "no-cache" directive is present in a request message, an
+application SHOULD forward the request toward the origin server even if
+it has a cached copy of what is being requested. This pragma directive
+has the same semantics as the "no-cache" cache-directive (see section
+18.10) and is defined here for backwards compatibility with HTTP/1.0.
+Clients SHOULD include both header fields when a "no-cache" request is
+sent to a server not known to be HTTP/1.1 compliant.
+
+Pragma directives MUST be passed through by a proxy or gateway
+application, regardless of their significance to that application, since
+the directives may be applicable to all recipients along the
+request/response chain. It is not possible to specify a pragma for a
+specific recipient; however, any pragma directive not relevant to a
+recipient SHOULD be ignored by that recipient.
+
+HTTP/1.1 clients SHOULD NOT send the Pragma request header. HTTP/1.1
+caches SHOULD treat "Pragma: no-cache" as if the client had sent
+"Cache-
+control: no-cache". No new Pragma directives will be defined in HTTP.
+
+
+18.35 Proxy-Authenticate
+The Proxy-Authenticate response-header field MUST be included as part of
+a 407 (Proxy Authentication Required) response. The field value consists
+of a challenge that indicates the authentication scheme and parameters
+applicable to the proxy for this Request-URI.
+
+ Proxy-Authentication = "Proxy-Authentication" ":" challenge
+
+The HTTP access authentication process is described in section 14.
+Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
+only to the current connection and MUST NOT be passed on to downstream
+clients.
+
+
+18.36 Proxy-Authorization
+The Proxy-Authorization request-header field allows the client to
+identify itself (or its user) to a proxy which requires authentication.
+The Proxy-Authorization field value consists of credentials containing
+the authentication information of the user agent for the proxy and/or
+realm of the resource being requested.
+
+ Proxy-Authorization = "Proxy-Authorization" ":" credentials
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 111]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The HTTP access authentication process is described in section 14.
+Unlike Authorization, the Proxy-Authorization applies only to the
+current connection and MUST NOT be passed on to upstream servers. If a
+request is authenticated and a realm specified, the same credentials
+SHOULD be valid for all other requests within this realm.
+
+
+18.37 Public
+The Public response-header field lists the set of non-standard methods
+supported by the server. The purpose of this field is strictly to inform
+the recipient of the capabilities of the server regarding unusual
+methods. The methods listed may or may not be applicable to the
+Request-
+URI; the Allow header field (section 18.7) SHOULD be used to indicate
+methods allowed for a particular URI. This does not prevent a client
+from trying other methods. The field value SHOULD not include the
+methods predefined for HTTP/1.1 in section 9.1.1.
+
+ Public = "Public" ":" 1#method
+
+Example of use:
+
+ Public: OPTIONS, MGET, MHEAD
+
+This header field applies only to the server directly connected to the
+client (i.e., the nearest neighbor in a chain of connections). If the
+response passes through a proxy, the proxy MUST either remove the Public
+header field or replace it with one applicable to its own capabilities.
+
+
+18.38 Range
+HTTP retrieval requests using conditional or unconditional GET methods
+may request one or more sub-ranges of the entity, instead of the entire
+entity. This is done using the Range request header:
+
+ Range = "Range" ":" ranges-specifier
+
+A server MAY ignore the Range header. However, HTTP/1.1 origin servers
+and intermediate caches SHOULD support byte ranges whenever possible,
+since this supports efficient recovery from partially failed transfers,
+and it supports efficient partial retrieval of large entities.
+
+If the server supports the Range header and the specified range or
+ranges are appropriate for the entity:
+
+ . The presence of a Range header in an unconditional GET modifies
+ what is returned if the GET is otherwise successful. In other
+ words, the response carries a status code of 206 (Partial Content)
+ instead of 200 (OK).
+ . The presence of a Range header in a conditional GET (a request
+ using one or both of If-Modified-Since and If-NoneMatch, or one or
+ both of If-Unmodified-Since and If-Match) modifies what is returned
+ if the GET is otherwise successful and the condition is true. It
+ does not affect the 304 (Not Modified) response returned if the
+ conditional is false.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 112]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+In some cases, it may be more appropriate to use the If-Range header
+(see section 18.28) in addition to the Range header.
+
+
+18.39 Referer
+The Referer[sic] request-header field allows the client to specify, for
+the server's benefit, the address (URI) of the resource from which the
+Request-URI was obtained. This allows a server to generate lists of
+back-links to resources for interest, logging, optimized caching, etc.
+It also allows obsolete or mistyped links to be traced for maintenance.
+The Referer field MUST NOT be sent if the Request-URI was obtained from
+a source that does not have its own URI, such as input from the user
+keyboard.
+
+ Referer = "Referer" ":" ( absoluteURI | relativeURI )
+
+Example:
+
+ Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+
+If a partial URI is given, it SHOULD be interpreted relative to the
+Request-URI. The URI MUST NOT include a fragment.
+
+ Note: Because the source of a link may be private information or
+ may reveal an otherwise private information source, it is strongly
+ recommended that the user be able to select whether or not the
+ Referer field is sent. For example, a browser client could have a
+ toggle switch for browsing openly/anonymously, which would
+ respectively enable/disable the sending of Referer and From
+ information.
+
+
+18.40 Retry-After
+The Retry-After response-header field can be used with a 503 (Service
+Unavailable) response to indicate how long the service is expected to be
+unavailable to the requesting client. The value of this field can be
+either an HTTP-date or an integer number of seconds (in decimal) after
+the time of the response.
+
+ Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
+
+Two examples of its use are
+
+ Retry-After: Wed, 14 Dec 1994 18:22:54 GMT
+ Retry-After: 120
+
+In the latter example, the delay is 2 minutes.
+
+
+18.41 Server
+The Server response-header field contains information about the software
+used by the origin server to handle the request. The field can contain
+multiple product tokens (section 7.8) and comments identifying the
+server and any significant subproducts. By convention, the product
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 113]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+tokens are listed in order of their significance for identifying the
+application.
+
+ Server = "Server" ":" 1*( product | comment )
+
+Example:
+
+ Server: CERN/3.0 libwww/2.17
+
+If the response is being forwarded through a proxy, the proxy
+application MUST NOT add its data to the product list. Instead, it
+SHOULD include a Via field (as described in section 18.47).
+
+ Note: Revealing the specific software version of the server may
+ allow the server machine to become more vulnerable to attacks
+ against software that is known to contain security holes. Server
+ implementers are encouraged to make this field a configurable
+ option.
+
+
+18.42 Title
+The Title entity-header field indicates the title of the entity
+
+ Title = "Title" ":" *TEXT
+
+An example of the field is
+
+ Title: Hypertext Transfer Protocol -- HTTP/1.1
+
+This field is isomorphic with the <TITLE> element in HTML .
+
+
+18.43 Transfer Encoding
+The Transfer-Encoding general-header field indicates what (if any) type
+of transformation has been applied to the message body in order to
+safely transfer it between the sender and the recipient. This differs
+from the Content-Encoding in that the transfer coding is a property of
+the message, not of the original resource entity.
+
+ Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer- coding
+
+Transfer codings are defined in section 7.6. An example is:
+
+ Transfer-Encoding: chunked
+
+Many older HTTP/1.0 applications do not understand the
+Transfer-Encoding
+header.
+
+
+18.44 Upgrade
+The Upgrade general-header allows the client to specify what additional
+communication protocols it supports and would like to use if the server
+finds it appropriate to switch protocols. The server MUST use the
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 114]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Upgrade header field within a 101 (Switching Protocols) response to
+indicate which protocol(s) are being switched.
+
+ Upgrade = "Upgrade" ":" 1#product
+
+For example,
+
+ Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
+The Upgrade header field is intended to provide a simple mechanism for
+transition from HTTP/1.1 to some other, incompatible protocol. It does
+so by allowing the client to advertise its desire to use another
+protocol, such as a later version of HTTP with a higher major version
+number, even though the current request has been made using HTTP/1.1.
+This eases the difficult transition between incompatible protocols by
+allowing the client to initiate a request in the more commonly supported
+protocol while indicating to the server that it would like to use a
+"better" protocol if available (where "better" is determined by the
+server, possibly according to the nature of the method and/or resource
+being requested).
+
+The Upgrade header field only applies to switching application-layer
+protocols upon the existing transport-layer connection. Upgrade cannot
+be used to insist on a protocol change; its acceptance and use by the
+server is optional. The capabilities and nature of the application-
+layer communication after the protocol change is entirely dependent upon
+the new protocol chosen, although the first action after changing the
+protocol MUST be a response to the initial HTTP request containing the
+Upgrade header field.
+
+The Upgrade header field only applies to the immediate connection.
+Therefore, the "upgrade" keyword MUST be supplied within a Connection
+header field (section 18.11) whenever Upgrade is present in an HTTP/1.1
+message.
+
+The Upgrade header field cannot be used to indicate a switch to a
+protocol on a different connection. For that purpose, it is more
+appropriate to use a 301, 302, 303, or 305 redirection response.
+
+This specification only defines the protocol name "HTTP" for use by the
+family of Hypertext Transfer Protocols, as defined by the HTTP version
+rules of section 7.1 and future updates to this specification. Any
+token can be used as a protocol name; however, it will only be useful if
+both the client and server associate the name with the same protocol.
+
+
+18.45 User-Agent
+The User-Agent request-header field contains information about the user
+agent originating the request. This is for statistical purposes, the
+tracing of protocol violations, and automated recognition of user agents
+for the sake of tailoring responses to avoid particular user agent
+limitations. Although it is not required, user agents SHOULD include
+this field with requests. The field can contain multiple product tokens
+(section 7.8) and comments identifying the agent and any subproducts
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 115]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+which form a significant part of the user agent. By convention, the
+product tokens are listed in order of their significance for identifying
+the application.
+
+ User-Agent = "User-Agent" ":" 1*( product | comment )
+
+Example:
+
+ User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+
+
+18.46 Vary
+The Vary response-header field is used by an origin server to signal
+that the resource identified by the current request is a generic)
+resource. A generic resource has multiple entities associated with it,
+all of which are representations of the content of the resource. If a
+GET or HEAD request on a generic resource is received, the origin server
+will select one of the associated entities as the entity best matching
+the request. Selection of this entity is based on the contents of
+particular header fields in the request message, or on other information
+pertaining to the request, like the network address of the sending
+client.
+
+A resource being generic has an important effect on cache management,
+particularly for caching proxies which service a diverse set of user
+agents. All 200 (OK) responses from generic resources MUST contain at
+least one Vary header (section 18.46) or Alternates header (section
+18.8) to signal variance.
+
+If no Vary headers and no Alternates headers are present in a 200 (OK)
+response, then caches may assume, as long as the response is fresh, that
+the resource in question is plain, and has only one associated entity.
+Note however that this entity can still change through time, as possibly
+indicated by a Cache-Control response header (section 18.10).
+
+After selection of the entity best matching the current request, the
+origin server will usually generate a 200 (OK) response, but it can also
+generate other responses like 206 (Partial Content) or 304 (Not
+Modified) if headers which modify the semantics of the request, like
+Range (section 18.38) or If-Match (section 18.26), are present. An
+origin server need not be capable of selecting an entity for every
+possible incoming request on a generic resource; it can choose to
+generate a 3xx (redirection) or 4xx (client error) type response for
+some requests.
+
+In a request message on a generic resource, the selecting request
+headers are those request headers whose contents were used by the origin
+server to select the entity best matching the request. The Vary header
+field specifies the selecting request headers and any other selection
+parameters that were used by the origin server.
+
+ Vary = "Vary" ":" 1#selection-parameter
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 116]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ selection-parameter = request-header-name
+ | "{accept-headers}"
+ | "{other}"
+ | "{" extension-parameter "}"
+
+ request-header-name = field-name
+
+ extension-parameter = token
+
+The presence of a request-header-name signals that the request-header
+field with this name is selecting. Note that the name need not belong
+to a request-header field defined in this specification, and that header
+names are case-insensitive. The presence of the "{accept-headers}"
+parameter signals that all request headers whose names start with
+"accept" are selecting.
+
+The inclusion of the "{other}" parameter in a Vary field signals that
+parameters other than the contents of request headers, for example the
+network address of the sending party, play a role in the selection of
+the response.
+
+ Note: This specification allows the origin server to express that
+ other parameters were used, but does not allow the origin server to
+ specify the exact nature of these parameters. This is left to
+ future extensions.
+
+If an extension-parameter unknown to the cache is present in a Vary
+header, the cache MUST treat it as the "{other}" parameter. If multiple
+Vary and Alternates header fields are present in a response, these MUST
+be combined to give all selecting parameters.
+
+The field name "Host" MUST never be included in a Vary header; clients
+MUST ignore it if it is present. The names of fields which change the
+semantics of a GET request, like "Range" and "If-Match" MUST also never
+be included, and MUST be ignored when present.
+
+Servers which use access authentication are not obliged to send "Vary:
+Authorization" headers in responses. It MUST be assumed that requests
+on authenticated resources can always produce different responses for
+different users. Note that servers can signal the absence of
+authentication by including "Cache-Control: public" header in the
+response.
+
+A cache MAY store and refresh 200 (OK) responses from a generic resource
+according to the rules in section 16.4. The partial entities in 206
+(Partial Content) responses from generic resources MAY also be used by
+the cache.
+
+When getting a request on a generic resource, a cache can only return a
+cached 200 (OK) response to one of its clients in two particular cases.
+
+First, if a cache gets a request on a generic resource for which it has
+cached one or more responses with Vary or Alternates headers, it can
+relay that request towards the origin server, adding an If-NoneMatch
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 117]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+header listing the etag-info values in the ETag headers (section Error!
+Reference source not found.) of the cached responses which have
+variant-
+IDs. If it then gets back a 304 (Not Modified) response with the etag-
+info of a cached 200 (OK) response in its ETag header, it can return
+this cached 200 (OK) response to its client, after merging in any of the
+304 response headers as specified in section 16.4.2.
+
+Second, if a cache gets a request on a generic resource, it can return
+to its client a cached, fresh 200 (OK) response which has Vary or
+Alternates headers, provided that
+
+
+ . the Vary and Alternates headers of this fresh response specify that
+ only request header fields are selecting parameters,
+
+ . the specified selecting request header fields of the current
+ request match the specified selecting request header fields of a
+ previous request on the resource relayed towards the origin
+server,
+
+ . this previous request got a 200 (OK) or 304 (Not Modified) response
+ which had the same etag-info value in its ETag header as the
+ cached, fresh 200 (OK) response.
+Two sequences of selecting request header fields match if and only if
+the first sequence can be transformed into the second sequence by only
+adding or removing whitespace at places in fields where this is allowed
+according to the syntax rules in this specification.
+
+If a cached 200 (OK) response MAY be returned to a request on a generic
+resource which includes a Range request header, then a cache MAY also
+use this 200 (OK) response to construct and return a 206 (Partial
+Content) response with the requested range.
+
+ Note: Implementation of support for the second case above is mainly
+ interesting in user agent caches, as a user agent cache will
+ generally have an easy way of determining whether the sequence of
+ request header fields of the current request equals the sequence
+ sent in an earlier request on the same resource. Proxy caches
+ supporting the second case would have to record diverse sequences
+ of request header fields previously relayed; the implementation
+ effort associated with this may not be balanced by a sufficient
+ payoff in traffic savings. A planned specification of a content
+ negotiation mechanism will define additional cases in which proxy
+ caches can return a cached 200 (OK) response without contacting the
+ origin server. The implementation effort associated with support
+ for these additional cases is expected to have a much better
+ cost/benefit ratio.
+
+
+18.47 Via
+The Via general-header field MUST be used by gateways and proxies to
+indicate the intermediate protocols and recipients between the user
+agent and the server on requests, and between the origin server and the
+client on responses. It is analogous to the "Received" field of RFC 822
+and is intended to be used for tracking message forwards, avoiding
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 118]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+request loops, and identifying the protocol capabilities of all senders
+along the request/response chain.
+
+ Via = "Via" ":" 1#( received-protocol received-by [ comment ]
+)
+
+ received-protocol = [ protocol-name "/" ] protocol-version
+ protocol-name = token
+ protocol-version = token
+ received-by = ( host [ ":" port ] ) | pseudonym
+ pseudonym = token
+
+The received-protocol indicates the protocol version of the message
+received by the server or client along each segment of the
+request/response chain. The received-protocol version is appended to
+the Via field value when the message is forwarded so that information
+about the protocol capabilities of upstream applications remains visible
+to all recipients.
+
+The protocol-name is optional if and only if it would be "HTTP". The
+received-by field is normally the host and optional port number of a
+recipient server or client that subsequently forwarded the message.
+However, if the real host is considered to be sensitive information, it
+MAY be replaced by a pseudonym. If the port is not given, it MAY be
+assumed to be the default port of the received-protocol.
+
+Multiple Via field values represent each proxy or gateway that has
+forwarded the message. Each recipient MUST append its information such
+that the end result is ordered according to the sequence of forwarding
+applications.
+
+Comments MAY be used in the Via header field to identify the software of
+the recipient proxy or gateway, analogous to the User-Agent and Server
+header fields. However, all comments in the Via field are optional and
+MAY be removed by any recipient prior to forwarding the message.
+
+For example, a request message could be sent from an HTTP/1.0 user agent
+to an internal proxy code-named "fred", which uses HTTP/1.1 to forward
+the request to a public proxy at nowhere.com, which completes the
+request by forwarding it to the origin server at www.ics.uci.edu. The
+request received by www.ics.uci.edu would then have the following Via
+header field:
+
+ Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
+
+Proxies and gateways used as a portal through a network firewall SHOULD
+NOT, by default, forward the names and ports of hosts within the
+firewall region. This information SHOULD only be propagated if
+explicitly enabled. If not enabled, the received-by host of any host
+behind the firewall SHOULD be replaced by an appropriate pseudonym for
+that host.
+
+For organizations that have strong privacy requirements for hiding
+internal structures, a proxy MAY combine an ordered subsequence of Via
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 119]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+header field entries with identical received-protocol values into a
+single such entry. For example,
+
+ Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+
+ could be collapsed to
+
+ Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+
+Applications SHOULD NOT combine multiple entries unless they are all
+under the same organizational control and the hosts have already been
+replaced by pseudonyms. Applications MUST NOT combine entries which
+have different received-protocol values.
+
+ Note: The Via header field replaces the Forwarded header field
+ which was present in earlier drafts of this specification.
+
+
+18.48 Warning
+Warning headers are sent with responses using:
+
+ Warning = "Warning" ":" warn-code SP warn-agent SP warn-text
+ warn-code = 2DIGIT
+ warn-agent = ( host [ ":" port ] ) | pseudonym
+ ; the name or pseudonym of the server adding
+ ; the Warning header, for use in debugging
+ warn-text = quoted-string
+
+A response may carry more than one Warning header.
+
+The warn-text should be in a natural language and character set that is
+most likely to be intelligible to the human user receiving the
+response.
+This decision may be based on any available knowledge, such as the
+location of the cache or user, the Accept-Language field in a request,
+the Content-Language field in a response, etc. The default language is
+English and the default character set is ISO-8599-1.
+
+If a character set other than ISO-8599-1 is used, it must be encoded in
+the warn-text using the method described in RFC 1522 [14].
+
+Any server or cache may add Warning headers to a response. New Warning
+headers should be added after any existing Warning headers. A cache MUST
+NOT delete any Warning header that it received with a response.
+However,
+if a cache successfully validates a cache entry, it SHOULD remove any
+Warning headers previously attached to that entry. It MUST then add any
+Warning headers received in the validating response. In other words,
+Warning headers are those that would be attached to the most recent
+relevant response.
+
+When multiple Warning headers are attached to a response, the user agent
+SHOULD display as many of them as possible, in the order that they
+appear in the response. If it is not possible to display all of the
+warnings, the user agent should follow these heuristics:
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 120]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . Warnings that appear early in the response take priority over those
+ appearing later in the response.
+ . Warnings in the user's preferred character set take priority over
+ warnings in other character sets but with identical warn-codes and
+ warn-agents.
+Systems that generate multiple Warning headers should order them with
+this user-agent behavior in mind.
+
+This is a list of the currently-defined warn-codes, each with a
+recommended warn-text in English, and a description of its meaning.
+
+
+10 Response is stale
+ MUST be included whenever the returned response is stale. A cache may
+ add this warning to any response, but may never remove it until the
+ response is known to be fresh.
+
+11 Revalidation failed
+ MUST be included if a cache returns a stale response because an
+ attempt to revalidate the response failed, due to an inability to
+ reach the server. A cache may add this warning to any response, but
+ may never remove it until the response is successfully revalidated.
+
+12 Disconnected operation
+ SHOULD be included if the cache is intentionally disconnected from
+ the rest of the network for a period of time.
+
+99 Miscellaneous warning
+ The warning text may include arbitrary information to be presented to
+ a human user, or logged. A system receiving this warning MUST NOT
+ take any automated action.
+
+
+
+18.49 WWW-Authenticate
+The WWW-Authenticate response-header field MUST be included in 401
+(Unauthorized) response messages. The field value consists of at least
+one challenge that indicates the authentication scheme(s) and parameters
+applicable to the Request-URI.
+
+ WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
+
+The HTTP access authentication process is described in section 14. User
+agents MUST take special care in parsing the WWW-Authenticate field
+value if it contains more than one challenge, or if more than one WWW-
+Authenticate header field is provided, since the contents of a challenge
+may itself contain a comma-separated list of authentication parameters.
+
+
+19 Security Considerations
+This section is meant to inform application developers, information
+providers, and users of the security limitations in HTTP/1.1 as
+described by this document. The discussion does not include definitive
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 121]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+solutions to the problems revealed, though it does make some suggestions
+for reducing security risks.
+
+
+19.1 Authentication of Clients
+As mentioned in section 14, the Basic authentication scheme is not a
+secure method of user authentication, nor does it in any way protect the
+Entity-Body, which is transmitted in clear text across the physical
+network used as the carrier. HTTP does not prevent additional
+authentication schemes and encryption mechanisms from being employed to
+increase security or the addition of enhancements (such as schemes to
+use one-time passwords) to Basic authentication.
+
+The most serious flaw in Basic authentication is that it results in the
+essentially clear text transmission of the user's password over the
+physical network. It is this problem which Digest Authentication
+attempts to address.
+
+Because Basic authentication involves the clear text transmission of
+passwords it SHOULD never be used (without enhancements) to protect
+sensitive or valuable information.
+
+A common use of Basic authentication is for identification purposes --
+requiring the user to provide a user name and password as a means of
+identification, for example, for purposes of gathering accurate usage
+statistics on a server. When used in this way it is tempting to think
+that there is no danger in its use if illicit access to the protected
+documents is not a major concern. This is only correct if the server
+issues both user name and password to the users and in particular does
+not allow the user to choose his or her own password. The danger arises
+because naive users frequently reuse a single password to avoid the task
+of maintaining multiple passwords.
+
+If a server permits users to select their own passwords, then the threat
+is not only illicit access to documents on the server but also illicit
+access to the accounts of all users who have chosen to use their account
+password. If users are allowed to choose their own password that also
+means the server must maintain files containing the (presumably
+encrypted) passwords. Many of these may be the account passwords of
+users perhaps at distant sites. The owner or administrator of such a
+system could conceivably incur liability if this information is not
+maintained in a secure fashion.
+
+Basic Authentication is also vulnerable to spoofing by counterfeit
+servers. If a user can be led to believe that he is connecting to a
+host containing information protected by basic authentication when in
+fact he is connecting to a hostile server or gateway then the attacker
+can request a password, store it for later use, and feign an error.
+This type of attack is not possible with Digest Authentication[26].
+Server implementers SHOULD guard against the possibility of this sort of
+counterfeiting by gateways or CGI scripts. In particular it is very
+dangerous for a server to simply turn over a connection to a gateway
+since that gateway can then use the persistent connection mechanism to
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 122]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+engage in multiple transactions with the client while impersonating the
+original server in a way that is not detectable by the client.
+
+
+19.2 Safe Methods
+The writers of client software should be aware that the software
+represents the user in their interactions over the Internet, and should
+be careful to allow the user to be aware of any actions they may take
+which may have an unexpected significance to themselves or others.
+
+In particular, the convention has been established that the GET and HEAD
+methods should never have the significance of taking an action other
+than retrieval. These methods should be considered "safe. " This allows
+user agents to represent other methods, such as POST, PUT and DELETE, in
+a special way, so that the user is made aware of the fact that a
+possibly unsafe action is being requested.
+
+Naturally, it is not possible to ensure that the server does not
+generate side-effects as a result of performing a GET request; in fact,
+some dynamic resources consider that a feature. The important
+distinction here is that the user did not request the side-effects, so
+therefore cannot be held accountable for them.
+
+
+19.3 Abuse of Server Log Information
+A server is in the position to save personal data about a user's
+requests which may identify their reading patterns or subjects of
+interest. This information is clearly confidential in nature and its
+handling may be constrained by law in certain countries. People using
+the HTTP protocol to provide data are responsible for ensuring that such
+material is not distributed without the permission of any individuals
+that are identifiable by the published results.
+
+
+19.4 Transfer of Sensitive Information
+Like any generic data transfer protocol, HTTP cannot regulate the
+content of the data that is transferred, nor is there any a priori
+method of determining the sensitivity of any particular piece of
+information within the context of any given request. Therefore,
+applications SHOULD supply as much control over this information as
+possible to the provider of that information. Four header fields are
+worth special mention in this context: Server, Via, Referer and From.
+
+Revealing the specific software version of the server may allow the
+server machine to become more vulnerable to attacks against software
+that is known to contain security holes. Implementers SHOULD make the
+Server header field a configurable option.
+
+Proxies which serve as a portal through a network firewall SHOULD take
+special precautions regarding the transfer of header information that
+identifies the hosts behind the firewall. In particular, they SHOULD
+remove, or replace with sanitized versions, any Via fields generated
+behind the firewall.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 123]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The Referer field allows reading patterns to be studied and reverse
+links drawn. Although it can be very useful, its power can be abused if
+user details are not separated from the information contained in the
+Referer. Even when the personal information has been removed, the
+Referer field may indicate a private document's URI whose publication
+would be inappropriate.
+
+The information sent in the From field might conflict with the user's
+privacy interests or their site's security policy, and hence it SHOULD
+NOT be transmitted without the user being able to disable, enable, and
+modify the contents of the field. The user MUST be able to set the
+contents of this field within a user preference or application defaults
+configuration.
+
+We suggest, though do not require, that a convenient toggle interface be
+provided for the user to enable or disable the sending of From and
+Referer information.
+
+
+19.5 Attacks Based On File and Path Names
+Implementations of HTTP origin servers SHOULD be careful to restrict the
+documents returned by HTTP requests to be only those that were intended
+by the server administrators. If an HTTP server translates HTTP URIs
+directly into file system calls, the server MUST take special care not
+to serve files that were not intended to be delivered to HTTP clients.
+For example, UNIX, Microsoft Windows, and other operating systems use
+".." as a path component to indicate a directory level above the current
+one. On such a system, an HTTP server MUST disallow any such construct
+in the Request-URI if it would otherwise allow access to a resource
+outside those intended to be accessible via the HTTP server. Similarly,
+files intended for reference only internally to the server (such as
+access control files, configuration files, and script code) MUST be
+protected from inappropriate retrieval, since they might contain
+sensitive information. Experience has shown that minor bugs in such HTTP
+server implementations have turned into security risks.
+
+
+19.6 Personal Information
+HTTP clients are often privy to large amounts of personal information
+(e.g. the user's name, location, mail address, passwords, encryption
+keys, etc.), and SHOULD be very careful to prevent unintentional leakage
+of this information via the HTTP protocol to other sources. We very
+strongly recommend that a convenient interface be provided for the user
+to control dissemination of such information, and that designers and
+implementers be particularly careful in this area. History shows that
+errors in this area are often both serious security and/or privacy
+problems, and often generate very adverse publicity for the
+implementer's company.
+
+
+19.7 Privacy Issues Connected to Accept headers
+Accept request headers can reveal information about the user to all
+servers which are accessed. The Accept-Language header in particular
+can reveal information the user would consider to be of a private
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 124]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+nature, because the understanding of particular languages is often
+strongly correlated to the membership of a particular ethnic group.
+User agents which offer the option to configure the contents of an
+Accept-Language header to be sent in every request are strongly
+encouraged to let the configuration process include a message which
+makes the user aware of the loss of privacy involved.
+
+An approach that limits the loss of privacy would be for a user agent to
+omit the sending of Accept-Language headers by default, and to ask the
+user whether it should start sending Accept-Language headers to a server
+if it detects, by looking for any Vary or Alternates response headers
+generated by the server, that such sending could improve the quality of
+service.
+
+Elaborate user-customized accept header fields sent in every request, in
+particular if these include quality values, can be used by servers as
+relatively reliable and long-lived user identifiers. Such user
+identifiers would allow content providers to do click-trail tracking,
+and would allow collaborating content providers to match cross-server
+click-trails or form submissions of individual users. Note that for
+many users not behind a proxy, the network address of the host running
+the user agent will also serve as a long-lived user identifier. In
+environments where proxies are used to enhance privacy, user agents
+should be conservative in offering accept header configuration options
+to end users. As an extreme privacy measure, proxies could filter the
+accept headers in relayed requests. General purpose user agents which
+provide a high degree of header configurability should warn users about
+the loss of privacy which can be involved.
+
+
+19.8 DNS Spoofing
+Clients using HTTP rely heavily on the Domain Name Service, and are thus
+generally prone to security attacks based on the deliberate miss-
+association of IP addresses and DNS names. The deployment of DNSSEC
+should help this situation. In advance of this deployment, however,
+clients need to be cautious in assuming the continuing validity of an IP
+number/DNS name association.
+
+In particular, HTTP clients SHOULD rely on their name resolver for
+confirmation of an IP number/DNS name association, rather than caching
+the result of previous host name lookups. Many platforms already can
+cache host name lookups locally when appropriate, and they SHOULD be
+configured to do so. These lookups should be cached, however, only when
+the TTL (Time To Live) information reported by the name server makes it
+likely that the cached information will remain useful.
+
+If HTTP clients cache the results of host name lookups in order to
+achieve a performance improvement, they MUST observe the TTL information
+reported by DNS.
+
+If HTTP clients do not observe this rule, they could be spoofed when a
+previously-accessed server's IP address changes. As renumbering is
+expected to become increasingly common, the possibility of this form of
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 125]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+attack will grow. Observing this requirement thus reduces this
+potential security vulnerability.
+
+This requirement also improves the load-balancing behavior of clients
+for replicated servers using the same DNS name and reduces the
+likelihood of a user's experiencing failure in accessing sites which use
+that strategy.
+
+
+19.9 Location Headers and Spoofing
+If a single server supports multiple organizations that do not trust one
+another, then it must check the values of Location and Content-Location
+headers in responses that are generated under control of said
+organizations to make sure that they do not attempt to invalidate
+resources over which they have no authority.
+
+
+20 Acknowledgments
+This specification makes heavy use of the augmented BNF and generic
+constructs defined by David H. Crocker for RFC 822 . Similarly, it
+reuses many of the definitions provided by Nathaniel Borenstein and Ned
+Freed for MIME . We hope that their inclusion in this specification will
+help reduce past confusion over the relationship between HTTP and
+Internet mail message formats.
+
+The HTTP protocol has evolved considerably over the past four years. It
+has benefited from a large and active developer community--the many
+people who have participated on the www-talk mailing list--and it is
+that community which has been most responsible for the success of HTTP
+and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau,
+Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip
+M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
+Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
+recognition for their efforts in defining early aspects of the
+protocol.
+
+This document has benefited greatly from the comments of all those
+participating in the HTTP-WG. In addition to those already mentioned,
+the following individuals have contributed to this specification:
+
+ Gary Adams Harald Tveit Alvestrand
+ Keith Ball Brian Behlendorf
+ Paul Burchard Maurizio Codogno
+ Mike Cowlishaw Roman Czyborra
+ Michael A. Dolan Alan Freier
+ Marc Hedlund Koen Holtman
+ Alex Hopmann Bob Jernigan
+ Shel Kaphan Rohit Khare
+ Martijn Koster Alexei Kosut
+ David M. Kristol Daniel LaLiberte
+ Paul J. Leach Albert Lunde
+ John C. Mallery Jean-Philippe Martin-Flatin
+ Larry Masinter Mitra
+ Gavin Nicol Scott Powers
+ Bill Perry Jeffrey Perry
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 126]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ Owen Rees Luigi Rizzo
+ David Robinson Marc Salomon
+ Rich Salz Jim Seidman
+ Chuck Shotton Eric W. Sink
+ Simon E. Spero Richard N. Taylor
+ Robert S. Thau Francois Yergeau
+ Mary Ellen Zurko David Morris
+ Greg Herlihy Bill (BearHeart) Weinman
+ Allan M. Schiffman
+
+
+Much of the content and presentation of the caching design is due to
+suggestions and comments from individuals including: Shel Kaphan, Paul
+Leach, Koen Holtman, David Morris, Larry Masinter, and Roy Fielding.
+
+Most of the specification of ranges is based on work originally done by
+Ari Luotonen and John Franks, with additional input from Steve Zilles
+and Roy Fielding.
+
+XXX need acks for subgroup work.
+
+
+
+
+21 References
+
+[1] H. Alvestrand. "Tags for the identification of languages." RFC
+
+ 1766, UNINETT, March 1995.
+
+[2] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey,
+ B. Alberti. "The Internet Gopher Protocol: (a distributed document
+
+ search and retrieval protocol)", RFC 1436, University of Minnesota,
+ March 1993.
+
+[3] T. Berners-Lee. "Universal Resource Identifiers in WWW" A
+
+ Unifying Syntax for the Expression of Names and Addresses of Objects
+ on the Network as used in the World-Wide Web." RFC 1630, CERN, June
+ 1994.
+
+[4] T. Berners-Lee, L. Masinter, M. McCahill.
+ "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC,
+
+ University of Minnesota, December 1994.
+
+[5] T. Berners-Lee, D. Connolly.
+ "HyperText Markup Language Specification - 2.0." RFC 1866, MIT/LCS,
+
+ November 1995.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 127]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+[6] T. Berners-Lee, R. Fielding, H. Frystyk.
+ "Hypertext Transfer Protocol - HTTP/1.0." Work in Progress (draft-
+
+ ietf-http-v10-spec-04.txt), MIT/LCS, UC Irvine, September 1995.
+
+[7] N. Borenstein, N. Freed.
+ "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
+
+ for Specifying and Describing the Format of Internet Message Bodies."
+ RFC 1521, Bellcore, Innosoft, September 1993.
+
+[8] R. Braden.
+ "Requirements for Internet hosts - application and support." STD 3,
+
+ RFC 1123, IETF, October 1989.
+
+[9] D. H. Crocker.
+ "Standard for the Format of ARPA Internet Text Messages." STD 11, RFC
+
+ 822, UDEL, August 1982.
+
+[10] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J.
+ Sui, M. Grinbaum. "WAIS Interface Protocol Prototype Functional
+ Specification." (v1.5), Thinking Machines Corporation, April 1990.
+
+[11] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC
+
+ Irvine, June 1995.
+
+[12] M. Horton, R. Adams.
+ "Standard for interchange of USENET messages." RFC 1036 (Obsoletes
+
+ RFC 850), AT&T Bell Laboratories, Center for Seismic Studies,
+ December 1987.
+
+[13] B. Kantor, P. Lapsley. "Network News Transfer Protocol A
+
+ Proposed Standard for the Stream-Based Transmission of News." RFC
+ 977, UC San Diego, UC Berkeley, February 1986.
+
+[14] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part Two
+
+ : Message Header Extensions for Non-ASCII Text." RFC 1522, University
+ of Tennessee, September 1993.
+
+[15] E. Nebel, L. Masinter. "Form-based File Upload in HTML." RFC
+
+ 1867, Xerox Corporation, November 1995.
+
+[16] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821,
+
+ USC/ISI, August 1982.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 128]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+[17] J. Postel. "Media Type Registration Procedure." RFC 1590,
+
+ USC/ISI, March 1994.
+
+[18] J. Postel, J. K. Reynolds. "File Transfer Protocol (FTP)" STD
+9,
+
+ RFC 959, USC/ISI, October 1985.
+
+[19] J. Reynolds, J. Postel. "Assigned Numbers." STD 2, RFC 1700,
+
+ USC/ISI, October 1994.
+
+[20] K. Sollins, L. Masinter.
+ "Functional Requirements for Uniform Resource Names." RFC 1737,
+
+ MIT/LCS, Xerox Corporation, December 1994.
+
+[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
+ Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
+
+[22] ISO-8859. International Standard -- Information Processing --
+ 8-bit Single-Byte Coded Graphic Character Sets --
+ Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
+ Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
+ Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
+ Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
+ Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
+ Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
+ Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
+ Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
+ Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
+
+[23] Meyers, M. Rose "The Content-MD5 Header Field." RFC 1864,
+
+ Carnegie Mellon, Dover Beach Consulting, October, 1995.
+
+[24] B. Carpenter, Y. Rekhter, "Renumbering Needs Work". RFC 1900,
+
+ IAB, February 1996.
+
+[25] Gzip is available from the GNU project at
+ <URL:ftp://prep.ai.mit.edu/pub/gnu/>. A more formal specification is
+
+ currently a work in progress.
+
+[26] Work In Progress for Digest authentication of the IETF HTTP
+ working group.
+
+[27] TBS, Work in progress (XXX should put RFC in here_ )
+
+[28] Mills, D, "Network Time Protocol, Version 3", Specification,
+
+ Implementation and Analysis RFC 1305, University of Delaware, March,
+ 1992.
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 129]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+[29] Work in progress of the HTTP working group (XXX is this correct
+ reference for incomplete work?).
+
+[30] S. Spero. "Analysis of HTTP Performance Problems"
+ <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>
+
+[31] E. Rescorla, A. Schiffman "The Secure HyperText Transfer
+ Protocol" Internet-Draft (work in progress).
+
+[32] A. Freier, P Karlton, P. Kocher. "SSL Version 3.0" Internet-
+ Draft" (work in progress).
+
+[33] Jeffrey C. Mogul. "The Case for Persistent-Connection HTTP". In
+ Proc.SIGCOMM '95 Symposium on Communications Architectures and
+ Protocols, pages 299-313. Cambridge, MA, August, 1995.
+
+[34] Jeffrey C. Mogul. "The Case for Persistent-Connection HTTP".
+ Research, Report 95/4, Digital Equipment Corporation Western Research
+ Laboratory, May, 1995.,
+ <URL
+ :http://www.research.digital.com/wrl/techreports/abstracts/95.4.html>
+
+
+[35] Work in progress of the HTTP working group on state management.
+
+22 Authors' Addresses
+
+Roy T. Fielding
+
+Department of Information and Computer Science
+University of California
+Irvine, CA 92717-3425, USA
+Fax: +1 (714) 824-4056
+Email: fielding@ics.uci.edu
+
+Henrik Frystyk Nielsen
+
+W3 Consortium
+MIT Laboratory for Computer Science
+545 Technology Square
+Cambridge, MA 02139, USA
+Fax: +1 (617) 258 8682
+Email: frystyk@w3.org
+
+Tim Berners-Lee
+
+Director, W3 Consortium
+MIT Laboratory for Computer Science
+545 Technology Square
+Cambridge, MA 02139, USA
+Fax: +1 (617) 258 8682
+Email: timbl@w3.org
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 130]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+Jim Gettys
+
+MIT Laboratory for Computer Science
+545 Technology Square
+Cambridge, MA 02139, USA
+Fax: +1 (617) 258 8682
+Email: jg@w3.org
+
+Jeffrey C. Mogul
+
+Western Research Laboratory
+Digital Equipment Corporation
+250 University Avenue
+Palo Alto, California, 94305, U.S.A.
+Email: mogul@wrl.dec.com
+
+
+
+
+23 Appendices
+These appendices are provided for informational reasons only -- they do
+not form a part of the HTTP/1.1 specification.
+
+
+23.1 Internet Media Type message/http
+In addition to defining the HTTP/1.1 protocol, this document serves as
+the specification for the Internet media type "message/http". The
+following is to be registered with IANA .
+
+ Media Type name: message
+ Media subtype name: http
+ Required parameters: none
+ Optional parameters: version, msgtype
+
+ version: The HTTP-Version number of the enclosed message
+ (e.g., "1.1"). If not present, the version can be
+ determined from the first line of the body.
+
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first
+ line of the body.
+
+ Encoding considerations: only "7bit", "8bit", or "binary" are
+ permitted
+
+ Security considerations: none
+
+
+23.2 Tolerant Applications
+Although this document specifies the requirements for the generation of
+HTTP/1.1 messages, not all applications will be correct in their
+implementation. We therefore recommend that operational applications be
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 131]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+tolerant of deviations whenever those deviations can be interpreted
+unambiguously.
+
+Clients SHOULD be tolerant in parsing the Status-Line and servers
+tolerant when parsing the Request-Line. In particular, they SHOULD
+accept any amount of SP or HT characters between fields, even though
+only a single SP is required.
+
+The line terminator for HTTP-header fields is the sequence CRLF.
+However, we recommend that applications, when parsing such headers,
+recognize a single LF as a line terminator and ignore the leading CR.
+
+
+23.3 Differences Between HTTP Bodies and RFC 1521 Internet Message Bodies
+HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822
+) and the Multipurpose Internet Mail Extensions (MIME ) to allow
+entities to be transmitted in an open variety of representations and
+with extensible mechanisms. However, RFC 1521 discusses mail, and HTTP
+has a few features that are different than those described in RFC 1521.
+These differences were carefully chosen to optimize performance over
+binary connections, to allow greater freedom in the use of new media
+types, to make date comparisons easier, and to acknowledge the practice
+of some early HTTP servers and clients.
+
+At the time of this writing, it is expected that RFC 1521 will be
+revised. The revisions may include some of the practices found in
+HTTP/1.1 but not in RFC 1521.
+
+This appendix describes specific areas where HTTP differs from RFC
+1521.
+Proxies and gateways to strict MIME environments SHOULD be aware of
+these differences and provide the appropriate conversions where
+necessary. Proxies and gateways from MIME environments to HTTP also need
+to be aware of the differences because some conversions may be
+required.
+
+
+23.3.1 Conversion to Canonical Form
+RFC 1521 requires that an Internet mail entity be converted to canonical
+form prior to being transferred, as described in Appendix G of RFC 1521
+. Section 7.7.1 of this document describes the forms allowed for
+subtypes of the "text" media type when transmitted over HTTP. RFC 1521
+requires that content with a typeof "text" represent line breaks as
+CRLF and forbids the use of CR or LF outside of line break sequences.
+HTTP allows CRLF, bare CR, and bare LF to indicate a line break within
+text content when a message is transmitted over HTTP.
+
+Where it is possible, a proxy or gateway from HTTP to a strict RFC 1521
+environment SHOULD translate all line breaks within the text media types
+described in section 7.7.1 of this document to the RFC 1521 canonical
+form of CRLF. Note, however, that this may be complicated by the
+presence of a Content-Encoding and by the fact that HTTP allows the use
+of some character sets which do not use octets 13 and 10 to represent CR
+and LF, as is the case for some multi-byte character sets.
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 132]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+23.3.2 Conversion of Date Formats
+HTTP/1.1 uses a restricted set of date formats (section 7.3.1) to
+simplify the process of date comparison. Proxies and gateways from other
+protocols SHOULD ensure that any Date header field present in a message
+conforms to one of the HTTP/1.1 formats and rewrite the date if
+necessary.
+
+
+23.3.3 Introduction of Content-Encoding
+RFC 1521 does not include any concept equivalent to HTTP/1.1's Content-
+Encoding header field. Since this acts as a modifier on the media type,
+proxies and gateways from HTTP to MIME-compliant protocols MUST either
+change the value of the Content-Type header field or decode the Entity-
+Body before forwarding the message. (Some experimental applications of
+Content-Type for Internet mail have used a media-type parameter of
+";conversions=<content-coding>" to perform an equivalent function as
+Content-Encoding. However, this parameter is not part of RFC 1521.)
+
+
+23.3.4 No Content-Transfer-Encoding
+HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
+1521.
+Proxies and gateways from MIME-compliant protocols to HTTP MUST remove
+any non-identity CTE ("quoted-printable" or "base64") encoding prior to
+delivering the response message to an HTTP client.
+
+Proxies and gateways from HTTP to MIME-compliant protocols are
+responsible for ensuring that the message is in the correct format and
+encoding for safe transport on that protocol, where "safe transport" is
+defined by the limitations of the protocol being used. Such a proxy or
+gateway SHOULD label the data with an appropriate Content-Transfer-
+Encoding if doing so will improve the likelihood of safe transport over
+the destination protocol.
+
+
+23.3.5 HTTP Header Fields in Multipart Body-Parts
+In RFC 1521, most header fields in multipart body-parts are generally
+ignored unless the field name begins with "Content-". In HTTP/1.1,
+multipart body-parts may contain any HTTP header fields which are
+significant to the meaning of that part.
+
+
+23.3.6 Introduction of Transfer-Encoding
+HTTP/1.1 introduces the Transfer-Encoding header field (section 18.43).
+Proxies/gateways MUST remove any transfer coding prior to forwarding a
+message via a MIME-compliant protocol. The process for decoding the
+"chunked" transfer coding (section 7.6) can be represented in pseudo-
+code as:
+
+ length := 0
+ read chunk-size and CRLF
+ while (chunk-size > 0) {
+ read chunk-data and CRLF
+ append chunk-data to Entity-Body
+ length := length + chunk-size
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 133]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ read chunk-size and CRLF
+ }
+ read entity-header
+ while (entity-header not empty) {
+ append entity-header to existing header fields
+ read entity-header
+ }
+ Content-Length := length
+ Remove "chunked" from Transfer-Encoding
+
+
+
+
+23.3.7 MIME-Version
+HTTP is not a MIME-compliant protocol (see Appendix 23.3). However,
+HTTP/1.1 messages may include a single MIME-Version general-header field
+to indicate what version of the MIME protocol was used to construct the
+message. Use of the MIME-Version header field indicates that the message
+is in full compliance with the MIME protocol (as defined in ).
+Proxies/gateways are responsible for ensuring full compliance (where
+possible) when exporting HTTP messages to strict MIME environments.
+
+ MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+MIME version "1.0" is the default for use in HTTP/1.1. However,
+HTTP/1.1
+message parsing and semantics are defined by this document and not the
+MIME specification.
+
+
+23.4 Changes from HTTP/1.0
+This section will summarize major differences between versions HTTP/1.0
+and HTTP/1.1.
+
+
+23.4.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses
+The requirements that clients and servers support the Host request-
+header, report an error if the Host request-header (section 18.24) is
+missing from an HTTP/1.1 request, and accept absolute URIs (Section
+9.1.2) are among the most important changes from HTTP/1.0.
+
+In HTTP/1.0 there is a one-to-one relationship of IP addresses and
+servers. There is no other way to distinguish the intended server of a
+request than the IP address to which that request is directed. The
+HTTP/1.1 change will allow the Internet, once HTTP/1.0 clients and
+servers are no longer common, to support multiple Web sites from a
+single IP address, greatly simplifying large operational Web servers,
+where allocation of many IP addresses to a single host has created
+serious problems. The Internet will also be able to recover the IP
+addresses that have been used for the sole purpose of allowing root-
+level domain names to be used in HTTP URLs. Given the rate of growth of
+the Web, and the number of servers already deployed, it is extremely
+important that implementations of HTTP/1.1 correctly implement these new
+requirements:
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 134]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ . both clients and servers MUST support the Host request-header
+
+ . Host request-headers are required in HTTP/1.1 requests.
+
+ . servers MUST report an error if an HTTP/1.1 request does not
+ include a Host request-header
+
+ . servers MUST accept absolute URIs
+
+23.5 Additional Features
+This appendix documents protocol elements used by some existing HTTP
+implementations, but not consistently and correctly across most
+HTTP/1.1
+applications. Implementers should be aware of these features, but cannot
+rely upon their presence in, or interoperability with, other HTTP/1.1
+applications. Some of these describe proposed experimental features,
+and some describe features that experimental deployment found lacking
+that are now addressed in the base HTTP/1.1 specification.
+
+
+23.5.1 Additional Request Methods
+
+23.5.1.1 PATCH
+The PATCH method is similar to PUT except that the entity contains a
+list of differences between the original version of the resource
+identified by the Request-URI and the desired content of the resource
+entity after the PATCH action has been applied. The list of differences
+is in a format defined by the media type of the entity (e.g.,
+"application/diff") and MUST include sufficient information to allow the
+server to recreate the changes necessary to convert the original version
+of the resource entity to the desired version.
+
+If the request passes through a cache and the Request-URI identifies a
+currently cached entity, that entity MUST be removed from the cache.
+Responses to this method are not cachable.
+
+For compatibility with HTTP/1.0 applications, all PATCH requests MUST
+include a valid Content-Length header field unless the server is known
+to be HTTP/1.1 compliant. When sending a PATCH request to an HTTP/1.1
+server, a client MUST use a valid Content-Length or the "chunked"
+Transfer-Encoding. The server SHOULD respond with a 400 (Bad Request)
+message if it cannot determine the length of the request message's
+content, or with 411 (Length Required) if it wishes to insist on
+receiving a valid Content-Length.
+
+The actual method for determining how the patched resource is placed,
+and what happens to its predecessor, is defined entirely by the origin
+server. If the original version of the resource being patched included a
+Content-Version header field, the request entity MUST include a
+Derived-
+From header field corresponding to the value of the original Content-
+Version header field. Applications are encouraged to use these fields
+for constructing versioning relationships and resolving version
+conflicts.
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 135]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+PATCH requests must obey the entity transmission requirements set out in
+section 13.4.1.
+
+Caches that implement PATCH should invalidate cached responses as
+defined in section 16.10 for PUT.
+
+
+23.5.1.2 LINK
+The LINK method establishes one or more Link relationships between the
+existing resource identified by the Request-URI and other existing
+resources. The difference between LINK and other methods allowing links
+to be established between resources is that the LINK method does not
+allow any Entity-Body to be sent in the request and does not directly
+result in the creation of new resources.
+
+If the request passes through a cache and the Request-URI identifies a
+currently cached entity, that entity MUST be removed from the cache.
+Responses to this method are not cachable.
+
+Caches that implement LINK should invalidate cached responses as defined
+in section 16.10 for PUT.
+
+
+23.5.1.3 UNLINK
+The UNLINK method removes one or more Link relationships from the
+existing resource identified by the Request-URI. These relationships may
+have been established using the LINK method or by any other method
+supporting the Link header. The removal of a link to a resource does not
+imply that the resource ceases to exist or becomes inaccessible for
+future references.
+
+If the request passes through a cache and the Request-URI identifies a
+currently cached entity, that entity MUST be removed from the cache.
+Responses to this method are not cachable.
+
+Caches that implement UNLINK should invalidate cached responses as
+defined in section 16.10 for PUT.
+
+
+23.5.1.4 PUT
+To support the PATCH method, if the entity being PUT was derived from an
+existing resource which included a Content-Version header field, the new
+entity MUST include a Derived-From header field corresponding to the
+value of the original Content-Version header field. Multiple Derived-
+From values may be included if the entity was derived from multiple
+resources with Content-Version information. Applications are encouraged
+to use these fields for constructing versioning relationships and
+resolving version conflicts.
+
+
+23.5.2 Additional Header Field Definitions
+
+23.5.2.1 Content-Version
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 136]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+The Content-Version entity-header field defines the version tag
+associated with a rendition of an evolving entity. Together with the
+Derived-From field described in section 23.5.2.2, it allows a group of
+people to work simultaneously on the creation of a work as an iterative
+process. The field SHOULD be used to allow evolution of a particular
+work along a single path. It SHOULD NOT be used to indicate derived
+works or renditions in different representations. It MAY also me used as
+an opaque value for comparing a cached entity's version with that of the
+current resource entity.
+
+ Content-Version = "Content-Version" ":" quoted-string
+
+Examples of the Content-Version field include:
+
+ Content-Version: "2.1.2"
+ Content-Version: "Fred 19950116-12:26:48"
+ Content-Version: "2.5a4-omega7"
+
+The value of the Content-Version field SHOULD be considered opaque to
+all parties but the origin server. A user agent MAY suggest a value for
+the version of an entity transferred via a PUT request; however, only
+the origin server can reliably assign that value.
+
+
+23.5.2.2 Derived-From
+The Derived-From entity-header field can be used to indicate the version
+tag of the resource from which the enclosed entity was derived before
+modifications were made by the sender. This field is used to help manage
+the process of merging successive changes to a resource, particularly
+when such changes are being made in parallel and from multiple sources.
+
+ Derived-From = "Derived-From" ":" quoted-string
+
+An example use of the field is:
+
+ Derived-From: "2.1.1"
+
+The Derived-From field is required for PUT and PATCH requests if the
+entity being sent was previously retrieved from the same URI and a
+Content-Version header was included with the entity when it was last
+retrieved.
+
+
+23.5.2.3 Link
+The Link entity-header field provides a means for describing a
+relationship between two resources, generally between the requested
+resource and some other resource. An entity MAY include multiple Link
+values. Links at the metainformation level typically indicate
+relationships like hierarchical structure and navigation paths. The Link
+field is semantically equivalent to the <LINK> element in HTML .
+
+ Link = "Link" ":" #("<" URI ">" *( ";" link-param )
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 137]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+ link-param = ( ( "rel" "=" relationship )
+ | ( "rev" "=" relationship )
+ | ( "title" "=" quoted-string )
+ | ( "anchor" "=" <"> URI <"> )
+ | ( link-extension ) )
+
+ link-extension = token [ "=" ( token | quoted-string ) ]
+
+ relationship = sgml-name
+ | ( <"> sgml-name *( SP sgml-name) <"> )
+
+ sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
+
+Relationship values are case-insensitive and MAY be extended within the
+constraints of the sgml-name syntax. The title parameter MAY be used to
+label the destination of a link such that it can be used as
+identification within a human-readable menu. The anchor parameter MAY be
+used to indicate a source anchor other than the entire current
+resource,
+such as a fragment of this resource or a third resource.
+
+Examples of usage include:
+
+ Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
+
+ Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"
+
+The first example indicates that chapter2 is previous to this resource
+in a logical navigation path. The second indicates that the person
+responsible for making the resource available is identified by the given
+e-mail address.
+
+
+23.5.2.4 URI
+The URI header field has, in past versions of this specification, been
+used as a combination of the existing Location, Content-Location, and
+Alternates header fields. Its primary purpose has been to include a list
+of additional URIs for the resource, including names and mirror
+locations. However, it has become clear that the combination of many
+different functions within this single field has been a barrier to
+consistently and correctly implementing any of those functions.
+Furthermore, we believe that the identification of names and mirror
+locations would be better performed via the Link header field. The URI
+header field is therefore deprecated in favor of those other fields.
+
+ URI-header = "URI" ":" 1#( "<" URI ">" )
+
+
+23.5.2.5 Compatibility with HTTP/1.0 Persistent Connections
+Some clients and servers may wish to be compatible with some previous
+implementations of persistent connections in HTTP/1.0 clients and
+servers. These implementations are faulty, and the new facilities in
+HTTP/1.1 are designed to rectify these problems. The fear was that
+some existing 1.0 clients may be sending Keep-Alive to a proxy server
+that doesn't understand Connection, which would then erroneously forward
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 138]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+it to the next inbound server, which would establish the Keep-Alive
+connection and result in a dead 1.0 proxy waiting for the close on the
+response. The result is that 1.0 clients must be prevented from using
+Keep-Alive when talking to proxies.
+
+However, talking to proxies is the most important use of persistent
+connections, so that is clearly unacceptable. Therefore, we need some
+other mechanism for indicating a persistent connection is desired, which
+is safe to use even when talking to an old proxy that ignores
+Connection. As it turns out, there are two ways to accomplish that:
+
+1.
+ Introduce a new keyword (persist) which is declared to be valid only
+ when received from an HTTP/1.1 message.
+
+2.
+ Declare persistence to be the default for HTTP/1.1 messages and
+ introduce a new keyword (close) for declaring non-persistence.
+
+The following describes the original, buggy form of persistent
+connections.
+
+When connecting to an origin server an HTTP client MAY send the Keep-
+Alive connection-token in addition to the Persist connection-token:
+
+ Connection: Keep-Alive,Persist
+
+An HTTP/1.0 server would then respond with the Keep-Alive connection
+token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
+persistent connection.
+
+An HTTP/1.1 server may also establish persistent connections with
+HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
+However, a persistent connection with an HTTP/1.0 client cannot make use
+of the chunked transfer-coding, and therefore MUST use a Content-Length
+for marking the ending boundary of each Entity-Body.
+
+A client MUST NOT send the Keep-Alive connection token to a proxy server
+as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 for parsing
+the Connection header field.
+
+
+23.5.2.5.1 The Keep-Alive Header
+When the Keep-Alive connection-token has been transmitted with a request
+or a response a Keep-Alive header field MAY also be included. The Keep-
+Alive header field takes the following form:
+
+ Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
+
+ keepalive-param = param-name "=" value
+
+The Keep-Alive header itself is optional, and is used only if a
+parameter is being sent. HTTP/1.1 does not define any parameters.
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 139]
+
+
+
+
+INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
+
+
+If the Keep-Alive header is sent, the corresponding connection token
+MUST be transmitted. The Keep-Alive header MUST be ignored if received
+without the connection token.
+
+
+23.5.3 Compatibility with Previous Versions
+It is beyond the scope of a protocol specification to mandate compliance
+with previous versions. HTTP/1.1 was deliberately designed, however, to
+make supporting previous versions easy. While we are contemplating a
+separate document containing advice to implementers, we feel it worth
+noting that at the time of composing this specification, we would expect
+commercial HTTP/1.1 servers to:
+
+
+ . recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
+ requests;
+
+ . understand any valid request in the format of HTTP/0.9, 1.0, or
+ 1.1;
+
+ . respond appropriately with a message in the same major version used
+ by the client.
+And we would expect HTTP/1.1 clients to:
+
+
+ . recognize the format of the Status-Line for HTTP/1.0 and 1.1
+ responses;
+
+ . understand any valid response in the format of HTTP/0.9, 1.0, or
+ 1.1.
+For most implementations of HTTP/1.0, each connection is established by
+the client prior to the request and closed by the server after sending
+the response. A few implementations implement the Keep-Alive version of
+persistent connections described in section 23.5.2.5.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 140]
+
+
+
--- /dev/null
+
+
+
+
+INTERNET-DRAFT Martin Hamilton
+draft-ietf-ids-dnsnames-00.txt Loughborough University
+Expires in six months Russ Wright
+ Lawrence Berkeley Laboratory
+ May 1996
+
+
+ Use of DNS Aliases for Network Services
+ Filename: draft-ietf-ids-dnsnames-00.txt
+
+
+Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-
+ Drafts as reference material or to cite them other than as ``work
+ in progress.''
+
+ To learn the current status of any Internet-Draft, please check
+ the ``1id-abstracts.txt'' listing contained in the Internet-
+ Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
+ (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
+ Coast), or ftp.isi.edu (US West Coast).
+
+Abstract
+
+ It has become a common practice to use symbolic names (usually
+ CNAMEs) in the Domain Name Service (DNS - [1,2]) to refer to network
+ services such as anonymous FTP [3] servers, Gopher [4] servers, and
+ most notably World-Wide Web HTTP [5] servers. This is desirable for
+ a number of reasons. It provides a way of moving services from one
+ machine to another transparently, and a mechanism by which people or
+ agents may programatically discover that an organization runs, say, a
+ World-Wide Web server.
+
+ Although this approach has been almost universally adopted, there is
+ no standards document or similar specification for these commonly
+ used names. This document seeks to rectify this situation by
+ gathering together the extant "folklore" on naming conventions, and
+ proposes a mechanism for accommodating new protocols. Distribution
+ of this document is unlimited. Comments should be sent to the IETF
+ Integrated Directory Services mailing list, ietf-ids@umich.edu, or
+
+
+
+ [Page 1]
+\f
+INTERNET-DRAFT May 1996
+
+
+ directly to the authors.
+
+1. Rationale
+
+ In order to locate the network services offered at a particular
+ Internet domain one is faced with the choice of selecting from a
+ growing number of centralized databases - typically Web or Usenet
+ News "wanderers", or attempting to infer the existence of network
+ services from whatever DNS information may be available. The former
+ approach is not practical in some cases, notably when the entity
+ seeking service information is a program.
+
+ Perhaps the most visible example of the latter approach at work is in
+ the case of World-Wide Web HTTP servers. It is common practice to
+ try prefixing the domain name of an organization with "http://www."
+ in order to reach its World-Wide Web site, e.g. taking "hivnet.fr"
+ and arriving at "http://www.hivnet.fr." Some popular World-Wide Web
+ browsers have gone so far as to provide automatic support for this
+ domain name expansion.
+
+ Ideally, the DNS or some complementary directory service would
+ provide a means for programs to determine automatically the network
+ services which are offered at a particular Internet domain, the
+ protocols which are used to deliver them, and other technical
+ information such as TCP [6] and UDP [7] port numbers.
+
+ Unfortunately, although much work has been done on developing "yellow
+ pages" directory service technologies, and on attempting to define
+ new types of DNS resource record to provide this type of information,
+ there is no widely agreed upon or widely deployed solution to the
+ problem - except in a small number of cases.
+
+ The first case is where the DNS already provides a lookup capability
+ for the type of information being sought after. For example: Mail
+ Exchanger (MX) records specify how mail to a particular domain should
+ be routed [8], the Start of Authority (SOA) records make it possible
+ to determine who is responsible for a given domain, and Name Server
+ (NS) records indicate which hosts provide DNS name service for a
+ given domain.
+
+ The second case is where the DNS does not provide an appropriate
+ lookup capability, but there is some widely accepted convention for
+ finding this information. Some use has been made of Text (TXT)
+ records in this scenario, but in the vast majority of cases a
+ Canonical Name (CNAME) or Address (A) record pointer is used to
+ indicate the host or hosts which provide the service. This document
+ proposes a slight formalization of this well-known alias approach.
+
+
+
+
+ [Page 2]
+\f
+INTERNET-DRAFT May 1996
+
+
+ It should be noted that the DNS provides a Well Known Services (WKS)
+ lookup capability, which makes it possible to determine the services
+ offered by a particular host given its domain name. In practice this
+ is not widely used, and was deprecated in the Host Requirements
+ specification [9]. In fact, WKS is really trying to solve a
+ different problem - advertising the services provided by a particular
+ machine, rather than which machines provide particular services for a
+ domain as a whole.
+
+2. A generic framework
+
+ One approach to dealing with aliases for new protocols would be to
+ define a standard set of DNS aliases for the most popular network
+ services, and an accompanying review procedure for registering new
+ protocols - such as has been attempted with Internet Media (MIME)
+ Types [10]. We suggest that in the rapidly changing world of
+ computer networking this may not be the most appropriate way of
+ tackling the problem.
+
+ The Internet Assigned Numbers Authority (IANA) maintains a registry
+ of well known port numbers, registered port numbers, protocol and
+ service names [11]. We propose that this list be used to determine
+ the a default port number, transport protocol (e.g. TCP or UDP) and
+ DNS alias for a given application protocol.
+
+ e.g.
+
+ -----------------------------------------------------------
+ Name Port Transport Protocol
+ -----------------------------------------------------------
+ finger 79 TCP Finger [12]
+ ftp 21 TCP File Transfer Protocol
+ gopher 70 TCP Internet Gopher Protocol
+ ldap 389 TCP/UDP Lightweight Directory Access
+ Protocol [13]
+ ntp 123 UDP Network Time Protocol [14]
+ rwhois 4321 TCP Referral WHOIS [15]
+ whois 43 TCP NICNAME/WHOIS [16]
+ -----------------------------------------------------------
+
+ If it is not appropriate to use the information registered with IANA
+ for a particular application protocol, we suggest the protocol
+ specification should indicate why this is the case - and preferably
+ propose an alternative mechanism. For example, a Remote Procedure
+ Call (RPC) based application protocol which does not use a fixed port
+ number by default might determine which port to use by contacting a
+ remote RPC portmapper.
+
+
+
+
+ [Page 3]
+\f
+INTERNET-DRAFT May 1996
+
+
+ We suggest that the DNS alias to be used for a service be taken
+ initially from the IANA lists of well known port numbers (in the
+ traditionally "restricted" rage 0 to 1023) and registered port
+ numbers (1024 to 65535), with recourse to the list of protocol and
+ service names if there is some confusion over the preferred alias.
+ This might be necessary if, for example, the name associated with the
+ IANA registered port number for a protocol contains the underscore
+ character "_", the plus character "+", or the dot character "." -
+ these are not legal as domain name components.
+
+3. Special cases
+
+ In addition to the character set problems outlined above, there are a
+ small number of special cases which are not currently catered for in
+ the IANA registry. We propose that IANA maintain a list of these in
+ addition to the existing assigned numbers information.
+
+ Some common examples:
+
+ -----------------------------------------------------------
+ Alias Service
+ -----------------------------------------------------------
+ archie archie [17] (alias for "prospero")
+ cso CCSO nameserver [18] (alias for "csnet-ns")
+ fsp File Service Protocol [19]
+ news Usenet News via NNTP [20] (alias for "nntp")
+ ns DNS servers, and CCSO nameservers (aliases for
+ "domain" and "csnet-ns")
+ ph CCSO (alias for "csnet-ns")
+ wais Wide Area Information Server [21] (alias for
+ "z39.50")
+ www World-Wide Web HTTP (alias for "http")
+ -----------------------------------------------------------
+
+4. (Ab)Use of the DNS as a directory service
+
+ The widespread use of these common aliases effectively means that it
+ is sometimes possible to "guess" the domain names associated with an
+ organization's network services, though this is becoming more
+ difficult as the number of organizations registered in the DNS
+ increases.
+
+ It should be understood by implementors that the existence of a DNS
+ entry such as
+
+ www.hivnet.fr
+
+ does not constitute a registration of a World-Wide Web service.
+
+
+
+ [Page 4]
+\f
+INTERNET-DRAFT May 1996
+
+
+ There is no requirement that the domain name resolve to an IP address
+ or addresses. There is no requirement that a host be listening for
+ HTTP connections, or if it is, that the HTTP server be running on
+ port 80. Finally, even if all of these things are true, there can be
+ no guarantee that the World-Wide Web server will be prepared to honor
+ requests from arbitrary clients.
+
+ Having said this, the aliases do provide useful "hints" about the
+ services offered. We propose that they be taken in this spirit.
+
+ The conventions described in this document are, essentially, only
+ useful when the organization's domain name can be determined - e.g.
+ from some external database. A number of groups, including the IETF,
+ have been working on ways of finding domain names given a set of
+ information such as organization name, location, and business type.
+ It is hoped that one or more of these will eventually make it
+ possible to augment the basic lookup service which the DNS provides
+ with a more generalised search and retrieval capability.
+
+5. DNS server configuration
+
+ In the short term, whilst directory service technology and further
+ types of DNS resource record are being developed, domain name
+ administrators are encouraged to use these common names for the
+ network services they run. They will make it easier for outsiders to
+ find information about your organization, and also make it easier for
+ you to move services from one machine to another.
+
+ There are two conventional approaches to creating these DNS entries.
+ One is to add a single CNAME record to your DNS server's
+ configuration, e.g.
+
+ ph.hivnet.fr. IN CNAME baby.hivnet.fr.
+
+ Note that in this scenario no information about ph.hivnet.fr should
+ exist in the DNS other than the CNAME record. An alternative
+ approach would be to create an A record for each of the IP addresses
+ associated with ph.hivnet.fr, e.g.
+
+ ph.hivnet.fr. IN A 194.167.157.2
+
+ Recent DNS server implementations provide a "round-robin" feature
+ which causes the host's IP addresses to be returned in a different
+ order each time the address is looked up.
+
+ Network clients are starting to appear which, when they encounter a
+ host with multiple addresses, use heuristics to determine the address
+ to contact - e.g. picking the one which has the shortest round-trip-
+
+
+
+ [Page 5]
+\f
+INTERNET-DRAFT May 1996
+
+
+ time. Thus, if a server is mirrored (replicated) at a number of
+ locations, it may be desirable to list the IP addresses of the mirror
+ servers as A records of the primary server. This is only likely to
+ be appropriate if the mirror servers are exact copies of the original
+ server.
+
+6. Limitations of this approach
+
+ Some services require that a client have more information than the
+ server's domain name and (default) port number. For example, an LDAP
+ client needs to know a starting search base within the Directory
+ Information Tree in order to have a meaningful dialogue with the
+ server. This document does not attempt to address this problem.
+
+ In some cases, different aliases are in common use for the same
+ service - e.g. "ph", "cso" and "ns" for the CCSO nameserver. It
+ might appear to be in everyone's interest to narrow the choice of
+ alias down to a single name. However, if current practice implies
+ that a number of aliases are equally valid, it would be advisable to
+ support them all. This increases the likelihood of the service being
+ found.
+
+ <<contentious>> Given the confusion over the multiple use of the "ns"
+ alias in particular, we could suggest/mandate that everyone move to a
+ single name, e.g. the IANA registered "csnet-ns" or one of "cso" and
+ "ph". Should we be trying to do this ? Discuss! <</contentious>>
+
+ Another problem is the use of a single alias to refer to multiple
+ network services, e.g. "ns" is commonly used to refer to both hosts
+ which run the CCSO nameserver, and DNS servers themselves. In this
+ particular case the DNS already provides a lookup capability for
+ nameservers via the NS record. As noted, implementations should be
+ resilient in the event that the name does not point to the expected
+ service.
+
+7. Security considerations
+
+ The DNS is open to many kinds of "spoofing" attacks, and it cannot be
+ guaranteed that the result returned by a DNS lookup is indeed the
+ genuine information. Spoofing may take the form of denial of
+ service, such as directing of the client to a non-existent address,
+ or a passive attack such as an intruder's server which masquerades as
+ the legitimate one.
+
+ Work is ongoing to remedy this situation insofar as the DNS is
+ concerned [22]. In the meantime it should be noted that stronger
+ authentication mechanisms such as public key cryptography with large
+ key sizes are a pre-requisite if the DNS is being used in any
+
+
+
+ [Page 6]
+\f
+INTERNET-DRAFT May 1996
+
+
+ sensitive situations. Examples of these would be on-line financial
+ transactions, and any situation where privacy is a concern - such as
+ the querying of medical records over the network. Strong encryption
+ of the network traffic may also be advisable, to protect against TCP
+ connection "hijacking" and packet sniffing.
+
+8. Conclusions
+
+ The service names registered with the IANA provide a sensible set of
+ defaults which may be used as an aid in determining the hosts which
+ offer particular services for a given domain name.
+
+ This document has noted some exceptions which are either inherently
+ unsuitable for this treatment, or already have a substantial
+ installed base using alternative aliases.
+
+9. Acknowledgements
+
+ Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas
+ Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, and <<your
+ name here!!>> for their comments on draft versions of this document.
+
+ This work was supported by grants from the UK Electronic Libraries
+ Programme (eLib) and the European Commission's Telematics for
+ Research Programme.
+
+10. References
+
+ Request For Comments (RFC) and Internet Draft documents are available
+ from <URL:ftp://ftp.internic.net> and numerous mirror sites.
+
+ [1] P. V. Mockapetris. "Domain names - concepts and
+ facilities", RFC 1034. November 1987.
+
+
+ [2] P. V. Mockapetris. "Domain names - implementation
+ and specification", RFC 1035. November 1987.
+
+
+ [3] J. Postel, J. K. Reynolds. "File Transfer Proto-
+ col", RFC 959. October 1985.
+
+
+ [4] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
+ D. Torrey & B. Albert. "The Internet Gopher Proto-
+ col (a distributed document search and retrieval
+ protocol)", RFC 1436. March 1993.
+
+
+
+
+ [Page 7]
+\f
+INTERNET-DRAFT May 1996
+
+
+ [5] T. Berners-Lee, R. Fielding, H. Nielsen. "Hyper-
+ text Transfer Protocol -- HTTP/1.0", RFC 1945. May
+ 1996.
+
+
+ [6] J. Postel. "Transmission Control Protocol", RFC
+ 793. September 1981.
+
+
+ [7] J. Postel. "User Datagram Protocol", RFC 768.
+ August 1980.
+
+
+ [8] C. Partridge. "Mail routing and the domain sys-
+ tem", RFC 974. January 1986.
+
+
+ [9] R. T. Braden. "Requirements for Internet hosts -
+ application and support", RFC 1123. October 1989.
+
+
+ [10] J. Postel. "Media Type Registration Procedure",
+ RFC 1590. March 1994.
+
+
+ [11] J. Reynolds, J. Postel. "ASSIGNED NUMBERS", RFC
+ 1700. October 1994.
+
+
+ [12] D. Zimmerman. "The Finger User Information Proto-
+ col", RFC 1288. December 1992.
+
+
+ [13] W. Yeong, T. Howes, S. Kille. "Lightweight Direc-
+ tory Access Protocol", RFC 1777. March 1995.
+
+
+ [14] D. Mills. "Network Time Protocol (Version 3)
+ Specification, Implementation", RFC 1305. March
+ 1992.
+
+
+ [15] S. Williamson & M. Kosters. "Referral Whois Proto-
+ col (RWhois)", RFC 1714. November 1994.
+
+
+ [16] K. Harrenstien, M. K. Stahl, E.J. Feinler.
+ "NICNAME/WHOIS", RFC 954. October 1985.
+
+
+
+ [Page 8]
+\f
+INTERNET-DRAFT May 1996
+
+
+ [17] A. Emtage, P. Deutsch. "archie - An Electronic
+ Directory Service for the Internet", Winter Usenix
+ Conference Proceedings 1992. Pages 93-110.
+
+
+ [18] R. Hedberg, S. Dorner, P. Pomes. "The CCSO
+ Nameserver (Ph) Architecture", Internet Draft.
+ February 1996.
+
+
+ [19] FSP software distribution:
+ <URL:ftp://ftp.germany.eu.net/pub/networking/inet/fsp>
+
+
+ [20] B. Kantor, P. Lapsley. "Network News Transfer Pro-
+ tocol", RFC 977. February 1986.
+
+
+ [21] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman,
+ B. Kahle, J. Kunze, H. Morris & F. Schiettecatte.
+ "WAIS over Z39.50-1988", RFC 1625. June 1994.
+
+
+ [22] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name
+ System Security Extensions", Internet Draft. Janu-
+ ary 1996.
+
+
+11. Authors addresses
+
+ Martin Hamilton
+ Department of Computer Studies
+ Loughborough University of Technology
+ Leics. LE11 3TU, UK
+
+ Email: m.t.hamilton@lut.ac.uk
+
+
+ Russ Wright
+ Information & Computing Sciences Division
+ Lawrence Berkeley National Laboratory
+ 1 Cyclotron Road, Berkeley
+ Mail-Stop: 50B-2258
+ CA 94720, USA
+
+ Email: wright@lbl.gov
+
+
+
+
+
+ [Page 9]
+\f
+INTERNET-DRAFT May 1996
+
+
+ This Internet Draft expires 29th November, 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [Page 10]
+\f
--- /dev/null
+Network Working Group Jacob Palme
+Internet Draft Stockholm University/KTH
+draft-ietf-mailext-mail-attributes-04.txt Sweden
+Category: Informational May 1996
+Expires November 1996
+
+
+
+
+
+ Common Internet Message Headers
+
+ Status of this Memo
+
+
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-
+ Drafts as reference material or to cite them other than as
+ ``work in progress.''
+
+ To learn the current status of any Internet-Draft, please check
+ the ``1id-abstracts.txt'' listing contained in the Internet-
+ Drafts Shadow Directories on ftp.is.co.za (Africa),
+ nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
+ ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
+
+ This memo provides information for the Internet community. This'
+ memo does not specify an Internet standard of any kind, since
+ this document is mainly a compilation of information taken from
+ other RFCs.. Distribution of this memo is unlimited.
+
+
+
+ Abstract
+
+This memo contains a table of commonly occurring headers in headings of
+e-mail messages. The document compiles information from other RFCs such
+as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766,
+RFC 1806 and RFC 1864. A few commonly occurring headers which are not
+defined in RFCs are also included. For each header, the memo gives a
+short description and a reference to the RFC in which the header is
+defined.
+
+
+
+
+
+
+
+Palme [Page 1]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+
+ Table of contents
+
+1. Introduction
+
+2. Use of gatewaying headers
+
+3. Table of headers
+
+ 3.1 Phrases used in the tables
+ 3.2 Trace information
+ 3.3 Format and control information
+ 3.4 Sender and recipient indication
+ 3.5 Response control
+ 3.6 Message identification and referral headers
+ 3.7 Other textual headers
+ 3.8 Headers containing dates and times
+ 3.9 Quality information
+ 3.10 Language information
+ 3.11 Size information
+ 3.12 Conversion control
+ 3.13 Encoding information
+ 3.14 Resent-headers
+ 3.15 Security and reliability
+ 3.16 Miscellaneous
+
+4. Acknowledgments
+
+5. References
+
+6. Author's address
+
+Appendix A: Headers sorted by Internet RFC document in which
+ they appear
+
+Appendix B: Alphabetical index
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme [Page 2]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+
+ 1. Introduction
+
+Many different Internet standards and RFCs define headers which
+may occur on Internet Mail Messages and Network News Articles. The
+intention of this document is to list all such headers in one
+document as an aid to people developing message systems or interested
+in Internet Mail standards.
+
+The document contains all headers which the author has
+found in the following Internet standards: , RFC 822 [2],
+RFC 1036 [3], RFC 1123 [5], RFC 1327 [7], RFC 1496 [8], RFC 1521 [11],
+RFC 1766 [12], RFC 1806 [14] and RFC 1864[17]. Note in particular that
+heading attributes defined in PEM (RFC 1421-1424) and MOSS (RFC 1848
+[16]) are not included. PEM and MOSS headers only appear inside the
+body of a message, and thus are not headers in the RFC 822 sense. Mail
+attributes in envelopes, i.e. attributes controlling the message
+transport mechanism between mail and news servers, are not included.
+This means that attributes from SMTP [1], UUCP [18] and NNTP [15] are
+not covered either. Headings used only in HTTP [19] are not included
+yet, but may be included in future version of this memo. A few
+additional headers which often can be found in e-mail headings but are
+not part of any Internet standard are also included.
+
+For each header, the document gives a short description and
+a reference to the Internet standard or RFC, in which they are defined.
+
+The header names given here are spelled the same way as when they are
+actually used. This is usually American but sometimes English spelling.
+One header in particular, "Organisation/Organization", occurs in e-mail
+headers sometimes with the English and other times with the American
+spelling.
+
+The following words are used in this memo with the meaning specified
+below:
+
+heading Formatted text at the top of a message, ended by a
+ blank line
+
+header = heading One field in the heading, beginning with a field
+field name, colon, and followed by the field value(s)
+
+It is my intention to continue updating this document after its
+publication as an RFC. The latest version, which may be more up-to-date
+(but also less fully checked out) will be kept available for
+downloading by anonymous FTP from URL
+http://www.dsv.su.se/~jpalme/ietf-mail-attributes.pdf.
+
+Please e-mail me (Jacob Palme <jpalme@dsv.su.se>) if you have noted
+headers which should be included in this memo but are not.
+
+
+
+
+Palme [Page 3]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+ 2. Use of gatewaying headers
+
+RFC 1327 defines a number of new headers in Internet mail, which
+are defined to map headers which X.400 has but which were
+previously not standardized in Internet mail. The fact that a
+header occurs in RFC 1327 indicates that it is recommended for
+use in gatewaying messages between X.400 and Internet mail, but
+does not mean that the header is recommended for messages wholly
+within Internet mail. Some of these headers may eventually see
+widespread implementation and use in Internet mail, but at the time of
+this writing (May 1996) they are not widely implemented or used.
+
+Headers defined in RFC 1036 for use in Usenet News sometimes appear
+in mail messages, either because the messages have been gatewayed
+from Usenet News to e-mail, or because the messages were written in
+combined clients supporting both e-mail and Usenet News in the same
+client. These headers are not standardized for use in Internet e-mail
+and should be handled with caution by e-mail agents.
+
+
+
+
+ 3. Table of headers
+
+3.1 Phrases used in the tables
+
+
+"not for general Used to mark headers which are defined in RFC
+usage" 1327 for use in messages from or to Internet
+ mail/X.400 gateways. These headers have not
+ been standardized for general usage in the
+ exchange of messages between Internet mail-
+ based systems.
+
+"not standardized Used to mark headers defined only in RFC 1036
+for use in e-mail" for use in Usenet News. These headers have no
+ standard meaning when appearing in e-mail,
+ some of them may even be used in different
+ ways by different software. When appearing in
+ e-mail, they should be handled with caution.
+ Note that RFC 1036, although generally used as
+ a standard for Usenet News, is not an accepted
+ IETF standard or on the IETF standards track.
+
+"non-standard" This header is not specified in any of
+ referenced RFCs which define Internet
+ protocols, including Internet Standards, draft
+ standards or proposed standards. The header
+ appears here because it often appears in e-
+ mail or Usenet News. Usage of these headers is
+ not in general recommended.
+
+
+
+Palme [Page 4]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+"discouraged" This header, which is non-standard, is known
+ to create problems and should not be
+ generated. Handling of such headers in
+ incoming mail should be done with great
+ caution.
+
+"controversial" The meaning and usage of this header is
+ controversial, i.e. different implementors
+ have chosen to implement the header in
+ different ways. Because of this, such headers
+ should be handled with caution and
+ understanding of the different possible
+ interpretations.
+
+"experimental" This header is used for newly defined headers,
+ which are to be tried out before entering the
+ IETF standards track. These should only be
+ used if both communicating parties agree on
+ using them. In practice, some experimental
+ protocols become de-facto-standards before
+ they are made into IETF standards.
+
+
+
+3.2 Trace information
+Used to convey the information Return-Path: RFC 821,
+from the MAIL FROM envelope RFC 1123: 5.2.13.
+attribute in final delivery, when
+the message leaves the SMTP
+environment in which "MAIL FROM"
+is used.
+
+Trace of MTAs which a message has Received: RFC 822: 4.3.2,
+passed. RFC 1123: 5.2.8.
+
+List of MTAs passed. Path: RFC 1036: 2.2.6,
+ only in Usenet
+ News, not in e-
+ mail.
+
+Trace of distribution lists DL-Expansion- RFC 1327, not for
+passed. History- general usage.
+ Indication:
+
+3.3 Format and control
+information
+
+An indicator that this message is MIME-Version: RFC 1521: 3.
+formatted according to the MIME
+standard, and an indication of
+which version of MIME is
+utilized.
+
+
+
+Palme [Page 5]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+Special Usenet News actions. Control: RFC 1036: 2.1.6,
+ only in Usenet
+ News, not in e-
+ mail.
+
+Which body part types occur in Original- RFC 1327, not for
+this message. Encoded- general usage.
+ Information-
+ Types:
+
+Controls whether this message may Alternate- RFC 1327, not for
+be forwarded to alternate Recipient: general usage.
+recipients such as a postmaster
+if delivery is not possible to
+the intended recipient. Default:
+Allowed.
+
+Whether recipients are to be told Disclose- RFC 1327, not for
+the names of other recipients of Recipients: general usage.
+the same message. This is
+primarily an X.400 facility. In
+X.400, this is an envelope
+attribute and refers to
+disclosure of the envelope
+recipient list. Disclosure of
+other recipients is in Internet
+mail done via the To:, cc: and
+bcc: headers.
+
+Whether a MIME body part is to be Content- RFC 1806,
+shown inline or is an attachment; Disposition: experimental
+can also indicate a suggested
+filename for use when saving an
+attachment to a file.
+
+3.4 Sender and recipient
+indication
+
+Authors or persons taking From: RFC 822: 4.4.1,
+responsibility for the message. RFC 1123: 5.2.15-
+ 16, 5.3.7,
+ RFC 1036 2.1.1
+
+Name of the moderator of the Approved: RFC 1036: 2.2.11,
+newsgroup to which this message not standardized
+is sent; necessary on an article for use in e-mail.
+sent to a moderated newsgroup to
+allow its distribution to the
+newsgroup members. Also used on
+certain control messages, which
+are only performed if they are
+marked as Approved.
+
+
+
+Palme [Page 6]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+The person or agent submitting Sender: RFC 822: 4.4.2,
+the message to the network, if RFC 1123: 5.2.15-
+other than shown by the From: 16, 5.3.7.
+header.
+
+Primary recipients. To: RFC 822: 4.5.1,
+ RFC 1123: 5.2.15-
+ 16, 5.3.7.
+
+Secondary, informational cc: RFC 822: 4.5.2,
+recipients. (cc = Carbon Copy) RFC 1123. 5.2.15-
+ 16, 5.3.7.
+
+Recipients not to be disclosed to bcc: RFC 822: 4.5.3,
+other recipients. (bcc = Blind RFC 1123: 5.2.15-
+Carbon Copy). 16, 5.3.7.
+
+In Usenet News: group(s) to which Newsgroups: RFC 1036: 2.1.3,
+this article was posted. not standardized
+Some systems provide this header and controversial
+also in e-mail although it is not for use in e-mail.
+standardized there.
+Unfortunately, the header can
+appear in e-mail with two
+different and contradictory
+meanings:
+(a) Indicates the newsgroup
+recipient of a message sent to
+both e-mail and Usenet News
+recipients.
+(b) In a personally addressed
+reply to a message in a news-
+group, indicate the newsgroup in
+which this discussion originated.
+
+Inserted by Sendmail when there Apparently- Non-standard,
+is no "To:" recipient in the To: discouraged,
+original message, listing mentioned in
+recipients derived from the RFC 1211.
+envelope into the message
+heading. This behavior is not
+quite proper, MTAs should not
+modify headings (except inserting
+Received lines), and it can in
+some cases cause Bcc recipients
+to be wrongly divulged to non-Bcc
+recipients.
+
+Geographical or organizational Distribution: RFC 1036: 2.2.7,
+limitation on where this message not standardized
+can be distributed. for use in e-mail.
+
+
+
+
+Palme [Page 7]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+Fax number of the originator. Fax:, Non-standard.
+ Telefax:
+
+
+Phone number of the originator. Phone: Non-standard.
+
+Information about the client Mail-System- Non-standard.
+software of the originator. Version:,
+ Mailer:,
+ Originating-
+ Client:, X-
+ Mailer, X-
+ Newsreader
+
+3.5 Response control
+
+This header is meant to indicate Reply-To: RFC 822: 4.4.3,
+where the sender wants replies to RFC 1036: 2.2.1
+go. Unfortunately, this is controversial.
+ambiguous, since there are
+different kinds of replies, which
+the sender may wish to go to
+different addresses. In
+particular, there are personal
+replies intended for only one
+person, and group replies,
+intended for the whole group of
+people who read the replied-to
+message (often a mailing list).
+
+Some mail systems use this header
+to indicate a better form of the
+e-mail address of the sender.
+Some mailing list expanders puts
+the name of the list in this
+header. These practices are
+controversial. The personal
+opinion of the author of this RFC
+is that this header should be
+avoided except in special cases,
+but this is a personal opinion
+not shared by all specialists in
+the area.
+
+Used in Usenet News to indicate Followup-To: RFC 1036: 2.2.3,
+that future discussions (=follow- not standardized
+up) on an article should go to a for use in e-mail.
+different set of newsgroups than
+the replied-to article. The most
+common usage is when an article
+is posted to several newsgroups,
+and further discussions is to
+take place in only one of them.
+
+Palme [Page 8]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+In e-mail, this header is used in
+a message which is sent to both e-
+mail and Usenet News, to show
+where follow-up in Usenet news is
+wanted. The header does not say
+anything about where follow-up in
+e-mail is to be sent.
+
+Note that the value of this
+header must always be one or more
+newsgroup names, never e-mail
+addresses.
+
+Address to which notifications Errors-To:, Non-standard,
+are to be sent and a request to Return- discouraged.
+get delivery notifications. Receipt-To:
+Internet standards recommend,
+however, the use of RCPT TO and
+Return-Path, not Errors-To, for
+where delivery notifications are
+to be sent.
+
+Whether non-delivery report is Prevent- RFC 1327, not for
+wanted at delivery error. Default NonDelivery- general usage.
+is to want such a report. Report:
+
+Whether a delivery report is Generate- RFC 1327, not for
+wanted at successful delivery. Delivery- general usage.
+Default is not to generate such a Report:
+report.
+
+Indicates whether the content of Content- RFC 1327, not for
+a message is to be returned with Return: general usage.
+non-delivery notifications.
+
+3.6 Message identification and
+referral headers
+
+Unique ID of this message. Message-ID: RFC 822: 4.6.1
+ RFC 1036: 2.1.5.
+
+Unique ID of one body part of the Content-ID: RFC 1521: 6.1.
+content of a message.
+
+Reference to message which this In-Reply-To: RFC 822: 4.6.2.
+message is a reply to.
+
+Reference to other related References: RFC 822: 4.6.3
+messages. RFC 1036: 2.1.5.
+
+Reference to previous message Obsoletes: RFC 1327, not for
+being corrected and replaced. general usage.
+Compare to "Supersedes:" below.
+
+
+Palme [Page 9]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+Commonly used in Usenet News in Supersedes: Non-standard.
+similar ways to the "Obsoletes"
+header described above. In Usenet
+News, however, Supersedes causes
+a full deletion of the replaced
+message in the server, while
+Obsoletes is implemented in the
+client and often does not remove
+the old version of the text.
+
+3.7 Other textual headers
+
+Search keys for data base Keywords: RFC 822: 4.7.1
+retrieval. RFC 1036: 2.2.9.
+
+Title, heading, subject. Often Subject: RFC 822: 4.7.1
+used as thread indicator for RFC 1036: 2.1.4.
+messages replying to or
+commenting on other messages.
+
+Comments on a message. Comments: RFC 822: 4.7.2.
+
+Description of a particular body Content- RFC 1521: 6.2.
+part of a message. Description:
+
+Organization to which the sender Organization: RFC 1036: 2.2.8,
+of this message belongs. not standardized
+ for use in e-mail.
+
+See Organization above. Organisation: Non-standard.
+
+Short text describing a longer Summary: RFC 1036: 2.2.10,
+message. Warning: Some mail not standardized
+systems will not display this for use in e-mail,
+text to the recipient. Because of discouraged.
+this, do not use this header for
+text which you want to ensure
+that the recipient gets.
+
+A text string which identifies Content- RFC 1327, not for
+the content of a message. Identifier: general usage.
+
+3.8 Headers containing dates and
+times
+
+The time when a message was Delivery- RFC 1327, not for
+delivered to its recipient. Date: general usage.
+
+In Internet, the date when a Date: RFC 822: 5.1,
+message was written, in X.400, RFC 1123: 5.2.14
+the time a message was submitted. RFC 1036: 2.1.2.
+Some Internet mail systems also
+use the date when the message was
+submitted.
+
+Palme [Page 10]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+A suggested expiration date. Can Expires: RFC 1036: 2.2.4,
+be used both to limit the time of not standardized
+an article which is not for use in e-mail.
+meaningful after a certain date,
+and to extend the storage of
+important articles.
+
+Time at which a message loses its Expiry-Date: RFC 1327, not for
+validity. general usage.
+
+Latest time at which a reply is Reply-By: RFC 1327, not for
+requested (not demanded). general usage.
+
+3.9 Quality information
+
+Can be "normal", "urgent" or "non- Priority: RFC 1327, not for
+urgent" and can influence general usage.
+transmission speed and delivery.
+
+Sometimes used as a priority Precedence: Non-standard,
+value which can influence controversial,
+transmission speed and delivery. discouraged.
+Common values are "bulk" and
+"first-class". Other uses is to
+control automatic replies and to
+control return-of-content
+facilities, and to stop mailing
+list loops.
+
+A hint from the originator to the Importance: RFC 1327, not for
+recipients about how important a general usage.
+message is. Values: High, normal
+or low. Not used to control
+transmission speed.
+
+How sensitive it is to disclose Sensitivity: RFC 1327, not for
+this message to other people than general usage.
+the specified recipients. Values:
+Personal, private, company
+confidential. The absence of this
+header in messages gatewayed from
+X.400 indicates that the message
+is not sensitive.
+
+Body parts are missing. Incomplete- RFC 1327, not for
+ Copy: general usage.
+
+3.10 Language information
+
+Can include a code for the Language: RFC 1327, not for
+natural language used in a general usage.
+message, e.g. "en" for English.
+
+
+
+Palme [Page 11]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+Can include a code for the Content- RFC 1766, proposed
+natural language used in a Language: standard.
+message, e.g. "en" for English.
+
+3.11 Size information
+
+Inserted by certain mailers to Content- Non-standard,
+indicate the size in bytes of the Length: discouraged.
+message text. This is part of a
+format some mailers use when
+showing a message to its users,
+and this header should not be
+used when sending a message
+through the net. The use of this
+header in transmission of a
+message can cause several
+robustness and interoperability
+problems.
+
+Size of the message. Lines: RFC 1036: 2.2.12,
+ not standardized
+ for use in e-mail.
+
+3.12 Conversion control
+
+The body of this message may not Conversion: RFC 1327, not for
+be converted from one character general usage.
+set to another. Values:
+Prohibited and allowed.
+
+Non-standard variant of Content- Non-standard.
+Conversion: with the same values. Conversion:
+
+The body of this message may not Conversion- RFC 1327, not for
+be converted from one character With-Loss: general usage.
+set to another if information
+will be lost. Values: Prohibited
+and allowed.
+
+3.13 Encoding information
+
+Format of content (character set Content-Type: RFC 1049,
+etc.) Note that the values for RFC 1123: 5.2.13,
+this header are defined in RFC 1521: 4.
+different ways in RFC 1049 and in
+MIME (RFC 1521), look for the
+"MIME-version" header to
+understand if Content-Type is to
+be interpreted according to RFC
+1049 or according to MIME. The
+MIME definition should be used in
+generating mail.
+
+
+
+Palme [Page 12]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+Coding method used in a MIME Content- RFC 1521: 5.
+message body. Transfer-
+ Encoding:
+
+Only used with the value Message-Type: RFC 1327, not for
+"Delivery Report" to indicates general usage.
+that this is a delivery report
+gatewayed from X.400.
+
+Used in several different ways by Encoding: RFC 1154,
+different mail systems. Some use RFC 1505,
+it for a kind of content-type experimental.
+information, some for encoding
+and length information, some for
+a kind of boundary information,
+some in other ways.
+
+3.14 Resent-headers
+
+When manually forwarding a Resent-Reply- RFC 822: C.3.3.
+message, headers referring to the To:,
+forwarding, not to the original Resent-From:,
+message. Note: MIME specifies Resent-
+another way of resending Sender:,
+messages, using the "Message" Resent-From:,
+Content-Type. Resent-Date:,
+ Resent-To:,
+ Resent-cc:,
+ Resent-bcc:,
+ Resent-
+ Message-ID:
+
+3.15 Security and reliability
+
+Checksum of content to ensure Content-MD5: RFC 1864, proposed
+that it has not been modified. standard.
+
+3.16 Miscellaneous
+
+Name of file in which a copy of Fcc: Non-standard.
+this message is stored.
+
+Has been automatically forwarded. Auto- RFC 1327, not for
+ Forwarded: general usage.
+
+Can be used in Internet mail to Discarded- RFC 1327, not for
+indicate X.400 IPM extensions X400-IPMS- general usage.
+which could not be mapped to Extensions:
+Internet mail format.
+
+Can be used in Internet mail to Discarded- RFC 1327, not for
+indicate X.400 MTS extensions X400-MTS- general usage.
+which could not be mapped to Extensions:
+Internet mail format.
+
+Palme [Page 13]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+
+ 4. Acknowledgments
+
+Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Keith Moore, Nick
+Smith and several other people have helped me with compiling this list.
+I especially thank Ned Freed and Olle Järnefors for their thorough
+review and many helpful suggestions for improvements. I alone take
+responsibility for any errors which may still be in the list.
+
+An earlier version of this list has been published as part of [13].
+
+
+
+ 5. References
+
+Ref. Author, title IETF status
+ (May 1996)
+----- --------------------------------------------- -----------
+[1] J. Postel: "Simple Mail Transfer Protocol", Standard,
+ STD 10, RFC 821, August 1982. Recommended
+
+[2] D. Crocker: "Standard for the format of ARPA Standard,
+ Internet text messages." STD 11, RFC 822, Recommended
+ August 1982.
+
+[3] M.R. Horton, R. Adams: "Standard for Not an offi-
+ interchange of USENET messages", RFC 1036, cial IETF
+ December 1987. standard,
+ but in
+ reality a de-
+ facto
+ standard for
+ Usenet News
+
+[4] M. Sirbu: "A Content-Type header header for Standard,
+ internet messages", RFC 1049, March 1988. Recommended,
+ but can in
+ the future
+ be expected
+ to be
+ replaced by
+ MIME
+
+[5] R. Braden (editor): "Requirements for Standard,
+ Internet Hosts -- Application and Support", Required
+ STD-3, RFC 1123, October 1989.
+
+[6] D. Robinson, R. Ullman: "Encoding Header Non-standard
+ Header for Internet Messages", RFC 1154,
+ April 1990.
+
+
+
+
+
+Palme [Page 14]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+[7] S. Hardcastle-Kille: "Mapping between Proposed
+ X.400(1988) / ISO 10021 and RFC 822", RFC standard,
+ 1327 May 1992. elective
+
+[8] H. Alvestrand & J. Romaguera: "Rules for Proposed
+ Downgrading Messages from X.400/88 to standard,
+ X.400/84 When MIME Content-Types are Present elective
+ in the Messages", RFC 1496, August 1993.
+
+[9] A. Costanzo: "Encoding Header Header for Non-standard
+ Internet Messages", RFC 1154, April 1990.
+
+[10] A. Costanzo, D. Robinson: "Encoding Header Experimental
+ Header for Internet Messages", RFC 1505,
+ August 1993.
+
+[11] N. Borenstein & N. Freed: "MIME (Multipurpose Draft
+ Internet Mail Extensions) Part One: Standard,
+ Mechanisms for Specifying and Describing the elective
+ Format of Internet Message Bodies", RFC 1521,
+ Sept 1993.
+
+[12] H. Alvestrand: "Tags for the Identification Proposed
+ of Languages", RFC 1766, February 1995. standard,
+ elective
+
+[13] J. Palme: "Electronic Mail", Artech House Non-standard
+ publishers, London-Boston January 1995.
+
+[14] R. Troost, S. Dorner: "Communicating Experimental
+ Presentation Information in Internet
+ Messages: The Content-Disposition Header",
+ RFC 1806, June 1995.
+
+[15] B. Kantor, P. Lapsley, "Network News Transfer Proposed
+ Protocol: "A Proposed Standard for the Stream- standard
+ Based Transmission of News", RFC 977, January
+ 1986.
+[16] 1848 PS S. Crocker, N. Freed, J. Galvin, Proposed
+ S. Murphy, "MIME Object Security Services", standard
+ RFC 1848, March 1995.
+
+[17] J. Myers, M. Rose: The Content-MD5 Header Draft
+ Header, RFC 1864, October 1995. standard
+
+[18] M. Horton, UUCP mail interchange format Not an offi-
+ standard, RFC 976, Januari 1986. cial IETF
+ standard,
+ but in
+ reality a de-
+ facto
+ standard for
+ Usenet News
+
+
+Palme [Page 15]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+[19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft
+ Hypertext Transfer Protocol -- HTTP/1.0,
+ draft-ietf-http-v10-spec-04.txt.
+
+
+
+ 6. Author's address
+
+Jacob Palme Phone: +46-8-16 16 67
+Stockholm University/KTH Fax: +46-8-783 08 29
+Electrum 230 E-mail: jpalme@dsv.su.se
+S-164 40 Kista, Sweden
+
+
+
+
+ Appendix A:
+Headers sorted by Internet RFC document in which they appear.
+
+
+RFC 822
+-------
+
+bcc
+cc
+Comments
+Date
+From
+In-Reply-To
+Keywords
+Message-ID
+Received
+References
+Reply-To
+Resent-
+Resent-bcc
+Resent-cc
+Resent-Date
+Resent-From
+Resent-From
+Resent-Message-ID
+Resent-Reply-To
+Resent-To
+Return-Path
+Sender
+Sender
+Subject
+To
+
+
+
+
+
+
+
+Palme [Page 16]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+RFC 1036
+--------
+
+Approved
+Control
+Distribution
+Expires
+Followup-To
+Lines
+Newsgroups
+Organization
+Path
+Summary
+
+RFC 1049
+--------
+
+Content-Type
+
+RFC 1327
+--------
+
+Alternate-recipient
+Auto-Forwarded
+Autoforwarded
+Content-Identifier
+Content-Return
+Conversion
+Conversion-With-Loss
+Delivery-Date
+Discarded-X400-IPMS-Extensions
+Discarded-X400-MTS-Extensions
+Disclose-Recipients
+DL-Expansion-History
+Expiry-Date
+Generate-Delivery-Report
+Importance
+Incomplete-Copy
+Language
+Message-Type Delivery
+Obsoletes
+Original-Encoded-Information-Types
+Prevent-NonDelivery-Report
+Priority
+Reply-By
+Report
+Sensitivity
+
+RFC 1505
+--------
+
+Encoding
+
+
+Palme [Page 17]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+RFC 1521
+--------
+
+Content-Description
+Content-ID
+Content-Transfer-Encoding
+Content-Type
+MIME-Version
+
+RFC 1806
+--------
+
+Content-Disposition
+
+RFC 1864
+--------
+
+Content-MD5
+
+Not Internet standard
+---------------------
+
+Apparently-to
+Content-length
+Encoding
+Errors-To
+Return-Receipt-To
+Fax
+Telefax
+Fcc
+Mail-System-Version
+Mailer
+Organisation
+Originating-Client
+Phone
+Supersedes
+X-Mailer
+X-Newsreader
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Palme [Page 18]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+ Appendix B:
+ Alphabetical index
+
+Section Heading-header
+------- --------------
+
+3.3 Alternate-Recipient
+3.4 Apparently-To
+3.4 Approved
+3.16 Auto-Forwarded
+3.4 bcc
+3.4 cc
+ Client, see Originating-Client
+3.7 Comments
+3.12 Content-Conversion
+3.7 Content-Description
+3.3 Content-Disposition
+3.6 Content-ID
+3.7 Content-Identifier
+3.10 Content-Language see also Language
+3.11 Content-Length
+3.15 Content-MD5
+3.4 Content-Return
+3.13 Content-Transfer-Encoding
+3.13 Content-Type
+3.3 Control
+3.12 Conversion
+3.12 Conversion-With-Loss
+3.8 Date
+3.8 Delivery-Date
+ Delivery-Report, see Generate-Delivery-Report, Prevent-
+ Delivery-Report, Non-Delivery-Report, Content-Type
+ Description, see Content-Description
+3.16 Discarded-X400-IPMS-Extensions
+3.16 Discarded-X400-MTS-Extensions
+3.3 Disclose-Recipients
+ Disposition, see Content-Disposition
+3.4 Distribution
+3.2 DL-Expansion-History-Indication
+3.13 Encoding see also Content-Transfer-Encoding
+3.4 Errors-To
+3.8 Expires
+ Extension see Discarded-X400-IPMS-Extensions, Discarded-
+ X400-MTS-Extensions
+3.4 Fax
+3.16 Fcc
+3.4 Followup-To
+ Forwarded, see Auto-Forwarded
+3.4 From
+3.4 Generate-Delivery-Report
+ History, see DL-Expansion-History-Indication
+ ID, see Content-ID and Message-ID
+ Identifier, see Content-ID and Message-ID
+
+
+Palme [Page 19]
+\fdraft-ietf-mailext-mail-attributes-04.txt May 1996
+
+3.9 Importance
+3.6 In-Reply-To
+3.9 Incomplete-Copy
+3.7 Keywords
+3.10 Language see also Content-Language
+ Length see Content-Length
+3.11 Lines
+3.4 Mail-System-Version see also X-mailer
+3.4 Mailer
+ MD5 see Content-MD5
+3.6 Message-ID
+3.13 Message-Type
+3.3 MIME-Version
+3.4 Newsgroups
+ Newsreader, see X-Newsreader
+3.6 Obsoletes
+3.7 Organisation
+3.7 Organization
+3.3 Original-Encoded-Information-Types
+3.4 Originating-Client
+3.2 Path
+3.4 Phone
+3.9 Precedence
+3.4 Prevent-NonDelivery-Report
+3.9 Priority
+3.2 Received
+ Recipient, see To, cc, bcc, Alternate-Recipient, Disclose-
+ Recipient
+3.6 References
+3.8 Reply-By
+3.4 Reply-To, see also In-Reply-To, References
+3.14 Resent-
+ Return see also Content-Return
+3.2 Return-Path
+3.5 Return-Receipt-To
+3.4 Sender
+3.9 Sensitivity
+3.7 Subject
+3.7 Summary
+3.6 Supersedes
+3.4 Telefax
+3.4 To
+ Transfer-Encoding see Content-Transfer-Encoding
+ Type see Content-Type, Message-Type, Original-Encoded-
+ Information-Types
+ Version, see MIME-Version, X-Mailer
+3.4 X-Mailer see also Mail-System-Version
+3.4 X-Newsreader
+
+
+
+
+
+
+Palme [Page 20]
--- /dev/null
+
+Internet Draft Barbara Fraser
+Network Working Group SEI/CMU
+Expires in six months Editor
+ June 1996
+
+
+ Site Security Handbook
+ <draft-ietf-ssh-handbook-03.txt>
+
+Status of this Memo
+
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet- Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ To learn the current status of any Internet-Draft, please check the
+ ``1id-abstracts.txt'' listing contained in the Internet- Drafts
+ Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+Table of Contents
+
+1. Introduction.................................................... 2
+1.1 Purpose of this Work............................................ 2
+1.2 Audience........................................................ 2
+1.3 Definitions..................................................... 3
+1.4 Related Work.................................................... 3
+1.5 Basic Approach.................................................. 3
+1.6 Risk Assessment................................................. 4
+2. Security Policies............................................... 5
+2.1 What is a Computer Security Policy and Why Have One?............ 5
+2.2 What Makes a Good Computer Security Policy?..................... 7
+2.3 Keeping the Policy Flexible..................................... 8
+3. Architecture.................................................... 9
+3.1 Objectives...................................................... 9
+3.2 Network and Service Configuration............................... 11
+3.3 Firewalls....................................................... 16
+4. Security Services and Procedures................................ 19
+4.1 Authentication.................................................. 19
+4.2 Confidentiality................................................. 22
+4.3 Integrity....................................................... 23
+4.4 Authorization................................................... 23
+4.5 Access.......................................................... 24
+4.6 Auditing........................................................ 27
+4.7 Securing Backups................................................ 30
+5. Security Incident Handling...................................... 30
+5.1 Preparing and Planning for Incident Handling.................... 32
+
+
+
+Site Security Working Group [Page 1]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+5.2 Notification and Points of Contact.............................. 34
+5.3 Identifying an Incident......................................... 40
+5.4 Handling an Incident............................................ 42
+5.5 Aftermath of an Incident........................................ 47
+5.6 Responsibilities................................................ 48
+6. Ongoing Activities.............................................. 49
+7. Tools and Locations............................................. 49
+8. Mailing Lists and Other Resources............................... 51
+9. References...................................................... 53
+10. Annotated Bibliography.......................................... 62
+
+1. INTRODUCTION
+
+ This document provides guidance to system and network administrators
+ on how to address security issues within the Internet community. It
+ builds on the foundation provided in RFC 1244 and is the collective
+ work of a number of contributing authors. Those authors include:
+ Jules P. Aronson, Nevil Brownlee, Frank Byrum, Joao Nuno Ferreira,
+ Erik Guttman, Klaus-Peter Kossakowski, Edward.P.Lewis, Gary Malkin,
+ Russ Mundy, Philip J. Nesser, and Michael S. Ramsey.
+
+ A special thank you goes to Joyce Reynolds, ISI, and Paul Holbrook,
+ CICnet, for their vision, leadership, and effort in the creation of
+ the first version of this handbook. It is the working group's sincere
+ hope that this version will be as helpful to the community as the
+ earlier one was.
+
+1.1 Purpose of this Work
+
+ This handbook is a guide to setting computer security policies and
+ procedures for sites that have systems on the Internet. This guide
+ lists issues and factors that a site must consider when setting their
+ own policies. It makes some recommendations and provides discussions
+ of relevant areas.
+
+ This guide is only a framework for setting security policies and
+ procedures. In order to have an effective set of policies and
+ procedures, a site will have to make many decisions, gain agreement,
+ and then communicate and implement the policies.
+
+1.2 Audience
+
+ The audience for this document are system and network administrators,
+ and decision makers (typically "middle management") at sites. For
+ brevity, we will use the term "administrator" throughout this
+ document to refer to system and network administrators.
+
+ This document is not directed at programmers or those trying to
+ create secure programs or systems. The focus of this document is on
+ the policies and procedures that need to be in place to support any
+ technical security features that a site may be implementing.
+
+ The primary audience for this work are sites that are members of the
+ Internet community. However, this document should be useful to any
+
+
+
+Site Security Working Group [Page 2]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ site that allows communication with other sites. As a general guide
+ to security policies, this document may also be useful to sites with
+ isolated systems.
+
+1.3 Definitions
+
+ For the purposes of this guide, a "site" is any organization that
+ owns computers or network-related resources. These resources may
+ include host computers that users use, routers, terminal servers,
+ PC's or other devices that have access to the Internet. A site may
+ be an end user of Internet services or a service provider such as a
+ mid-level network. However, most of the focus of this guide is on
+ those end users of Internet services. We assume that the site has
+ the ability to set policies and procedures for itself with the
+ concurrence and support from those who actually own the resources.
+
+ The "Internet" is that set of networks and machines which use the
+ TCP/IP protocol suite, connect through gateways, and share common
+ name and address spaces [1].
+
+ The term "administrator" is used to cover all those people who are
+ responsible for the day-to-day operation of system and network
+ resources. This may be a number of individuals or an organization.
+
+ The term "decision maker" refers to those people at a site who set or
+ approve policy. These are often (but not always) the people who own
+ the resources.
+
+1.4 Related Work
+
+ The IETF Guidelines for Security Incident Response Working Group
+ (GRIP) is developing a document for security incident response teams.
+ That document provides additional guidance to those organizations
+ planning to develop their own computer security incident response
+ team (CSIRT), including a template that is useful to CSIRTs when
+ describing their policies and services.
+
+ The Site Security Handbook Working Group is working on a User's Guide
+ to Internet Security. It will provide practical guidance to end users
+ to help them protect their information and the resources they use.
+
+1.5 Basic Approach
+
+ This guide is written to provide basic guidance in developing a
+ security plan for your site. One generally accepted approach to
+ follow is suggested by Fites, et. al. [ref] and includes the
+ following steps:
+
+ (1) Identify what you are trying to protect
+ (2) Determine what you are trying to protect it from
+ (3) Determine how likely the threats are
+ (4) Implement measures which will protect your assets in a cost-
+ effective manner.
+ (5) Review the process continuously and make improvements each time
+
+
+
+Site Security Working Group [Page 3]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ a weakness is found.
+
+
+ Most of this document is focused on item 4 above, but the other steps
+ cannot be avoided if an effective plan is to be established at your
+ site. One old truism in security is that the cost of protecting
+ yourself against a threat should be less than the cost of recovering
+ if the threat were to strike you. Without reasonable knowledge of
+ what you are protecting and what the likely threats are, following
+ this rule could be difficult.
+
+1.6 Risk Assessment
+
+1.6.1 General Discussion
+
+ One of the most important reasons for creating a computer security
+ policy is to ensure that efforts spent on security yield cost
+ effective benefits. Although this may seem obvious, it is possible
+ to be mislead about where the effort is needed. As an example, there
+ is a great deal of publicity about intruders on computers systems;
+ yet most surveys of computer security show that, for most
+ organizations, the actual loss from "insiders" is much greater.
+
+ Risk analysis involves determining what you need to protect, what you
+ need to protect it from, and how to protect it. It is the process of
+ examining all of your risks, then ranking those risks by level of
+ severity. This process involves making cost-effective decisions on
+ what you want to protect. As mentioned above, you should probably
+ not spend more to protect something than it is actually worth.
+
+ A full treatment of risk analysis is outside the scope of this
+ document. [3, FITES] and [16, PFLEEGER] provide introductions to
+ this topic. However, there are two elements of a risk analysis that
+ will be briefly covered in the next two sections:
+
+ (1) Identifying the assets
+ (2) Identifying the threats
+
+ For each asset, the basic goals of security are availability,
+ confidentiality, and integrity. Each threat should be examined with
+ an eye to how the threat could affect these areas.
+
+1.6.2 Identifying the Assets
+
+ One step in a risk analysis is to identify all the things that need
+ to be protected. Some things are obvious, like valuable proprietary
+ information, intellectual property, and all the various pieces of
+ hardware; but, some are overlooked, such as the people who actually
+ use the systems. The essential point is to list all things that could
+ be affected by a security problem.
+
+ One list of categories is suggested by Pfleeger [16, PFLEEGER, page
+ 459]; this list is adapted from that source:
+
+
+
+
+Site Security Working Group [Page 4]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ (1) Hardware: CPUs, boards, keyboards, terminals,
+ workstations, personal computers, printers, disk
+ drives, communication lines, terminal servers, routers.
+
+ (2) Software: source programs, object programs,
+ utilities, diagnostic programs, operating systems,
+ communication programs.
+
+ (3) Data: during execution, stored on-line, archived off-line,
+ backups, audit logs, databases, in transit over
+ communication media.
+
+ (4) People: users, administrators.
+
+ (5) Documentation: on programs, hardware, systems, local
+ administrative procedures.
+
+ (6) Supplies: paper, forms, ribbons, magnetic media.
+
+1.6.3 Identifying the Threats
+
+ Once the assets requiring protection are identified, it is necessary
+ to identify threats to those assests. The threats can then be
+ examined to determine what potential for loss exists. It helps to
+ consider from what threats you are trying to protect your assets.
+ The following are classic threats that should be considered.
+ Depending on your site, there will be more specific threats that
+ should be identified and addressed.
+
+ (1) Unauthorized access to resources and/or information
+ (2) Disclosure of information
+ (3) Denial of service
+
+2. Security Policies
+
+2.1 What is a Computer Security Policy and Why Have One?
+
+ The security-related decisions you make, or fail to make, as network
+ administrator largely determines how secure or insecure your network
+ is, how much functionality your network offers, and how easy your
+ network is to use. However, you cannot make good decisions about
+ security without first determining what your security goals are.
+ Until you determine what your security goals are, you cannot make
+ effective use of any collection of security tools because you simply
+ will not know what to check for and what restrictions to impose.
+
+ For example, your goals will probably be very different from the
+ goals of a product vendor. Vendors are trying to make configuration
+ and operation of their products as simple as possible, which implies
+ that the default configurations will often be as open (i.e.,
+ insecure) as possible. While this does make it easier to install new
+ products, it also leaves access to those systems, and other systems
+ through them, open to any user who wanders by.
+
+
+
+
+Site Security Working Group [Page 5]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Your goals will be largely determined by the following key tradeoffs:
+
+ (1) services offered vs. security provided -
+ Each service offered to users carries its own security risks.
+ For some services the risk outweighs the benefit of the service
+ and the administrator may choose to eliminate the service rather
+ than try to secure it.
+
+ (2) ease of use vs. security -
+ The easiest system to use would allow access to any user and requi=
+re
+ no passwords; that is, there would be no security. Requiring
+ passwords makes the system a little less convenient, but more secu=
+re.
+ Requiring device-generated one-time passwords makes the system eve=
+n
+ more difficult to use, but much more secure.
+
+ (3) cost of security vs. risk of loss -
+ There are many different costs to security: monetary (i.e., the
+ cost of purchasing security hardware and software like firewalls
+ and one-time password generators), performance (i.e., encryption
+ and decryption take time), and ease of use (as mentioned above).
+ There are also many levels of risk: loss of privacy (i.e., the
+ reading of information by unauthorized individuals), loss of
+ data (i.e., the corruption or erasure of information), and the
+ loss of service (e.g., the filling of data storage space, usage
+ of computational resources, and denial of network access). Each
+ type of cost must be weighed against each type of loss.
+
+
+ Your goals should be communicated to all users, operations staff, and
+ managers through a set of security rules, called a "computer security
+ policy."
+
+2.1.1 Definition of a Computer Security Policy
+
+ A computer security policy is a formal statement of the rules by
+ which people who are given access to an organization's technology and
+ information assets must abide.
+
+2.1.2 Purposes of a Computer Security Policy
+
+ The main purpose of a computer security policy is to inform users,
+ staff and managers of their obligatory requirements for protecting
+ technology and information assets. The policy should specify the
+ mechanisms through which these requirements can be met. Another
+ purpose is to provide a baseline from which to acquire, configure and
+ audit computer systems and networks for compliance with the policy.
+ Therefore an attempt to use a set of security tools in the absence of
+ at least an implied security policy is meaningless.
+
+ An Appropriate Use Policy (AUP) may also be part of a security
+ policy. It should spell out what users may and may not do on the
+ various components of the system, including the type of traffic
+ allowed on the networks. The AUP should be as explicit as possible
+ to avoid ambiguity or misunderstanding. For example, an AUP might
+
+
+
+Site Security Working Group [Page 6]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ list any prohibited USENET newsgroups.
+
+2.1.3 Who Should be Involved When Forming Policy?
+
+ In order for a security policy to be appropriate and effective, it
+ needs to have the acceptance and support of all levels of employees
+ within the organization. The following is a list of individuals who
+ should be involved in the creation and review of security policy
+ documents:
+
+ (1) site security administrator
+ (2) legal counsel
+ (3) computing center personnel
+ (4) administrators of large user groups within the organization
+ (e.g., business divisions, computer science department within a
+ university, etc.)
+ (5) security incident response team
+ (6) representatives of the user groups affected by the security policy
+
+ The list of above is representative of many organizations, but is not
+ necessarily comprehensive. The idea is to bring in representation
+ from key stakeholders, management who have budget and policy
+ authority, technical staff who know what can and cannot be supported,
+ and legal counsel who know the legal ramifications of various policy
+ choices. In some organizations, it may be appropriate to include
+ audit personnel. Involving this group is important if resulting
+ policy statements are to reach the broadest possible acceptance.
+
+2.2 What Makes a Good Computer Security Policy?
+
+ The characteristics of a good security policy are:
+
+ (1) It must be implementable through system administration
+ procedures, publishing of acceptable use guidelines, or other
+ appropriate methods.
+
+ (2) It must be enforcible with security tools, where appropriate,
+ and with sanctions, where actual prevention is not technically
+ feasible.
+
+ (3) It must clearly define the areas of responsibility for the
+ users, staff, and administrators.
+
+ The components of a good security policy include:
+
+ (1) Computer Technology Purchasing Guidelines which specify required,
+ or preferred, security features. These should supplement existing
+ purchasing policies and guidelines.
+
+ (2) A Privacy Policy which defines reasonable expectations of privacy
+ regarding such issues as monitoring of electronic mail, logging of
+ keystrokes, and access to users' files.
+
+ (3) An Access Policy which defines access rights and privileges to
+
+
+
+Site Security Working Group [Page 7]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ protect assets from loss or disclosure by specifying acceptable us=
+e
+ guidelines for users, operations staff, and management. It should
+ provide guidelines for external connections, data communications,
+ connecting devices to a network, and adding new software to
+ systems. It should also specify any required notification message=
+s
+ (e.g., connect messages should provide warnings about authorized
+ usage and line monitoring, and not simply say "Welcome").
+
+ (4) An Accountability Policy which defines the responsibilities of use=
+rs,
+ operations staff, and management. It should specify an audit
+ capability, and provide incident handling guidelines (i.e., what t=
+o
+ do and who to contact if a possible intrusion is detected).
+
+ (5) An Authentication Policy which establishes trust through an effect=
+ive
+ password policy, and by setting guidelines for remote location
+ authentication and the use of authentication devices (e.g., one-ti=
+me
+ passwords and the devices that generate them).
+
+ (6) An Availability statement which sets users' expectations for the
+ availability of resources. It should address redundancy and recov=
+ery
+ issues, as well as specify operating hours and maintenance down-ti=
+me
+ periods. It should also include contact information for reporting
+ system and network failures.
+
+ (7) A Violations Reporting Policy that indicates which types of
+ violations (e.g., privacy and security, internal and external)
+ must be reported and to whom the reports are made. A
+ non-threatening atmosphere and the possibility of anonymous report=
+ing
+ will result in a greater probability that a violation will be
+ reported if it is detected.
+
+ (8) Supporting Information which provides users, staff, and management
+ with contact information for each type of policy violation;
+ guidelines on how to handle outside queries about a security incid=
+ent,
+ or information which may be considered confidential or proprietary=
+;
+ and cross-references to security procedures and related informatio=
+n,
+ such as company policies and regulatory requirements (federal, sta=
+te,
+ and local).
+
+ There may be regulatory requirements that affect some aspects of your
+ security policy (e.g., line monitoring). The creators of the
+ security policy should consider seeking legal assistance in the
+ creation of the policy. At a minimum, the policy should be reviewed
+ by legal counsel.
+
+ Once your computer security policy has been established it should be
+ clearly communicated to users, staff, and management. Having all
+ personnel sign a statement indicating that they have read,
+ understood, and agreed to abide by the policy is an important part of
+ the process. Finally, your policy should be reviewed on a regular
+ basis to see if it is successfully supporting your security needs.
+
+2.3 Keeping the Policy Flexible
+
+
+
+
+Site Security Working Group [Page 8]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ In order for a security policy to be viable for the long term, it
+ requires a lot of flexibility. The mechanisms for updating the
+ policy should be clearly spelled out. This includes the process, the
+ people involved, and the people who must sign-off on the changes.
+
+ It is also important to recognize that there are exceptions to every
+ rule. Whenever possible, the policy should spell out what exceptions
+ to the general policy exist. For example, under what conditions is a
+ system administrator allowed to go through a user's files. Also,
+ there may be some cases when multiple users will have access to the
+ same userid. For example, on systems with a "root" user, multiple
+ system administrators may know the password and use the root account.
+
+ Another consideration is called the "Garbage Truck Syndrome." This
+ refers to what would happen to a site if a key person was suddenly
+ unavailable for his/her job function (e.g., was suddenly ill or left
+ the company unexpectedly). While the greatest security resides in
+ the minimum dissemination of information, the risk of losing critical
+ information increases when that information is not shared. It is
+ necessary to determine what the proper balance is for your site.
+
+3. Architecture
+
+3.1 Objectives
+
+3.1.1 Completely defined security plans
+
+ Defining a comprehensive security plan should be done by all sites.
+ This plan should be at a higher level than the specific policies
+ discussed in section 2. It should be crafted as a framework of broad
+ guidelines into which specific policies will fit.
+
+ It is important to have this framework in place so that individual
+ policies can be consistant with the overall site security
+ architecture. For example, having a strong policy with regard to
+ Internet access and having weak restrictions on modem usage is
+ inconsistent with an overall philosophy of strong security
+ restrictions on external access.
+
+ A security policy should contain, at a minimum: a list of services
+ which are currently, or will be, provided; who will have access to
+ those services; how access will be provided; who will administer
+ those services; etc. It is also important to define any limitations
+ on which portions of an organization can provide certain services.
+
+ Another aspect of the plan should concern incident handling. Chapter
+ 5 provides an in-depth discussion of responses to incidents, but it
+ is important to define classes of incidents and define responses to
+ each class of incident. For sites with firewalls, how many attempts
+ to foil the firewall will trigger a response? Are there levels of
+ escallation in both attacks and responses? For sites without
+ firewalls, does a single attempt to connect constitute an incident?
+ How about a systematic scan of machines?
+
+
+
+
+Site Security Working Group [Page 9]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ For sites connected to the Internet, the rampant media glorification
+ of Internet related security incidents can overshadow a (potentially)
+ more serious internal security problem. Likewise, companies who have
+ never been on the Internet before, may have strong, well defined,
+ internal policies but fail to adequately address an external
+ connection policy.
+
+3.1.2 Separation of Services
+
+ There are many services which a site may wish to provide for its
+ users, some of which may be external. There are a variety of
+ security reasons to attempt to isolate services onto dedicated
+ machines. There are also performance reasons in most cases, but a
+ detailed discussion is beyond to scope of this document.
+
+ The services which a site may provide will, in most cases, have
+ different levels of access needs and models of trust. Services which
+ are essential to the security or smooth operation of a site would be
+ better off being placed on a dedicated machine with very limited
+ access (see Section 3.1.3 "deny all" model), rather than on a machine
+ which provides a service (or services) which has traditionally been
+ less secure, or requires greater accessability by users who may
+ accidentally suborn security.
+
+ It is also important to distinguish between machines which operate
+ within different models of trust, i.e., all the machines inside of a
+ firewall and any machines on an exposed network.
+
+ Some of the services which should be examined for potential
+ separation are outlined in section 3.2.3. It is important to try to
+ understand that security is only as strong as the weakest link in the
+ chain. Several of the most publicized penetrations in recent years
+ has been through the electronic mail systems of machines. The
+ intruders were not trying to steal electronic mail, but they used the
+ vulnerability in that system to gain access to other systems.
+
+ If possible, each service should be running on a different machine
+ whose only duty is to provide a specific service. This helps to
+ isolate intruders and limit potential harm.
+
+3.1.3 Deny all/ Allow all
+
+ There are two diametrically opposed underlying philosophies which can
+ be adopted in defining a security plan. Both alternatives are
+ legitimate models to adopt, depending on the site and its needs for
+ security.
+
+ The first option is to turn off all services and then selectively
+ enable services on a case by case basis, be it at the machine or
+ network level, as they are needed. This model, which will here after
+ be referred to as the "deny all" model, is generally more secure.
+ More work is required to successfully implement a "deny all"
+ configuration and usually a better understanding of services. Only
+ allowing known services allows a better analysis of a particular
+
+
+
+Site Security Working Group [Page 10]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ service/protocol and the design of a security mechanism suited to the
+ security level of the site.
+
+ The other model, which will here after be referred to as the "allow
+ all" model, is much easier to implement, but is generally less secure
+ than the "deny all" model. Simply turn on all services, usually the
+ default at the host level, and allow all protocols to travel across
+ network boundaries, usually the default at the router level. As
+ security holes become apparent, they are patched at either the host
+ or network level.
+
+ Each of these models can be applied to different portions of the
+ site, depending on functionality requirements, administrative
+ control, site policy, etc. For example, the policy may be to use the
+ "allow all" model when setting up workstations for general use, but
+ adopt a "deny all" model when setting up information servers, like an
+ email hub. Likewise, an "allow all" policy may be adopted for
+ traffic between LAN's internal to the site, but a "deny all" policy
+ can be adopted between the site and the Internet.
+
+ Be careful when mixing philosophies as in the examples above. Many
+ sites adopt the M & M theory of a hard "crunchy" shell and a soft
+ "squishy" middle. They are willing to pay the cost of security for
+ their external traffic and require strong security measures, but are
+ unwilling or unable to provide similar protections internally. This
+ works fine as long as the outer defenses are never breached and the
+ internal users can be trusted. Once the outer shell (firewall) is
+ breached, subverting the internal network is trivial.
+
+3.1.4 Identify real needs for services
+
+ There is a large variety of services which may be provided, both
+ internally and on the Internet at large. Managing security is, in
+ many ways, managing access to services internal to the site and
+ managing how internal users access information at remote sites.
+
+ Services tend to rush like waves over the Internet. Over the years
+ many sites have established anonymous FTP servers, gopher servers,
+ wais servers, WWW servers, etc. as they became popular, but not
+ particularly needed, at all sites. Evaluate all new services that
+ are established with a skeptical attitude to determine if they are
+ actually needed or just the current fad sweeping the Internet.
+
+ Bear in mind that security complexity can grow exponentially with the
+ number of services provided. Filtering routers need to be modified
+ to support the new protocols. Some protocols are inherently
+ difficult to filter safely (e.g., RPC and UDP services), thus
+ providing more openings to the internal network. Services provided
+ on the same machine can interact in catastrophic ways. For example,
+ allowing anonymous FTP on the same machine as the WWW server may
+ allow an intruder to place a file in the anonymous FTP area and cause
+ the HTTP server to execute it.
+
+3.2 Network and Service Configuration
+
+
+
+Site Security Working Group [Page 11]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+3.2.1 Protecting the Infrastructure
+
+ Many network administrators go to great lengths to protect the hosts
+ on their networks. Few administrators make any effort to protect the
+ networks themselves. There is some rationale to this. For example,
+ it is far easier to protect a host than a network. Also, intruders
+ are likely to be after data on the hosts; damaging the network would
+ not serve their purposes. That said, there are still reasons to
+ protect the networks. For example, an intruder might divert network
+ traffic through an outside host in order to examine the data (i.e.,
+ to search for passwords). Also, infrastructure includes more than
+ the networks and the routers which interconnect them. Infrastructure
+ also includes network management (e.g., SNMP), services (e.g., DNS,
+ NFS, NTP, WWW), and security (i.e., user authentication and access
+ restrictions).
+
+ The infrastructure also needs protection against human error. When
+ an administrator misconfigures a host, that host may offer degraded
+ service. This only affects users who require that host and, unless
+ that host is a primary server, the number of affected users will
+ therefore be limited. However, if a router is misconfigured, all
+ users who require the network will be affected. Obviously, this is a
+ far larger number of users than those depending on any one host.
+
+3.2.2 Protecting the Network
+
+ There are several problems to which networks are vulnerable. The
+ classic is a "denial of service" attack. In this case, the network
+ is brought to a state in which it can no longer carry legitimate
+ users' data. There are two common ways this can be done: by
+ attacking the routers and by flooding the network with extraneous
+ traffic. An attack on the router is designed to cause it to stop
+ forwarding packets, or to forward them improperly. The former case
+ may be due to a misconfiguration, the injection of a spurious routing
+ update, or a "flood attack" (i.e., the router is bombarded with
+ unroutable packets, causing its performance to degrade). A flood
+ attack on a network is similar to a flood attack on a router, except
+ that the flood packets are usually broadcast. An ideal flood attack
+ would be the injection of a single packet which exploits some known
+ flaw in the network nodes and causes them to retransmit the packet,
+ or generate error packets, each of which is picked up and repeated by
+ another host. A well chosen attack packet can even generate an
+ exponential explosion of transmissions.
+
+ Another classic problem is "spoofing." In this case, spurious
+ routing updates are sent to one or more routers causing them to
+ misroute packets. This differs from a denial of service attack only
+ in the purpose behind the spurious route. In denial of service, the
+ object is to make the router unusable; a state which will be quickly
+ detected by network users. In spoofing, the spurious route will
+ cause packets to be routed to a host from which an intruder may
+ monitor the data in the packets. These packets are then re-routed to
+ their correct destinations. However, the intruder may or may not
+ have altered the contents of the packets.
+
+
+
+Site Security Working Group [Page 12]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ The solution to most of these problems is to protect the routing
+ update packets sent by the routing protocols in use (e.g., RIP-2,
+ OSPF). There are three levels of protection: clear-text password,
+ cryptographic checksum, and encryption. Passwords offer only minimal
+ protection against intruders who do not have direct access to the
+ physical networks. Passwords also offer some protection against
+ misconfigured routers (i.e, routers which, out of the box, attempt to
+ route packets). The advantage of passwords is that they have a very
+ low overhead, in both bandwidth and CPU consumption. Checksums
+ protect against the injection of spurious packets, even if the
+ intruder has direct access to the physical network. Combined with a
+ sequence number, or other unique identifier, a checksum can also
+ protect again "replay" attacks, wherein an old (but valid at the
+ time) routing update is retransmitted by either an intruder or a
+ misbehaving router. The most security is provided by complete
+ encryption of sequenced, or uniquely identified, routing updates.
+ This prevents an intruder from determining the topology of the
+ network. The disadvantage to encryption is the overhead involved in
+ processing the updates.
+
+ RIP-2 (RFC 1723) and OSPF (RFC 1583) both support clear-text
+ passwords in their base design specifications. In addition, there
+ are extensions to each base protocol to support MD5 encryption.
+
+ Unfortunately, there is no adequate protection against a flooding
+ attack, or a misbehaving host or router which is flooding the
+ network. Fortunately, this type of attack is obvious when it occurs
+ and can usually be terminated relatively simply.
+
+3.2.3 Protecting the Services
+
+ There are many types of services and each has its own security
+ requirements. These requirements will vary based on the intended use
+ of the service. For example, a service which should only be usable
+ within a site (e.g., NFS) may require different protection mechanisms
+ than a service provided for external use. It may be sufficient to
+ protect the internal server from external access. However, a WWW
+ server, which provides a home page intended for viewing by users
+ anywhere on the Internet, requires built-in protection. That is, the
+ service/protocol/server must provide whatever security may be
+ required to prevent unauthorized access and modification of the Web
+ database.
+
+ Internal services (i.e., services meant to be used only by users
+ within a site) and external services (i.e., services deliberately
+ made available to users outside a site) will, in general, have
+ protection requirements which differ as previously described. It is
+ therefore wise to isolate the internal services to one set of server
+ machines and the external services to another set of server machines.
+ That is, internal and external servers should not be co-located. In
+ fact, many sites go so far as to have one set of subnets (or even
+ different networks) which are accessible from the outside and another
+ set which may be accessed only within the site. Of course, there is
+ usually a firewall which connects these partitions. Great care must
+
+
+
+Site Security Working Group [Page 13]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ be taken to ensure that such a firewall is operating properly.
+
+ One form of external service deserves some special consideration, and
+ that is anonymous, or guest, access. This may be either anonymous
+ FTP or guest (unauthenticated) login. It is extremely important to
+ ensure that anonymous FTP servers and guest login userids are
+ carefully isolated from any hosts and file systems from which outside
+ users should be kept. Another area to which special attention must
+ be paid concerns anonymous, writable access. A site may be legally
+ responsible for the content of publicly available information, so
+ careful monitoring of the information deposited by anonymous users is
+ advised.
+
+ Now we shall consider some of the most popular services: name
+ service, password/key service, authentication/proxy service,
+ electronic mail, WWW, file transfer, and NFS. Since these are the
+ most frequently used services, they are the most obvious points of
+ attack. Also, a successful attack on one of these services can
+ produce disaster all out of proportion to the innocence of the basic
+ service.
+
+3.2.3.1 Name Servers (DNS and NIS(+))
+
+ The Internet uses the Domain Name System (DNS) to perform address
+ resolution for host and network names. The Network Information
+ Service (NIS) and NIS+ are not used on the global Internet, but are
+ subject to the same risks as a DNS server. Name-to-address
+ resolution is critical to the secure operation of any network. An
+ attacker who can successfully control or impersonate a DNS server can
+ re-route traffic to subvert security protections. For example,
+ routine traffic can be diverted to a compromised system to be
+ monitored; or, users can be tricked into providing authentication
+ secrets. An organization should create well known, protected sites
+ to act as secondary name servers and protect their DNS masters from
+ denial of service attacks using filtering routers.
+
+3.2.3.2 Password/Key Servers (NIS(+) and KDC)
+
+ Password and key servers generally protect their vital information
+ (i.e., the passwords and keys) with encryption algorithms. However,
+ even a one-way encrypted password can be determined by a dictionary
+ attack (wherein common words are encrypted to see if they match the
+ stored encryption). It is therefore necessary to ensure that these
+ servers are not accessable by hosts which do not plan to use them for
+ the service, and even those hosts should only be able to access the
+ service (i.e., general services, such as Telnet and FTP, should not
+ be allowed by anyone other than administrators).
+
+3.2.3.3 Authentication/Proxy Servers (SOCKS, FWTK)
+
+ A proxy server provides a number of security enhancements. It allows
+ sites to concentrate services through a specific host to allow
+ monitoring, hiding of internal structure, etc. This funnelling of
+ services creates an attractive target for a potential intruder. The
+
+
+
+Site Security Working Group [Page 14]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ type of protection required for a proxy server depends greatly on the
+ proxy protocol in use and the services being proxied. The general
+ rule of limiting access only to those hosts which need the services,
+ and limiting access by those hosts to only those services, is a good
+ starting point.
+
+3.2.3.4 Electronic Mail
+
+ Electronic mail (email) systems have long been a source for intruder
+ break-ins because email protocols are among the oldest and most
+ widely deployed services. Also, by it's very nature, an email server
+ requires access to the outside world; most email servers accept input
+ from any source. An email server generally consists of two parts: a
+ receiving/sending agent and a processing agent. Since email is
+ delivered to all users, and is usually private, the processing agent
+ typically requires system (root) privileges to deliver the mail.
+ Most email implementations perform both portions of the service,
+ which means the receiving agent also has system privileges. This
+ opens several security holes which this document will not describe.
+ There are some implementations available which allow a separation of
+ the two agents. Such implementations are generally considered more
+ secure, but still require careful installation to avoid creating a
+ security problem.
+
+3.2.3.5 World Wide Web (WWW)
+
+ The Web is growing in popularity exponentially because of its ease of
+ use and the powerful abilities to concentrate information services.
+ Most WWW servers take some directions and actions from the persons
+ accessing their services. The most common example is taking a
+ request from a remote user and passing the provided information to a
+ program running on the server to process the request. Some of these
+ programs are not written with security in mind and can create
+ security holes. If a Web server is available to the Internet
+ community, it is especially important that confidential information
+ not be co-located on the same host as the server. In fact, it is
+ recommended that the server have a dedicated host which is not
+ "trusted" by other internal hosts. It may be co-located with an
+ anonymous FTP server, since both protocols share common security
+ considerations.
+
+3.2.3.6 File Transfer (FTP, TFTP)
+
+ FTP and TFTP both allow users to receive and send electronic files in
+ a point-to-point manner. However, FTP requires authentication while
+ TFTP requires none. For this reason, TFTP should be avoided as much
+ as possible.
+
+ Improperly configured FTP servers can allow intruders to copy,
+ replace and delete files at will, anywhere on a host, so it is very
+ important to configure this service correctly. Access to encrypted
+ passwords and proprietary data, and the introduction of trojan horses
+ are just a few of the potential security holes that can occur when
+ the service is configured incorrectly. FTP servers should reside on
+
+
+
+Site Security Working Group [Page 15]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ their own host, or perhaps be co-located with a Web server, since the
+ two protocols share common security considerations. As mentioned in
+ the opening paragraphs of section 3.2.3, services offered internally
+ to your site should not be co-located with services offered
+ externally. Each should have its own host.
+
+ TFTP does not support the same range of functions and has no security
+ whatsoever. This service should only be considered for internal use,
+ and then it should be configured in a restricted way so that the
+ server only has access to a set of predetermined files (instead of
+ every world-readable file on the system). Probably the most common
+ usage of TFTP is for downloading router configuration files to a
+ router. TFTP should reside on its own host, and should not be
+ installed on hosts supporting external FTP or Web access.
+
+3.2.3.7 NFS
+
+ The Network File Service allows hosts to share common disks. NFS is
+ most frequently used by diskless hosts who depend on a disk server
+ for all of their storage needs. Unfortunately, NFS has no built-in
+ security. It is therefore necessary that the NFS server be
+ accessable only by those hosts which are using it for service. It is
+ especially important that external hosts be unable to reach the NFS
+ host by any means. Ideally, such access attempts would be stopped by
+ a firewall.
+
+3.2.4 Protecting the Protection
+
+ It is amazing how often a site will overlook the most obvious
+ weakness in its security by leaving the security server itself open
+ to attack. Based on considerations previously discussed, it should
+ be clear that: the security server should not be accessible from
+ off-site; should offer minimum access, except for the authentication
+ function, to users on-site; and should not be co-located with any
+ other servers. Further, all access to the node, including access to
+ the service itself, should be logged to provide a "paper trail" in
+ the event of a security breach.
+
+3.3 Firewalls
+
+ One of the most widely deployed and publicized security measures in
+ use on the Internet is a "firewall." Firewalls have been given the
+ reputation of a general panacea for many, if not all, of the Internet
+ security issues. They are not. Firewalls are just another tool in
+ the quest for system security. They provide a certain level of
+ protection and are, in general, a way of implementing security policy
+ at the network level. The level of security that a firewall provides
+ can vary as much as the level of security on a particular machine.
+ There are the traditional trade-offs between security, ease of use,
+ cost, complexity, etc.
+
+ A firewall is any one of several mechanisms used to control and watch
+ access to and from a network for the purpose of protecting it. A
+ firewall acts as a gateway through which all traffic to and from the
+
+
+
+Site Security Working Group [Page 16]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ protected network or machines passes. Firewalls help to place
+ limitations on the amount and type of communication that takes place
+ between the protected network and the another network (e.g., the
+ Internet, or another piece of the site's network).
+
+ A firewall is generally a way to build a wall between one part of a
+ network, a company=D5s internal network, for example, and another part,
+ the global Internet, for example. The unique feature about this wall
+ is that there needs to be ways for some traffic with particular
+ characteristics to pass through carefully monitored doors
+ ("gateways"). The difficult part is to establish the criteria by
+ which the packets are allowed or denied access through the doors.
+ Different books written on firewalls use different terminology to
+ describe the various forms of firewalls. This can be confusing to
+ system administrators who are not familiar with firewalls. The thing
+ to note here is that there is no fixed terminology for the
+ description of firewalls.
+
+ Firewalls are not always, or even typically, a single machine, but in
+ general are a combination of routers, networks, and host machines, so
+ for the purposes of this discussion, the term "firewall" can consist
+ of more than one physical device. Firewalls are typically built
+ using two different components, filtering routers and proxy servers.
+
+ Filtering routers are the easiest component to conceptualize in a
+ firewall. A router moves data back and forth between two (or more)
+ different networks. A "normal" router takes a packet from network A
+ and "routes" it to its destination on network B. A filtering router
+ does the same thing but decides not only how to route the packet, but
+ should it route the packet. This is done by installing a series of
+ filters by which the router decides what to do with any given packet
+ of data.
+
+ A discussion concerning capabilities of a particular brand of router,
+ running a particular software version is outside the scope of this
+ document. However, when evaluating a router to be used for filtering
+ packets, the following criteria can be important when implementing a
+ filtering policy: source and destination IP address, source and
+ destination TCP port numbers, state of the TCP "ack" bit, UDP source
+ and destination port numbers, and direction of packet flow (i.e.. A-
+ >B or B->A). Other information necessary to construct a secure
+ filtering scheme are whether the router reorders filter instructions
+ (designed to optimize filters, this can sometimes change the meaning
+ and cause unintended access), and whether it is possible to apply
+ filters for inbound and outbound packets on each interface (if the
+ router filters only outbound packets then the router is "outside" of
+ its filters and may be more vulnerable to attack). In addition to
+ the router being vulnerable, this distinction between applying
+ filters on inbound or outbound packets is especially relevant for
+ routers with more than 2 interfaces. Other important issues are the
+ ability to create filters based on IP header options and the fragment
+ state of a packet. Building a good filter can be very difficult and
+ requires a good understanding of the type of services (protocols)
+ that will be filtered.
+
+
+
+Site Security Working Group [Page 17]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ For better security, the filters usually restrict access between the
+ two connected nets to just one host, the bastion host. It is only
+ possible to access the other network via this bastion host. As only
+ this host, rather than a few hundred hosts, can get attacked, it is
+ easier to maintain a certain level of security because only this host
+ has to be protected very carefully. To make resources available to
+ legitimate users across this firewall, services have to be forwarded
+ by the bastion host. Some servers have forwarding built in (like
+ DNS-servers or SMTP-servers), for other services (e.g., Telnet, FTP,
+ etc.), proxy servers can be used to allow access to the resources
+ across the firewall in a secure way.
+
+ A proxy server is way to concentrate application services through a
+ single machine. There is typically a single machine (the bastion
+ host) that acts as a proxy server for a variety of protocols (Telnet,
+ SMTP, FTP, HTTP, etc.) but there can be individual machines for each
+ service. Instead of connecting directly to an external server, the
+ client connects to the proxy server which in turn initiates a
+ connection to the requested external server. Depending on the type
+ of proxy server used, it is possible to configure internal clients to
+ perform this redirection automatically, without knowledge to the
+ user, others might require that the user connect directly to the
+ proxy server and then initiate the connection through a specified
+ format.
+
+ There are significant security benefits which can be derived from
+ using proxy servers. It is possible to add access control lists to
+ protocols, requiring users or machines to provide some level of
+ authentication before access is granted. Smarter proxy servers,
+ sometimes called Application Layer Gateways (ALGs), can be written
+ which understand specific protocols and can be configured to block
+ only subsections of the protocol. For example, an ALG for FTP can
+ tell the difference between the "put" command and the "get" command;
+ an organization may wish to allow users to "get" files from the
+ Internet, but not be able to "put" internal files on a remote server.
+ By contrast, a filtering router could either block all FTP access, or
+ none, but not a subset.
+
+ Proxy servers can also be configured to encrypt data streams based on
+ a variety of parameters. An organization might use this feature to
+ allow encrypted connections between two locations whose sole access
+ points are on the Internet.
+
+ Firewalls are typically thought of as a way to keep intruders out,
+ but they are also often used as a way to let legitimate users into a
+ site. There are many examples where a valid user might need to
+ regularly access the "home" site while on travel to trade shows and
+ conferences, etc. Access to the Internet is often available but may
+ be through an untrusted machine or network. A correctly configured
+ proxy server can allow the correct users into the site while still
+ denying access to other users.
+
+ The current best effort in firewall techniques is found using a
+ combination of a pair of screening routers with one or more proxy
+
+
+
+Site Security Working Group [Page 18]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ servers on a network between the two routers. This setup allows the
+ external router to block off any attempts to use the underlying IP
+ layer to break security (IP spoofing, source routing, packet
+ fragments), while allowing the proxy server to handle potential
+ security holes in the higher layer protocols. The internal router's
+ purpose is to block all traffic except to the proxy server. If this
+ setup is rigidly implemented, a high level of security can be
+ achieved.
+
+ Most firewalls provide logging which can be tuned to make security
+ administration of the network more convenient. Logging may be
+ centralized and the system may be configured to send out alerts for
+ abnormal conditions. It is important to regularly monitor these logs
+ for any signs of intrusions or break-in attempts. Since some
+ intruders will attempt to cover their tracks by editing logs, it is
+ desirable to protect these logs. A variety of methods is available,
+ including: write once, read many (WORM) drives; papers logs; and
+ centralized logging via the "syslog" utility. Another technique is
+ to use a "fake" serial printer, but have the serial port connected to
+ an isolated machine or PC which keeps the logs.
+
+ Firewalls are available in a wide range of quality and strengths.
+ Commercial packages start at approximately $10,000US and go up to
+ over $250,000US. "Home grown" firewalls can be built for smaller
+ amounts of capital. It should be remembered that the correct setup
+ of a firewall (commercial or homegrown) requires a significant amount
+ of skill and knowledge of TCP/IP. Both types require regular
+ maintenance, installation of software patches and updates, and
+ regular monitoring. When budgeting for a firewall, these additional
+ costs should be considered in addition to the cost of the physical
+ elements of the firewall.
+
+ As an aside, building a "home grown" firewall requires a significant
+ amount of skill and knowledge of TCP/IP. It should not be trivially
+ attempted because a perceived sense of security is worse in the long
+ run than knowing that there is no security. As with all security
+ measures, it is important to decide on the threat, the value of the
+ assets to be protected, and the costs to implement security.
+
+ A final note about firewalls. They can be a great aid when
+ implementing security for a site and they protect against a large
+ variety of attacks. But it is important to keep in mind that they
+ are only one part of the solution. They cannot protect your site
+ against all types of attack.
+
+4. Security Services and Procedures
+
+ This chapter guides the reader through a number of topics that should
+ be addressed when securing a site. Each section touches on a
+ security service or capability that may be required to protect the
+ information and systems at a site. These are presented at a fairly
+ high-level to introduce the reader to the concepts.
+
+ Throughout the chapter, you will find considerable mention of
+
+
+
+Site Security Working Group [Page 19]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ cryptography. It is outside the scope of this document to delve into
+ details concerning cryptography, but the interested reader can obtain
+ more information from books and articles listed in the reference
+ section of this document.
+
+4.1 Authentication
+
+ For many years, the prescribed method for authenticating users has
+ been through the use of standard, reusable passwords. Originally,
+ these passwords were used by users at terminals to authenticate
+ themselves to a central computer. At the time, there were no
+ networks (internally or externally), so the risk of disclosure of the
+ clear text password was minimal. Today, systems are connected
+ together through local networks, and these local networks are further
+ connected together and to the Internet. Users are logging in from
+ all over the globe; their reusable passwords are often transmitted
+ across those same networks in clear text, ripe for anyone in-between
+ to capture. And indeed, the CERT Coordination Center and other
+ response teams are seeing a tremendous number of incidents involving
+ packet sniffers which are capturing the clear text passwords. To
+ address this threat, we are including sections on better
+ technologies, like one-time passwords and Kerberos.
+
+ With the advent of newer technologies like one-time passwords (e.g.,
+ S/Key), PGP, and token-based authentication devices, people are using
+ password-like strings as secret tokens and pins. We are including a
+ discussion on these since they are the foundation upon which stronger
+ authentication techniques are based. If these secret tokens and pins
+ are not properly selected and protected, the authentication will be
+ easily subverted.
+
+4.1.1 One-Time passwords
+
+ As mentioned above, given today's networked environments, it is
+ recommended that sites concerned about the security and integrity of
+ their systems and networks consider moving away from standard,
+ reusable passwords. There have been many incidents involving Trojan
+ network programs (e.g., telnet and rlogin) and network packet
+ sniffing programs. These programs capture clear text
+ hostname/account name/password triplets. Intruders can use the
+ captured information for subsequent access to those hosts and
+ accounts. This is possible because 1) the password is used over and
+ over (hence the term "reusable"), and 2) the password passes across
+ the network in clear text.
+
+ Several authentication techniques have been developed that address
+ this problem. Among these techniques are challenge-response
+ technologies that provide passwords that are only used once (commonly
+ called one-time passwords). This document provides a list of sources
+ for products that provide this capability. The decision to use a
+ product is the responsibility of each organization, and each
+ organization should perform its own evaluation and selection.
+
+4.1.2 Kerberos
+
+
+
+Site Security Working Group [Page 20]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Kerberos is a distributed network security system which provides for
+ authentication across unsecured networks. If requested by the
+ application, integrity and encryption can also be provided. Kerberos
+ was originally developed at the Massachusetts Institute of Technology
+ (MIT) in the late 1980's. There are two major releases of Kerberos,
+ version 4 and 5, which are for practical purposes, incompatible.
+
+ Kerberos relies on a symmetric key database using a key distribution
+ center (KDC) which is known as the Kerberos server. A user or
+ service (known as "principals") are granted electronic "tickets"
+ after properly communicating with the KDC. These tickets are used
+ for authentication between principals. All tickets include a time
+ stamp which limits the time period for which the ticket is valid.
+ Therefore, Kerberos clients and server must have a secure time
+ source, and be able to keep time accurately.
+
+ The practical side of Kerberos is its integration with the
+ application level. Typical applications like FTP, telnet, POP, and
+ NFS have been integrated with the Kerberos system. There are a
+ variety of implementations which have varying levels of integration.
+ Please see the Kerberos FAQ available at http://www.ov.com/misc/krb-
+ faq.html for the latest information.
+
+4.1.3 Choosing and Protecting Secret Tokens and PINs
+
+ When selecting secret tokens, take care to choose them carefully.
+ Like the selection of passwords, they should be robust against brute
+ force efforts to guess them. That is, they should not be single
+ words in any language, any common, industry, or cultural acronyms,
+ etc. Ideally, they will be longer rather than shorter and consist of
+ pass phrases that combine upper and lower case character, digits, and
+ other characters.
+
+ Once chosen, the protection of these secret tokens is very important.
+ Some are used as pins to hardware devices (like token cards) and
+ these should not be written down and placed in the same location as
+ the device with which they are associated. Others, such as a secret
+ PGP key, should be protected from unauthorized access.
+
+ One final word on this subject. When using cryptography products,
+ like PGP, take care to determine the proper key length and ensure
+ that your users are trained to do likewise. As technology advances,
+ the minimum safe key length continues to grow. Make sure your site
+ keeps up with the current state of knowledge on the subject so that
+ you can ensure any cryptography used will be providing you the
+ protection you are assuming it is.
+
+4.1.4 Password Assurance
+
+ While the need to eliminate the use of standard, reusable passwords
+ cannot be overstated, it is recognized that some organizations may
+ have to transition to the use of better technology. Given that
+ situation, we have included the following advice to help with the
+ selection and maintenance of traditional passwords. But remember,
+
+
+
+Site Security Working Group [Page 21]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ none of these measures provides protection against disclosure due to
+ sniffer programs.
+
+ (1) The importance of robust passwords - In many (if not most) cases o=
+f
+ system penetration, the intruder needs to gain access to an accoun=
+t
+ on the system. One way that goal is typically accomplished is
+ through guessing the password of a legitimate user. This is often
+ accomplished by running an automated password cracking program,
+ which utilizes a very large dictionary, against the system's passw=
+ord
+ file. The only way to guard against passwords being disclosed in =
+this
+ manner is through the careful selection of passwords which cannot =
+be
+ easily guessed (i.e., combinations of numbers, letters, and punctu=
+ation
+ characters).
+
+ (2) Changing default passwords - Many operating systems and applicatio=
+n
+ programs are installed with default accounts and passwords. These
+ must be changed immediately to something that cannot be guessed or
+ cracked.
+
+ (3) Restricting access to the password file - In particular, a site
+ wants to protect the encrypted password portion of the file so tha=
+t
+ would-be intruders don't have them available for cracking. One
+ effective technique is to use shadow passwords where the password
+ field of the standard file contains a dummy or false password. Th=
+e
+ file containing the legitimate passwords are protected elsewhere o=
+n
+ the system.
+
+ (4) Password aging - When and how to expire passwords is still a subje=
+ct
+ of controversy among the security community. It is generally acce=
+pted
+ that a password should not be maintained once an account is no lon=
+ger in
+ use, but it is hotly debated whether a user should be forced to ch=
+ange a
+ good password that's in active use. The arguments for changing
+ passwords relate to the prevention of the continued use of penetra=
+ted
+ accounts. However, the opposition claims that frequent password
+ changes lead to users writing down their passwords in visible area=
+s
+ (such as pasting them to a terminal), or to users selecting very s=
+imple
+ passwords that are easy to guess. It should also be stated that a=
+n
+ intruder will probably use a captured or guessed password sooner r=
+ather
+ than later, in which case password aging provides little if any
+ protection.
+
+ While there is no definitive answer to this dilemma, a password po=
+licy
+ should directly address the issue and provide guidelines for how o=
+ften
+ a user should change the password. It is recommended that passwor=
+ds
+ be changed whenever root is penetrated, there is a critical change=
+ in
+ personnel (especially if it is the system administrator!), or when=
+ an
+ account has been compromised. In particular, if the root password=
+ is
+ compromised, all passwords on the system should be changed. In
+ addition, an annual change in their password is usually not diffic=
+ult
+ for most users, and you should consider requiring it.
+
+4.2 Confidentiality
+
+ There will be information assets that your site will want to protect
+
+
+
+Site Security Working Group [Page 22]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ from disclosure to unauthorized entities. Operating systems often
+ have built-in file protection mechanisms that allow an administrator
+ to control who on the system can access, or "see," the contents of a
+ given file. A stronger way to provide confidentiality is through
+ encryption. Encryption is accomplished by scrambling data so that it
+ is very difficult and time consuming for anyone other than the
+ authorized recipients or owners to obtain the plain text. Authorized
+ recipients and the owner of the information will possess the
+ corresponding decryption keys that allow them to easily unscramble
+ the text to a readable (clear text) form. We recommend that sites
+ use encryption to provide confidentiality and protect valuable
+ information.
+
+ The use of encryption is sometimes controlled by governmental and
+ site regulations, so we encourage administrators to become informed
+ of laws or policies that regulate its use before employing it. It is
+ outside the scope of this document to discuss the various algorithms
+ and programs available for this purpose, but we do caution against
+ the casual use of the UNIX crypt program as it has been found to be
+ easily broken. We also encourage you to take time to understand the
+ strength of the encryption in any given algorithm/product before
+ using it. Most well-known products are well-documented in the
+ literature, so this should be a fairly easy task.
+
+4.3 Integrity
+
+ As an administrator, you will want to make sure that information
+ (e.g., operating system files, company data, etc.) has not been
+ altered in an unauthorized fashion. This means you will want to
+ provide some assurance as to the integrity of the information on your
+ systems. One way to provide this is to produce a checksum of the
+ unaltered file, store that checksum offline, and periodically (or
+ when desired) check to make sure the checksum of the online file
+ hasn't changed (which would indicate the data has been modified).
+
+ Some operating systems come with checksumming programs, such as the
+ UNIX sum program. However, these may not provide the protection you
+ actually need. Files can be modified in such a way as to preserve
+ the result of the UNIX sum program! Therefore, we suggest that you
+ use a cryptographically strong program, such as the message digesting
+ program MD5 [ref], to produce the checksums you will be using to
+ assure integrity.
+
+ There are other applications when integrity will want to be assured,
+ such as when transmitting an email message between two parties. There
+ are products available that can provide this capability. The purpose
+ of this section is to acquaint you with this concept so that you can
+ apply it where needed. Once you identify that this is a capability
+ you need, you can go about identifying technologies that will provide
+ it.
+
+4.4 Authorization
+
+ Authorization refers to the process of granting privileges to
+
+
+
+Site Security Working Group [Page 23]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ processes and, ultimately, users. This differs from authentication
+ in that authentication is what occurs to identify a user. Once
+ identified (reliably), the privileges, rights, property, and
+ permissible actions of the user are determined by authorization.
+
+ Explicitly listing the authorized activities of each user (and user
+ process) with respect to all resources (objects) is impossible in a
+ reasonable system. In a real system certain techniques are used to
+ simplify the process of granting and checking authorization(s).
+
+ One approach, popularized in UNIX systems, is to assign to each
+ object three classes of user: owner, group and world. The owner is
+ either the creator of the object or the user assigned as owner by the
+ super-user. The owner permissions (read, write and execute) apply
+ only to the owner. A group is a collection of users which share
+ access rights to an object. The group permissions (read, write and
+ execute) apply to all users in the group (except the owner). The
+ world refers to everybody else with access to the system. The world
+ permissions (read, write and execute) apply to all users (except the
+ owner and members of the group).
+
+ Another approach is to attach to an object a list which explicitly
+ contains the identity of all permitted users (or groups). This is an
+ Access Control List. The advantage of these are that they are easily
+ maintained (one central list per object).
+
+4.5 Access
+
+4.5.1 Physical Access
+
+ Restrict physical access to areas containing hosts to people who are
+ supposed to use the hosts. Hosts include "trusted" terminals (such
+ as system consoles, operator terminals and terminals dedicated to
+ special tasks), and individual microcomputers and workstations,
+ especially those connected to your network. Make sure access
+ restrictions mesh well with people's work patterns; otherwise they
+ will find ways to circumvent your physical security (e.g., jamming
+ doors open).
+
+ Keep original and backup copies of data and programs safe. Apart
+ from keeping them in good condition for backup purposes, they must be
+ protected from theft.
+
+ Portable hosts are a particular risk. Make sure it won't cause
+ problems if one of your staff's portable computer is stolen.
+ Consider developing guidelines for the kinds of data that should be
+ allowed to reside on the disks of portable computers as well as how
+ the data should be protected (e.g., encryption) when it is on a
+ portable computer.
+
+ Other areas where physical access should be restricted is the wiring
+ closets and important network elements like file servers, name server
+ hosts, and routers.
+
+
+
+
+Site Security Working Group [Page 24]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+4.5.2 Walk-up Network Connections
+
+ By "walk-up" connections, we mean sockets located so as to provide a
+ convenient way for users to connect a portable host to your network.
+
+ Consider whether you need to provide this service, bearing in mind
+ that it allows any user to attach an unauthorized host to your
+ network. This increases the risk of attacks via techniques such as
+ IP address spoofing, packet sniffing, etc. Users and site management
+ must appreciate the risks involved. If you decide to provide walk-up
+ connections, plan the service carefully and define precisely where
+ you will provide it so that you can provide the necessary physical
+ access security.
+
+ A walk-up host should be authenticated before its user is permitted
+ to access resources on your network. As an alternative, it may be
+ possible to control physical access. For example, if the service is
+ to be used by students, you might only provide walk-up connection
+ sockets in student laboratories.
+
+ Keep an eye on empty offices. It may be sensible to disconnect
+ connections to unused offices at the wiring closet. Consider using
+ secure hubs and monitoring attempts to connect unauthorized hosts.
+
+4.5.3 Other Network Technologies
+
+ Technologies considered here include X.25, ISDN, SMDS, DDS and Frame
+ Relay. All are provided via physical links which go through
+ telephone exchanges, providing the potential for them to be diverted.
+ Crackers are certainly interested in telephone switches as well as in
+ data networks!
+
+ With switched technologies, use Permanent Virtual Circuits or Closed
+ User Groups whenever this is possible. Technologies which provide
+ authentication and/or encryption (such as IPv6) are evolving rapidly;
+ consider using them on links where security is important.
+
+4.5.4 Modems
+
+4.5.4.1 Modem lines must be managed
+
+ Although they provide convenient access to a site for its users, they
+ can also provide an effective detour around the site's firewalls.
+ For this reason it is essential to maintain proper control of modems.
+
+ Don't allow users to install a modem line without proper
+ authorization. This includes temporary installations (e.g., plugging
+ a modem into a facsimile or telephone line overnight).
+
+ Maintain a register of all your modem lines and keep your register up
+ to date. Conduct regular site checks for unauthorized modems.
+
+4.5.4.2 Dial-in users must be authenticated
+
+
+
+
+Site Security Working Group [Page 25]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ A username and password check should be completed before a user can
+ access anything on your network. Normal password security
+ considerations are particularly important (see section 4.1.1).
+
+ Remember that telephone lines can be tapped, and that it is quite
+ easy to intercept messages to cellular phones. Modern high-speed
+ modems use more sophisticated modulation techniques, which makes them
+ somewhat more difficult to monitor, but it is prudent to assume that
+ hackers know how to eavesdrop on your lines. For this reason, you
+ should use one-shot passwords if at all possible.
+
+ It is helpful to have a single dial-in point (e.g., a single large
+ modem pool) so that all users are authenticated in the same way.
+
+ Users will occasionally mis-type a password. Set a short delay - say
+ two seconds - after the first and second failed logins, and force a
+ disconnect after the third. This will slow down automated password
+ attacks. Don't tell the user whether the username, the password, or
+ both, were incorrect.
+
+4.5.4.3 All logins (successful and unsuccessful) should be logged
+
+ Don't keep correct passwords in the log, but consider keeping
+ incorrect passwords to aid in detecting password attacks. However,
+ most incorrect passwords are correct passwords with one character
+ mistyped and may suggest the real password. If you can't keep this
+ information secure, don't log it at all.
+
+ If Calling Line Identification is available, take advantage of it by
+ recording the calling number for each login attempt. Be sensitive to
+ the privacy issues raised by Calling Line Identification. Also be
+ aware that Calling Line Identification is not to be trusted; use the
+ data for informational purposes only, not for authentication.
+
+4.5.4.4 Minimize the amount of information given in your opening banner
+
+ In particular, don't announce the type of host hardware or operating
+ system - this encourages specialist hackers.
+
+ Display a short banner, but don't offer an "inviting" name (e.g.,
+ University of XYZ, Student Records System). Instead, give your site
+ name, a short warning that sessions may be monitored, and a
+ username/password prompt. Get your site's lawyers to check your
+ banner to make sure it states your legal position correctly.
+
+ For high-security applications, consider using a "blind" password
+ (i.e., give no response to an incoming call until the user has typed
+ in a password). This effectively simulates a dead modem.
+
+4.5.4.5 Call-back Capability
+
+ Some dial-in servers offer call-back facilities (i.e., the user dials
+ in and is authenticated, then the system disconnects the call and
+ calls back on a specified number). You will probably have to pay the
+
+
+
+Site Security Working Group [Page 26]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ charges for such calls.
+
+ This feature should be used with caution; it can easily be bypassed.
+ At a minimum, make sure that the return call is never made from the
+ same modem as the incoming one. Overall, although call-back can
+ improve modem security, you should not depend on it alone.
+
+4.5.4.6 Dial-out authentication
+
+ Dial-out users should also be authenticated, particularly since your
+ site will have to pay their telephone charges.
+
+ Never allow dial-out from an unauthenticated dial-in call, and
+ consider whether you will allow it from an authenticated one. The
+ goal here is to prevent callers using your modem pool as part of a
+ chain of logins. This can be hard to detect, particularly if a
+ hacker sets up a path through several hosts on your site.
+
+ At a minimum, don't allow the same modems and phone lines to be used
+ for both dial-in and dial-out. This can be implemented easily if you
+ run separate dial-in and dial-out modem pools.
+
+4.5.4.7 Make your modem programming as "bullet-proof" as possible
+
+ Be sure modems can't be reprogrammed while they're in service. At a
+ minimum, make sure that three plus signs won't put your dial-in
+ modems into command mode!
+
+ Program your modems to reset to your standard configuration at the
+ start of each new call. Failing this, make them reset at the end of
+ each call. This precaution will protect you against accidental
+ reprogramming of your modems.
+
+ Check that your modems terminate calls cleanly. When a user logs out
+ from an access server, verify that the server hangs up the phone line
+ properly. It is equally important that the server forces logouts
+ from whatever sessions were active if the user hangs up unexpectedly.
+
+4.6 Auditing
+
+ This section covers the procedures for collecting data generated by
+ network activity, which may be useful in analyzing the security of a
+ network and responding to security incidents.
+
+4.6.1 What to collect
+
+ Audit data should include any attempt to achieve a different security
+ level by any person, process, or other entity in the network. This
+ includes login and logout, su (or the non-UNIX equivalent), ticket
+ generation (for Kerberos, for example), and any other change of
+ access or status. It is especially important to note "anonymous" or
+ "guest" access to public servers.
+
+ The actual data to collect will differ for different sites and for
+
+
+
+Site Security Working Group [Page 27]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ different types of access changes within a site. In general, the
+ information you want to collect includes: username and hostname, for
+ login and logout; previous and new access rights, for a change of
+ access rights; and a timestamp. Of course, there is much more
+ information which might be gathered, depending on what the system
+ makes available and how much space is available to store that
+ information.
+
+ One very important note: do not gather passwords. This creates an
+ enormous potential security breach if the audit records should be
+ improperly accessed. Do not gather incorrect passwords either, as
+ they often differ from valid passwords by only a single character or
+ transposition.
+
+4.6.2 Collection Process
+
+ The collection process should be enacted by the host or resource
+ being accessed. Depending on the importance of the data and the need
+ to have it local in instances in which services are being denied,
+ data could be kept local to the resource until needed or be
+ transmitted to storage after each event.
+
+ There are basically three ways to store audit records: in a
+ read/write file on a host, on a write-once/read-many device (e.g., a
+ CD-ROM or a specially configured tape drive), or on a write-only
+ device (e.g., a line printer). Each method has advantages and
+ disadvantages.
+
+ File system logging is the least resource intensive of the three
+ methods and the easiest to configure. It allows instant access to
+ the records for analysis, which may be important if an attack is in
+ progress. File system logging is also the least reliable method. If
+ the logging host has been compromised, the file system is usually the
+ first thing to go; an intruder could easily cover up traces of the
+ intrusion.
+
+ Collecting audit data on a write-once device is slightly more effort
+ to configure than a simple file, but it has the significant advantage
+ of greatly increased security because an intruder could not alter the
+ data showing that an intrusion has occurred. The disadvantage of
+ this method is the need to maintain a supply of storage media and the
+ cost of that media. Also, the data may not be instantly available.
+
+ Line printer logging is useful in system where permanent and
+ immediate logs are required. A real time system is an example of
+ this, where the exact point of a failure or attack must be recorded.
+ A laser printer, or other device which buffers data (e.g., a print
+ server), may suffer from lost data if buffers contain the needed data
+ at a critical instant. The disadvantage of, literally, "paper
+ trails" is the need to keep the printer fed and the need to scan
+ records by hand. There is also the issue of where to store the,
+ potentially, enormous volume of paper which may be generated.
+
+ For each of the logging methods described, there is also the issue of
+
+
+
+Site Security Working Group [Page 28]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ securing the path between the device generating the log and actual
+ logging device (i.e., the file server, tape/CD-ROM drive, printer).
+ If that path is compromised, logging can be stopped or spoofed or
+ both. In an ideal world, the logging device would be directly
+ attached by a single, simple, point-to-point cable. Since that is
+ usually impractical, the path should pass through the minimum number
+ of networks and routers. Even if logs can be blocked, spoofing can
+ be prevented with cryptographic checksums (it probably isn't
+ necessary to encrypt the logs because they should not contain
+ sensitive information in the first place).
+
+4.6.3 Collection Load
+
+ Collecting audit data may result in a rapid accumulation of bytes so
+ storage availability for this information must be considered in
+ advance. There are a few ways to reduce the required storage space.
+ First, data can be compressed, using one of many methods. Or, the
+ required space can be minimized by keeping data for a shorter period
+ of time with only summaries of that data kept in long-term archives.
+ One major drawback to the latter method involves incident response.
+ Often, an incident has been ongoing for some period of time when a
+ site notices it and begins to investigate. At that point in time,
+ it's very helpful to have detailed audit logs available. If these are
+ just summaries, there may not be sufficient detail to fully handle
+ the incident.
+
+4.6.4 Handling and Preserving Audit Data
+
+ Audit data should be some of the most carefully secured data at the
+ site and in the backups. If an intruder were to gain access to audit
+ logs, the systems themselves, in addition to the data, would be at
+ risk.
+
+ Audit data may also become key to the investigation, apprehension,
+ and prosecution of the perpetrator of an incident. For this reason,
+ it is advisable to seek the advice of legal council when deciding how
+ audit data should be treated. This should happen before an incident
+ occurs.
+
+ If a data handling plan is not adequately defined prior to an
+ incident, it may mean that there is no recourse in the aftermath of
+ an event, and it may create liability resulting from improper
+ treatment of the data.
+
+4.6.5 Legal Considerations
+
+ Due to the content of audit data, there are a number of legal
+ questions that arise which need to be addressed by your legal
+ counsel. If you collect and save audit data, you need to be prepared
+ for consequences resulting both from its existence and its content.
+
+ One area concerns the privacy of individuals. In certain instances,
+ audit data may contain personal information. Searching through the
+ data, even for a routine check of the system's security, could
+
+
+
+Site Security Working Group [Page 29]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ represent an invasion of privacy.
+
+ A second area of concern involves knowledge of intrusive behavior
+ originating from your site. If an organization keeps audit data, is
+ it responsible for examining it to search for incidents? If a host
+ in one organization is used as a launching point for an attack
+ against another organization, can the second organization use the
+ audit data of the first organization to prove negligence on the part
+ of that organization?
+
+ The above examples are meant to be comprehensive, but should motivate
+ your organization to consider the legal issues involved with audit
+ data.
+
+4.7 Securing Backups
+
+ The procedure of creating backups is a classic part of operating a
+ computer system. Within the context of this document, backups are
+ addressed as part of the overall security plan of a site. There are
+ several aspects to backups that are important within this context:
+
+ (1) Make sure your site is creating backups
+ (2) Make sure your site is using offsite storage for backups. The
+ storage site should be carefully selected for both its security an=
+d
+ its availability.
+ (3) Consider encrypting your backups to provide additional protection =
+of
+ the information once it is off-site. However, be aware that you w=
+ill
+ need a good key management scheme so that you'll be able to recove=
+r
+ data at any point in the future. Also, make sure you will have
+ access to the necessary decryption programs at such time in the
+ future as you need to perform the decryption.
+ (4) Don't always assume that your backups are good. There have been
+ many instances of computer security incidents that have gone on fo=
+r
+ long periods of time before a site has noticed the incident. In s=
+uch
+ cases, backups of the affected systems are also tainted.
+ (5) Periodically check your backups.
+
+5. Security Incident Handling
+
+ This section of the document will supply guidance to be applied
+ before, during, and after a computer security incident occurs on a
+ machine, network, site, or multi-site environment. The operative
+ philosophy in the event of a breach of computer security is to react
+ according to a plan. This is true whether the breach is the result
+ of an external intruder attack, unintentional damage, a student
+ testing some new program to exploit a software vulnerability, or a
+ disgruntled employee. Each of the possible types of events, such as
+ those just listed, should be addressed in advance by adequate
+ contingency plans.
+
+ Traditional computer security, while quite important in the overall
+ site security plan, usually pays little attention to how to actually
+ handle the attack once it occurs. The result is that when an attack
+ is in progress, many decisions are made in haste and can be damaging
+
+
+
+Site Security Working Group [Page 30]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ to tracking down the source of the incident, collecting evidence to
+ be used in prosecution efforts, preparing for the recovery of the
+ system, and protecting the valuable data contained on the system.
+
+ One of the most important, but often overlooked, benefits for
+ efficient incident handling is an economic one. Having both
+ technical and managerial personnel respond to an incident requires
+ considerable resources. If trained to handle incidents efficiently,
+ less staff time is required when one occurs.
+
+ Due to the world-wide network most incidents are not restricted to a
+ single site. Operating systems vulnerabilities apply (in some cases)
+ to several millions of systems, and many vulnerabilities are
+ exploited within the network itself. Therefore, it is vital for all
+ sites with involved parties are informed as soon as possible.
+
+ Another benefit is related to public relations. News about computer
+ security incidents tends to be damaging to an organization's stature
+ among current or potential clients. Efficient incident handling
+ minimizes the potential for negative exposure.
+
+ A final benefit of efficient incident handling is related to legal
+ issues. It is possible that in the near future organizations may be
+ sued because one of their nodes was used to launch a network attack.
+ In a similar vein, people who develop patches or workarounds may be
+ sued if the patches or workarounds are ineffective, resulting in
+ compromise of the systems, or, if the patches or workarounds
+ themselves damage systems. Knowing about operating system
+ vulnerabilities and patterns of attacks, and then taking appropriate
+ measures to counter these potential threats, is critical to
+ circumventing possible legal problems.
+
+ The sections in this chapter provide an outline and starting point
+ for creating your site's policy for handling security incidents. The
+ sections are:
+
+ (1) Preparing and planning (what are the goals and objectives in
+ handling an incident).
+ (2) Notification (who should be contacted in the case of an incident).
+ (3) Evaluation (how serious is the incident).
+ (4) Handling (what should be done when an incident occurs).
+ - Notification (who should be notified about the incident).
+ - Containment (how can the damage be limited).
+ - Eradication (how to eliminate the reasons for the incident).
+ - Recovery (how to reestablish service and systems).
+ - Follow Up (what actions should be taken after the incident).
+ - Legal/Investigative implications (what are the legal and
+ prosecutorial implications of the incident).
+ - Documentation Logs (what records should be kept from
+ before, during, and after the incident).
+ (5) Aftermath (what are the implications of past incidents).
+ (6) Responsibilities (how to handle an incident responsibly).
+
+ The remainder of this chapter will detail the issues involved in each
+
+
+
+Site Security Working Group [Page 31]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ of the important topics listed above, and provide some guidance as to
+ what should be included in a site policy for handling incidents.
+
+5.1 Preparing and Planning for Incident Handling
+
+ Part of handling an incident is being prepared to respond to an
+ incident before the incident occurs in the first place. This
+ includes establishing a suitable level of protections as explained in
+ the preceding chapters. Doing this should help your site prevent
+ incidents as well as limit potential damage resulting from them when
+ they do occur. Protection also includes preparing incident handling
+ guidelines as part of a contingency plan for your organization or
+ site. Having written plans eliminates much of the ambiguity which
+ occurs during an incident, and will lead to a more appropriate and
+ thorough set of responses. It is vitally important to test the
+ proposed plan before an incident occurs through "dry runs". A team
+ might even consider hiring a tiger team to act in parallel with the
+ dry run.
+
+ Learning to respond efficiently to an incident is important for a
+ number of reasons:
+
+ (1) protecting the assets which could be compromised
+ (2) protecting resources which could be utilized more
+ profitably if an incident did not require their services
+ (3) complying with (government or other) regulations
+ (4) preventing the use of your systems in attacks against other
+ systems (which could cause you to incur legal liability)
+ (5) minimizing the potential for negative exposure
+
+ As in any set of pre-planned procedures, attention must be paid to a
+ set of goals for handling an incident. These goals will be
+ prioritized differently depending on the site. A specific set of
+ objectives can be identified for dealing with incidents:
+
+ (1) Figure out how it happened.
+ (2) Find out how to avoid further exploitation of the same
+ vulnerability.
+ (3) Avoid escalation and further incidents.
+ (4) Recover from the incident.
+ (5) Find out who did it.
+
+ Due to the nature of the incident, there might be a conflict between
+ analyzing the original source of a problem and restoring systems and
+ services. Overall goals (like assuring the integrity of critical
+ systems) might be the reason for not analyzing an incident. Of
+ course, this is an important management decision; but all involved
+ parties must be aware that without analysis the same incident may
+ happen again.
+
+ It is also important to prioritize the actions to be taken during an
+ incident well in advance of the time an incident occurs. Sometimes
+ an incident may be so complex that it is impossible to do everything
+ at once to respond to it; priorities are essential. Although
+
+
+
+Site Security Working Group [Page 32]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ priorities will vary from institution to institution, the following
+ suggested priorities may serve as a starting point for defining your
+ organization's response:
+
+ (1) Priority one -- protect human life and people's
+ safety; human life always has precedence over all
+ other considerations.
+
+ (2) Priority two -- protect classified and/or sensitive
+ data. Prevent exploitation of classified and/or
+ sensitive systems, networks or sites. Inform affected
+ classified and/or sensitive systems, networks or sites
+ about already occurred penetrations.
+ (Be aware of regulations by your site or by government)
+
+ (3) Priority three -- protect other data, including
+ proprietary, scientific, managerial and other data,
+ because loss of data is costly in terms of resources.
+ Prevent exploitations of other systems, networks or
+ sites and inform already affected systems, networks or
+ sites about successful penetrations.
+
+ (4) Priority four -- prevent damage to systems (e.g., loss
+ or alteration of system files, damage to disk drives,
+ etc.). Damage to systems can result in costly down
+ time and recovery.
+
+ (5) Priority five -- minimize disruption of computing
+ resources. It is better in many cases to shut a system
+ down or disconnect from a network than to risk damage
+ to data or systems.
+
+ An important implication for defining priorities is that once human
+ life and national security considerations have been addressed, it is
+ generally more important to save data than system software and
+ hardware. Although it is undesirable to have any damage or loss
+ during an incident, systems can be replaced. However, the loss or
+ compromise of data (especially classified or proprietary data) is
+ usually not an acceptable outcome under any circumstances.
+
+ Another important concern is the effect on others, beyond the systems
+ and networks where the incident occurs. Within the limits imposed by
+ government regulations it is always important to inform affected
+ parties as soon as possible. Due to the legal implications of this
+ topic, it should be included in the planned procedures to avoid
+ further delays and uncertainties for the administrators.
+
+ Any plan for responding to security incidents should be guided by
+ local policies and regulations. Government and private sites that
+ deal with classified material have specific rules that they must
+ follow.
+
+ The policies chosen by your site on how it reacts to incidents will
+ shape your response. For example, it may make little sense to create
+
+
+
+Site Security Working Group [Page 33]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ mechanisms to monitor and trace intruders if your site does not plan
+ to take action against the intruders if they are caught. Other
+ organizations may have policies that affect your plans. Telephone
+ companies often release information about telephone traces only to
+ law enforcement agencies.
+
+5.2 Notification and Points of Contact
+
+ It is important to establish contacts with various personnel before a
+ real incident occurs. These contacts are either local, other system
+ responsible or administrative contacts administrators elsewhere on
+ the Internet or are investigative agencies. Working with these
+ contacts appropriately will help to make your incident handling
+ process more efficient.
+
+ Communication may need to be established with various "Points of
+ Contact" (POC). These may be technical or administrative in nature
+ and may include legal or investigative agencies as well as Service
+ Providers and vendors. It is important to decide how much
+ information will be shared, especially with the wider community of
+ users at a site, with the public (the press) and with other sites.
+
+ Settling these issues are especially important for the local person
+ responsible for handling the incident, since that is the person
+ responsible for the actual notification of others. A list of
+ contacts in each of these categories is an important time saver for
+ this person during an incident. It can be quite difficult to find an
+ appropriate person during an incident when many urgent events are
+ ongoing. Including relevant telephone numbers (also electronic mail
+ addresses and fax numbers) in the site security policy is strongly
+ recommended. It is especially important to know how to contact
+ individuals who will be directly involved in handling a security
+ incident.
+
+5.2.1 Local Managers and Personnel
+
+ When an incident is under way, a major issue is deciding who is in
+ charge of coordinating the activity of the multitude of players. A
+ major mistake that can be made is to have a number of POCs who are
+ not pulling their efforts together. This will only add to the
+ confusion of the event and will probably lead to wasted or
+ ineffective effort.
+
+ The single POC may or may not be the person responsible for handling
+ the incident. There are two distinct roles to fill when deciding who
+ shall be the POC and who will be the person in charge of the
+ incident. The person in charge of the incident will make decisions
+ as to the interpretation of policy applied to the event. In
+ contrast, the POC must coordinate the effort of all the parties
+ involved with handling the event.
+
+ The POC must be a person with the technical expertise to successfully
+ coordinate the effort of the system managers and users involved in
+ monitoring and reacting to the attack. Often the management
+
+
+
+Site Security Working Group [Page 34]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ structure of a site is such that the administrator of a set of
+ resources is not a technically competent person with regard to
+ handling the details of the operations of the computers, but is
+ ultimately responsible for the use of these resources.
+
+ Another important function of the POC is to maintain contact with law
+ enforcement and other external agencies to assure that multi-agency
+ involvement occurs. The level of involvement will be determined by
+ management decisions as well as legal constraints.
+
+ Finally, if legal action in the form of prosecution is involved, the
+ POC may be asked to speak for the site in court. The alternative is
+ to have multiple witnesses whose input may be hard to coordinate in a
+ legal sense. This may lead to a weakening of any case against the
+ attackers. A single POC may also be the single person in charge of
+ collecting evidence, which will keep the number of people accounting
+ for evidence to a minimum. As a rule of thumb, the more people that
+ touch a potential piece of evidence, the greater the possibility that
+ it will be inadmissible in court.
+
+ One of the most critical tasks for the POC is the coordination of all
+ relevant processes. As responsibilities might be distributed over
+ the whole site, which may well consist of multiple independent
+ departments or groups, a well coordinate effort is crucial for
+ overall success. The situation get even worse if multiple sites are
+ involved. In many cases, no single POC in one site can coordinate
+ the handling of an entire incident. The appropriate incident
+ response teams are more suitable, if multiple sites are involved.
+
+ The incident handling process should provide some escalation
+ mechanisms. The POC might change; the impact of the incident force
+ the management to take the lead instead of giving the technical
+ administrator the responsibility. Other reasons for changing the POC
+ are the emergence of conflicts of interest, or changing priorities or
+ responsibilities. Regardless of why the POC is changed, all involved
+ parties must be informed. Arrangements should be made to allow the
+ new POC to contact the old one, to ensure an adequate briefing of
+ background information.
+
+5.2.2 Law Enforcement and Investigative Agencies
+
+ In the event of an incident that has legal consequences, it is
+ important to establish contact with investigative agencies (e.g, the
+ FBI and Secret Service in the U.S.) as soon as possible. Local law
+ enforcement, local security offices, and campus police departments
+ should also be informed as appropriate.
+
+ A primary reason is that once a major attack is in progress, there is
+ little time to call these agencies to determine exactly who the
+ correct point of contact is. Another reason is that it is important
+ to cooperate with these agencies in a manner that will foster a good
+ working relationship, and that will be in accordance with the working
+ procedures of these agencies. Knowing the working procedures in
+ advance and the expectations of your point of contact is a big step
+
+
+
+Site Security Working Group [Page 35]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ in this direction. For example, it is important to gather evidence
+ that will be admissible in a court of law, requiring prior knowledge
+ of how to gather such evidence. A final reason for establishing
+ contacts as soon as possible is that it is impossible to know the
+ particular agency that will assume jurisdiction in any given
+ incident. Making contacts and finding the proper channels early will
+ make responding to an incident go considerably more smoothly.
+
+ If your organization or site has a legal counsel, you need to notify
+ this office soon after you learn that an incident is in progress. At
+ a minimum, your legal counsel needs to be involved to protect the
+ legal and financial interests of your site or organization. There
+ are many legal and practical issues, a few of which are:
+
+ (1) Whether your site or organization is willing to risk negative
+ publicity or exposure to cooperate with legal prosecution efforts.
+
+ (2) Downstream liability--if you leave a compromised system as is so
+ it can be monitored and another computer is damaged because the
+ attack originated from your system, your site or organization
+ may be liable for damages incurred.
+
+ (3) Distribution of information--if your site or organization distribu=
+tes
+ information about an attack in which another site or organization =
+may
+ be involved or the vulnerability in a product that may affect abil=
+ity
+ to market that product, your site or organization may again be lia=
+ble
+ for any damages (including damage of reputation).
+
+ (4) Liabilities due to monitoring--your site or organization may be su=
+ed
+ if users at your site or elsewhere discover that your site is
+ monitoring account activity without informing users.
+
+ Unfortunately, there are no clear precedents yet on the liabilities
+ or responsibilities of organizations involved in a security incident
+ or who might be involved in supporting an investigative effort.
+ Investigators will often encourage organizations to help trace and
+ monitor intruders. Indeed, most investigators cannot pursue computer
+ intrusions without extensive support from the organizations involved.
+ However, investigators cannot provide protection from liability
+ claims, and these kinds of efforts may drag out for months and may
+ take a lot of effort.
+
+ On the other hand, an organization's legal council may advise extreme
+ caution and suggest that tracing activities be halted and an intruder
+ shut out of the system. This, in itself, may not provide protection
+ from liability, and may prevent investigators from identifying the
+ perpetrator.
+
+ The balance between supporting investigative activity and limiting
+ liability is tricky. You'll need to consider the advice of your legal
+ counsel and the damage the intruder is causing (if any) when making
+ your decision about what to do during any particular incident.
+
+ Your legal counsel should also be involved in any decision to contact
+
+
+
+Site Security Working Group [Page 36]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ investigative agencies when an incident occurs at your site. The
+ decision to coordinate efforts with investigative agencies is most
+ properly that of your site or organization. Involving your legal
+ counsel will also foster the multi-level coordination between your
+ site and the particular investigative agency involved, which in turn
+ results in an efficient division of labor. Another result is that
+ you are likely to obtain guidance that will help you avoid future
+ legal mistakes.
+
+ Finally, your legal counsel should evaluate your site's written
+ procedures for responding to incidents. It is essential to obtain a
+ "clean bill of health" from a legal perspective before you actually
+ carry out these procedures.
+
+ It is vital, when dealing with investigative agencies, to verify that
+ the person who calls asking for information is a legitimate
+ representative from the agency in question. Unfortunately, many well
+ intentioned people have unknowingly leaked sensitive details about
+ incidents, allowed unauthorized people into their systems, etc.,
+ because a caller has masqueraded as a representative of a government
+ agency.
+
+ A similar consideration is using a secure means of communication.
+ Because many network attackers can easily re-route electronic mail,
+ avoid using electronic mail to communicate with other agencies (as
+ well as others dealing with the incident at hand). Non-secured phone
+ lines (the phones normally used in the business world) are also
+ frequent targets for tapping by network intruders, so be careful!
+
+ There is no established set of rules for responding to an incident
+ when the local government becomes involved. Normally, except by
+ court order, no agency can force you to monitor, to disconnect from
+ the network, to avoid telephone contact with the suspected attackers,
+ etc. As discussed before, you should consult the matter with your
+ legal counsel, especially before taking an action that your
+ organization has never taken.
+
+ The particular agency involved may ask you to leave an attacked
+ machine on and to monitor activity. Complying with this request will
+ ensure continued cooperation of the agency. This is usually the best
+ route towards finding the source of the network attacks and,
+ ultimately, terminating the attacks. Additionally, you may need
+ information or a favor from the agency involved. You are likely to
+ get what you need only if you have been cooperative. It is
+ particularly important to avoid unnecessary or unauthorized
+ disclosure of information about the incident, including any
+ information furnished by the agency involved. In other words, don't
+ compromise the case the agency is trying to build. And remember, if
+ you do not cooperate with an agency, you will be less likely to
+ receive help from that agency in the future.
+
+ Sometimes your needs and the needs of an investigative agency will
+ differ. Your site may want to get back to normal business by closing
+ an attack route, but the investigative agency may want you to keep
+
+
+
+Site Security Working Group [Page 37]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ this route open. Similarly, your site may want to close a
+ compromised system down to avoid the possibility of negative
+ publicity, but again the investigative agency may want you to
+ continue monitoring. When there is such a conflict, there may be a
+ complex set of tradeoffs (e.g., interests of your site's management,
+ amount of resources you can devote to the problem, jurisdictional
+ boundaries, etc.). An important guiding principle is related to what
+ might be called "Internet citizenship" and its responsibilities. See
+ section 5.6.
+
+5.2.3 Computer Security Incident Handling Teams
+
+ There now exists a number of Computer Security Incident Response
+ teams (CSIRTs) such as the CERT Coordination Center and the CIAC or
+ other teams around the globe. Teams exist for many major government
+ agencies and large corporations. If such a team is available,
+ notifying it should be of primary importance during the early stages
+ of an incident. These teams are responsible for coordinating
+ computer security incidents over a range of sites and larger
+ entities. Even if the incident is believed to be contained within a
+ single site, it is possible that the information available through a
+ response team could help in closing out the incident.
+
+ If it is determined that the breach occurred due to a flaw in the
+ system's hardware or software, the vendor (or supplier) and a
+ Computer Security Incident Handling team should be notified as soon
+ as possible. This is especially important because many other systems
+ are vulnerable, too.
+
+ In setting up a site policy for incident handling, it may be
+ desirable to create a subgroup, much like those teams that already
+ exist, that will be responsible for handling computer security
+ incidents for the site (or organization). If such a team is created,
+ it is essential that communication lines be opened between this team
+ and other teams. Once an incident is under way, it is difficult to
+ open a trusted dialogue between other teams if none has existed
+ before.
+
+5.2.4 Affected and Involved Sites
+
+ If an incident has an impact on other sites, it is good practice to
+ inform them. It may be obvious from the beginning that the incident
+ is not limited to the local site, or it may emerge only after further
+ analysis.
+
+ Each site might choose to contact other sites directly or they can
+ pass the information to an appropriate incident response team, to
+ which the involved site belongs. As it is often very difficult to
+ find the responsible POC at remote sites, the involvement of an
+ incident response team will facilitate contact by making use of
+ already established channels.
+
+ The legal and liability issues arising from a security incident may
+ differ from site to site. It is important to define a policy for the
+
+
+
+Site Security Working Group [Page 38]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ sharing and logging of information about other sites before an
+ incident occurs. This policy should be crafted in consultation with
+ legal counsel.
+
+ Information about specific people is especially sensitive, and may be
+ subject to privacy laws. To avoid problems in this area, irrelevant
+ information should be deleted and a statement of how to handle the
+ remaining information should be included. A clear statement of how
+ this information is to be used is essential. No one who informs a
+ site of a security incident wants to read about it in the public
+ press. Incident response teams are valuable in this respect. When
+ they pass information to responsible POCs, they are able to protect
+ the anonymity of the original source. But, be aware that, in many
+ cases, the analysis of logs and information at other sites will
+ reveal addresses of your site.
+
+ All the problems discussed above should be not taken as reasons not
+ to involve other sites. In fact, the experiences of existing teams
+ reveal that most sites informed about security problems are not even
+ aware that their site had been compromised. Without timely
+ information, other sites are often unable to take action against
+ intruders.
+
+5.2.5 Public Relations - Press Releases
+
+ One of the most important issues to consider is when, who, and how
+ much to release to the general public through the press. There are
+ many issues to consider when deciding this particular issue. First
+ and foremost, if a public relations office exists for the site, it is
+ important to use this office as liaison to the press. The public
+ relations office is trained in the type and wording of information
+ released, and will help to assure that the image of the site is
+ protected during and after the incident (if possible). A public
+ relations office has the advantage that you can communicate candidly
+ with them, and provide a buffer between the constant press attention
+ and the need of the POC to maintain control over the incident.
+
+ If a public relations office is not available, the information
+ released to the press must be carefully considered. If the
+ information is sensitive, it may be advantageous to provide only
+ minimal or overview information to the press. It is quite possible
+ that any information provided to the press will be quickly reviewed
+ by the perpetrator of the incident. Also note that misleading the
+ press can often backfire and cause more damage than releasing
+ sensitive information.
+
+ While it is difficult to determine in advance what level of detail to
+ provide to the press, some guidelines to keep in mind are:
+
+ (1) Keep the technical level of detail low. Detailed
+ information about the incident may provide enough
+ information for copy-cat events or even damage the
+ site's ability to prosecute once the event is over.
+
+
+
+
+Site Security Working Group [Page 39]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ (2) Keep the speculation out of press statements.
+ Speculation of who is causing the incident or the
+ motives are very likely to be in error and may cause
+ an inflamed view of the incident.
+
+ (3) Work with law enforcement professionals to assure that
+ evidence is protected. If prosecution is involved,
+ assure that the evidence collected is not divulged to
+ the press.
+
+ (4) Try not to be forced into a press interview before you are
+ prepared. The popular press is famous for the "2 am"
+ interview, where the hope is to catch the interviewee off
+ guard and obtain information otherwise not available.
+
+ (5) Do not allow the press attention to detract from the
+ handling of the event. Always remember that the successful
+ closure of an incident is of primary importance.
+
+5.3 Identifying an Incident
+
+5.3.1 Is it real?
+
+ This stage involves determining if a problem really exists. Of
+ course many if not most signs often associated with virus infection,
+ system intrusions, malicious users, etc., are simply anomalies such
+ as hardware failures or suspicious system/user behavior. To assist
+ in identifying whether there really is an incident, it is usually
+ helpful to obtain and use any detection software which may be
+ available. Audit information is also extremely useful, especially in
+ determining whether there is a network attack. It is extremely
+ important to obtain a system snapshot as soon as one suspects that
+ something is wrong. Many incidents cause a dynamic chain of events
+ to occur, and an initial system snapshot may be the most valuable
+ tool for identifying the problem and any source of attack. Finally,
+ it is important to start a log book. Recording system events,
+ telephone conversations, time stamps, etc., can lead to a more rapid
+ and systematic identification of the problem, and is the basis for
+ subsequent stages of incident handling.
+
+ There are certain indications or "symptoms" of an incident which
+ deserve special attention:
+
+ (1) System crashes.
+ (2) New user accounts (the account RUMPLESTILTSKIN has been
+ unexpectedly created), or high activity on a previously
+ low usage account.
+ (3) New files (usually with novel or strange file names,
+ such as data.xx or k or .xx ).
+ (4) Accounting discrepancies (in a UNIX system you might
+ notice the shrinking of an accounting file called
+ /usr/admin/lastlog, something that should make you very
+ suspicious that there may be an intruder).
+ (5) Changes in file lengths or dates (a user should be
+
+
+
+Site Security Working Group [Page 40]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ suspicious if .EXE files in an MS DOS computer have
+ unexplainedly grown by over 1800 bytes).
+ (6) Attempts to write to system (a system manager notices
+ that a privileged user in a VMS system is attempting to
+ alter RIGHTSLIST.DAT).
+ (7) Data modification or deletion (files start to disappear).
+ (8) Denial of service (a system manager and all other users
+ become locked out of a UNIX system, now in single user mode).
+ (9) Unexplained, poor system performance
+ (10) Anomalies ("GOTCHA" is displayed on the console or there
+ are frequent unexplained "beeps").
+ (11) Suspicious probes (there are numerous unsuccessful login
+ attempts from another node).
+ (12) Suspicious browsing (someone becomes a root user on a UNIX
+ system and accesses file after file on many user accounts.)
+
+ By no means is this list comprehensive; we have just listed a number
+ of common indicators. It is best to collaborate with other technical
+ and computer security personnel to make a decision as a group about
+ whether an incident is occurring.
+
+5.3.2 Types and Scope of Incidents
+
+ Along with the identification of the incident is the evaluation of
+ the scope and impact of the problem. It is important to correctly
+ identify the boundaries of the incident in order to effectively deal
+ with it and prioritize responses.
+
+ In order to identify the scope and impact a set of criteria should be
+ defined which is appropriate to the site and to the type of
+ connections available. Some of the issues include:
+
+ (1) Is this a multi-site incident?
+ (2) Are many computers at your site affected by this incident?
+ (3) Is sensitive information involved?
+ (4) What is the entry point of the incident (network,
+ phone line, local terminal, etc.)?
+ (5) Is the press involved?
+ (6) What is the potential damage of the incident?
+ (7) What is the estimated time to close out the incident?
+ (8) What resources could be required to handle the incident?
+ (9) Is law enforcement involved?
+
+5.3.3 Assessing the Damage and Extent
+
+ The analysis of the damage and extent of the incident can be quite
+ time consuming, but should lead to some insight into the nature of
+ the incident, and aid investigation and prosecution. As soon as the
+ breach has occurred, the entire system and all of its components
+ should be considered suspect. System software is the most probable
+ target. Preparation is key to be able to detect all changes for a
+ possibly tainted system. This includes checksumming all tapes from
+ the vendor using a algorithm which is resistant to tampering. (See
+ sections 4.3)
+
+
+
+Site Security Working Group [Page 41]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Assuming original vendor distribution tapes are available, an
+ analysis of all system files should commence, and any irregularities
+ should be noted and referred to all parties involved in handling the
+ incident. It can be very difficult, in some cases, to decide which
+ backup tapes are showing a correct system status. Consider, for
+ example, that the incident may have continued for months or years
+ before discovery, and the suspect may be an employee of the site, or
+ otherwise have intimate knowledge or access to the systems. In all
+ cases, the pre-incident preparation will determine what recovery is
+ possible.
+
+ If the system supports centralized logging (most do), go back over
+ the logs and look for abnormalities. If process accounting and
+ connect time accounting is enabled, look for patterns of system
+ usage. To a lesser extent, disk usage may shed light on the
+ incident. Accounting can provide much helpful information in an
+ analysis of an incident and subsequent prosecution. Your ability to
+ address all aspects of a specific incident strongly depends on the
+ success of this analysis.
+
+5.4 Handling an Incident
+
+ Certain steps are necessary to take during the handling of an
+ incident. In all security related activities, the most important
+ point to be made is: One should have policies in place. Without
+ defined goals, activities undertaken will remain without focus. The
+ goals should be defined by management and legal counsel in advance.
+
+ One of the most fundamental objectives is to restore control of the
+ affected systems and to limit the impact and damage. In the worst
+ case scenario, shutting down the system, or disconnecting the system
+ from the network, may the only practical solution.
+
+ As the activities involved are complex, try to get as much help as
+ necessary. While trying to solve the problem alone, real damage
+ might occur due to delays or missing information. Most system
+ administrators take the discovery of an intruder as personal
+ challenge. By proceeding this way, other objectives as outlined in
+ the local policies may not always be considered. Trying to catch
+ intruders may be a very low priority, compared to system integrity,
+ for example. Monitoring a hacker's activity is useful, but it might
+ not be considered worth the risk to allow continued access.
+
+5.4.1 Types of notification, Exchange of information
+
+ When you have confirmed that an incident is occurring, the
+ appropriate personnel must be notified. How this notification is
+ achieved is very important to keeping the event under control both
+ from a technical and emotional standpoint. The circumstances should
+ be described in as much detail as possible, in order to aid prompt
+ acknowledgment and understanding of the problem. Great care should
+ be taken when determining to which groups detailed technical
+ information is given during the notification. For example, it is
+ helpful to pass this kind of information to an incident handling team
+
+
+
+Site Security Working Group [Page 42]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ as they can assist you by providing helpful hints for eradicating the
+ vulnerabilities involved in an incident. On the other hand, putting
+ the critical knowledge into the public domain (e.g., via USENET
+ newsgroups or mailing lists) may potentially put a large number of
+ systems at risk of intrusion. It is invalid to assume that all
+ administrators reading a particular newsgroup have access to
+ operating system source code, or can even understand an advisory well
+ enough to take adequate steps.
+
+ First of all, any notification to either local or off-site personnel
+ must be explicit. This requires that any statement (be it an
+ electronic mail message, phone call, or fax) providing information
+ about the incident be clear, concise, and fully qualified. When you
+ are notifying others that will help you handle an event, a "smoke
+ screen" will only divide the effort and create confusion. If a
+ division of labor is suggested, it is helpful to provide information
+ to each participant about what is being accomplished in other
+ efforts. This will not only reduce duplication of effort, but allow
+ people working on parts of the problem to know where to obtain
+ information relevant to their part of the incident.
+
+ Another important consideration when communicating about the incident
+ is to be factual. Attempting to hide aspects of the incident by
+ providing false or incomplete information may not only prevent a
+ successful resolution to the incident, but may even worsen the
+ situation.
+
+ The choice of language used when notifying people about the incident
+ can have a profound effect on the way that information is received.
+ When you use emotional or inflammatory terms, you raise the potential
+ for damage and negative outcomes of the incident. It is important to
+ remain calm both in written and spoken communications.
+
+ Another consideration is that not all people speak the same language.
+ Due to this fact, misunderstandings and delay may arise, especially
+ if it is a multi-national incident. Other international concerns
+ include differing legal implications of a security incident and
+ cultural differences. However, cultural differences do not only
+ exist between countries. They even exist within countries, between
+ different social or user groups. For example, an administrator of a
+ university system might be very relaxed about attempts to connect to
+ the system via telnet, but the administrator of a military system is
+ likely to consider the same action as a possible attack.
+
+ Another issue associated with the choice of language is the
+ notification of non-technical or off-site personnel. It is important
+ to accurately describe the incident without generating undue alarm or
+ confusion. While it is more difficult to describe the incident to a
+ non-technical audience, it is often more important. A non-technical
+ description may be required for upper-level management, the press, or
+ law enforcement liaisons. The importance of these communications
+ cannot be underestimated and may make the difference between
+ resolving the incident properly and escalating to some higher level
+ of damage.
+
+
+
+Site Security Working Group [Page 43]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ If an incident response team becomes involved, it might be necessary
+ to fill out a template for the information exchange. Although this
+ may seem to be an additional burden and adds a certain delay, it
+ helps the team to act on this minimum set of information. The
+ response team may be able to respond to aspects of the incident of
+ which the local administrator is unaware. If information is given out
+ to someone else, the following minimum information should be
+ provided:
+
+ (1) timezone of logs, ... in GMT or local time
+ (2) information about the remote system, including host names,
+ IP addresses and (perhaps) user IDs
+ (3) all log entries relevant for the remote site
+ (4) type of incident (what happened, why should you care)
+
+ If local information (i.e., local user IDs) is included in the log
+ entries, it might be necessary to sanitize the entries beforehand to
+ avoid privacy issues. In general, all information which might assist
+ a remote site in resolving an incident should be given out, unless
+ local policies prohibit this.
+
+5.4.2 Protecting Evidence and Activity Logs
+
+ When you respond to an incident, document all details related to the
+ incident. This will provide valuable information to yourself and
+ others as you try to unravel the course of events. Documenting all
+ details will ultimately save you time. If you don't document every
+ relevant phone call, for example, you are likely to forget a
+ significant portion of information you obtain, requiring you to
+ contact the source of information again. At the same time, recording
+ details will provide evidence for prosecution efforts, providing the
+ case moves in that direction. Documenting an incident will also help
+ you perform a final assessment of damage (something your management,
+ as well as law enforcement officers, will want to know), and will
+ provide the basis for later phases of the handling process:
+ eradication, recovery, and follow-up "lessons learned."
+
+ During the initial stages of an incident, it is often infeasible to
+ determine whether prosecution is viable, so you should document as if
+ you are gathering evidence for a court case. At a minimum, you
+ should record:
+
+ (1) all system events (audit records)
+ (2) all actions you take (time tagged)
+ (3) all phone conversations (including the person with whom
+ you talked, the date and time, and the content of the
+ conversation)
+
+ The most straightforward way to maintain documentation is keeping a
+ log book. This allows you to go to a centralized, chronological
+ source of information when you need it, instead of requiring you to
+ page through individual sheets of paper. Much of this information is
+ potential evidence in a court of law. Thus, when you initially
+ suspect that an incident will result in prosecution or when an
+
+
+
+Site Security Working Group [Page 44]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ investigative agency becomes involved, you need to:
+
+ (1) Regularly (e.g., every day) turn in photocopied, signed
+ copies of your logbook (as well as media you use to record
+ system events) to a document custodian.
+ (2) The custodian should store these copied pages in a secure
+ place (e.g., a safe).
+ (3) When you submit information for storage, you should
+ receive a signed, dated receipt from the document
+ custodian.
+
+ Failure to observe these procedures can result in invalidation of any
+ evidence you obtain in a court of law.
+
+5.4.3 Containment
+
+ The purpose of containment is to limit the extent of an attack. An
+ essential part of containment is decision making (e.g., determining
+ whether to shut a system down, disconnect from a network, monitor
+ system or network activity, set traps, disable functions such as
+ remote file transfer, etc.).
+
+ Sometimes this decision is trivial; shut the system down if the
+ information is classified, sensitive, or proprietary. Bear in mind
+ that removing all access while an incident is in progress obviously
+ notifies all users, including the alleged problem users, that the
+ administrators are aware of a problem; this may have a deleterious
+ effect on an investigation. In some cases, it is prudent to remove
+ all access or functionality as soon as possible, then restore normal
+ operation in limited stages. In other cases, it is worthwhile to
+ risk some damage to the system if keeping the system up might enable
+ you to identify an intruder.
+
+ This stage should involve carrying out predetermined procedures.
+ Your organization or site should, for example, define acceptable
+ risks in dealing with an incident, and should prescribe specific
+ actions and strategies accordingly. This is especially important
+ when a quick decision is necessary and it is not possible to first
+ contact all involved parties to discuss the decision. In the absence
+ of predefined procedures, the person in charge of the incident will
+ often not have the power to make difficult management decisions (like
+ to lose the results of a costly experiment by shutting down a
+ system). A final activity that should occur during this stage of
+ incident handling is the notification of appropriate authorities.
+
+5.4.4 Eradication
+
+ Once the incident has been contained, it is time to eradicate the
+ cause. But before eradicating the cause, great care should be taken
+ to collect all necessary information about the compromised system(s)
+ and the cause of the incident as they will likely be lost when
+ cleaning up the system.
+
+ Software may be available to help you in the eradication process,
+
+
+
+Site Security Working Group [Page 45]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ such as anti-virus software for small systems. If any bogus files
+ have been created archive them before deleting them. In the case of
+ virus infections, it is important to clean and reformat any disks
+ containing infected files. Finally, ensure that all backups are
+ clean. Many systems infected with viruses become periodically re-
+ infected simply because people do not systematically eradicate the
+ virus from backups. After eradication, a new backup should be taken.
+
+ Removing all vulnerabilities once an incident has occurred is
+ difficult. The key to removing vulnerabilities is knowledge and
+ understanding of the breach.
+
+ It may be necessary to go back to the original distribution tapes and
+ re-customize the system. To facilitate this worst case scenario, a
+ record of the original system setup and each customization change
+ should be maintained. In the case of a network-based attack, it is
+ important to install patches for each operating system vulnerability
+ which was exploited.
+
+ As discussed in section 5.4.2, a security log can be most valuable
+ during this phase of removing vulnerabilities. The logs showing how
+ the incident was discovered and contained can be used later to help
+ determine how extensive the damage was from a given incident. The
+ steps taken can be used in the future to make sure the problem does
+ not resurface. Ideally, one should automate and regularly apply the
+ same test as was used to detect the security incident.
+
+ If a particular vulnerability is isolated as having been exploited,
+ the next step is to find a mechanism to protect your system. The
+ security mailing lists and bulletins would be a good place to search
+ for this information, and you can get advice from incident response
+ teams.
+
+5.4.5 Recovery
+
+ Once the cause of an incident has been eradicated, the recovery phase
+ defines the next stage of action. The goal of recovery is to return
+ the system to normal. In general, bringing up services in the order
+ of demand to allow a minimum of user inconvenience is the best
+ practice. Understand that the proper recovery procedures for the
+ system are extremely important and should be specific to the site.
+
+5.4.6 Follow-Up
+
+ Once you believe that a system has been restored to a "safe" state,
+ it is still possible that holes, and even traps, could be lurking in
+ the system. One of the most important stages of responding to
+ incidents is also the most often omitted, the follow-up stage. In
+ the follow-up stage, the system should be monitored for items that
+ may have been missed during the cleanup stage. It would be prudent
+ to utilize some of the tools mentioned in section xxx (e.g., xxx) as
+ a start. Remember, these tools don't replace continual system
+ monitoring and good systems administration practices.
+
+
+
+
+Site Security Working Group [Page 46]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ The most important element of the follow-up stage is performing a
+ postmortem analysis. Exactly what happened, and at what times? How
+ well did the staff involved with the incident perform? What kind of
+ information did the staff need quickly, and how could they have
+ gotten that information as soon as possible? What would the staff do
+ differently next time?
+
+ After an incident, it is prudent to write a report describing the
+ exact sequence of events: the method of discovery, correction
+ procedure, monitoring procedure, and a summary of lesson learned.
+ This will aid in the clear understanding of the problem. Creating a
+ formal chronology of events (including time stamps) is also important
+ for legal reasons.
+
+ A follow-up report is valuable for many reasons. It provides a
+ reference to be used in case of other similar incidents. It is also
+ important to, as quickly as possible obtain a monetary estimate of
+ the amount of damage the incident caused. This estimate should
+ include costs associated with any loss of software and files
+ (especially the value of proprietary data that may have been
+ disclosed), hardware damage, and manpower costs to restore altered
+ files, reconfigure affected systems, and so forth. This estimate may
+ become the basis for subsequent prosecution activity. The report can
+ also help justify an organization's computer security effort to
+ management.
+
+5.5 Aftermath of an Incident
+
+ In the wake of an incident, several actions should take place. These
+ actions can be summarized as follows:
+
+ (1) An inventory should be taken of the systems' assets,
+ (i.e., a careful examination should determine how the
+ system was affected by the incident).
+
+ (2) The lessons learned as a result of the incident
+ should be included in revised security plan to
+ prevent the incident from re-occurring.
+
+ (3) A new risk analysis should be developed in light of the
+ incident.
+
+ (4) An investigation and prosecution of the individuals
+ who caused the incident should commence, if it is
+ deemed desirable.
+
+ If an incident is based on poor policy, and unless the policy is
+ changed, then one is doomed to repeat the past. Once a site has
+ recovered from and incident, site policy and procedures should be
+ reviewed to encompass changes to prevent similar incidents. Even
+ without an incident, it would be prudent to review policies and
+ procedures on a regular basis. Reviews are imperative due to today's
+ changing computing environments.
+
+
+
+
+Site Security Working Group [Page 47]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ The whole purpose of this post mortem process is to improve all
+ security measures to protect the site against future attacks. As a
+ result of an incident, a site or organization should gain practical
+ knowledge from the experience. A concrete goal of the post mortem is
+ to develop new proactive methods. Another important facet of the
+ aftermath may be end user and administrator education to prevent a
+ reoccurrence of the security problem.
+
+5.6 Responsibilities
+
+5.6.1 Not crossing the line
+
+ It is one thing to protect one's own network, but quite another to
+ assume that one should protect other networks. During the handling
+ of an incident, certain system vulnerabilities of one's own systems
+ and the systems of others become apparent. It is quite easy and may
+ even be tempting to pursue the intruders in order to track them.
+ Keep in mind that at a certain point it is possible to "cross the
+ line," and, with the best of intentions, become no better than the
+ intruder.
+
+ The best rule when it comes to propriety is to not use any facility
+ of remote sites which is not public. This clearly excludes any entry
+ onto a system (such as a remote shell or login session) which is not
+ expressly permitted. This may be very tempting; after a breach of
+ security is detected, a system administrator may have the means to
+ "follow it up," to ascertain what damage is being done to the remote
+ site. Don't do it! Instead, attempt to reach the appropriate point
+ of contact for the affected site.
+
+5.6.2 Good Internet Citizenship
+
+ During a security incident there are two choices one can make.
+ First, a site can choose to watch the intruder in the hopes of
+ catching him; or, the site can go about cleaning up after the
+ incident and shut the intruder out of the systems. This is a
+ decision that must be made very thoughtfully, as there may be legal
+ liabilities if you choose to leave your site open, knowing that an
+ intruder is using your site as a launching pad to reach out to other
+ sites. Being a good Internet citizen means that you should try to
+ alert other sites that may have been impacted by the intruder. These
+ affected sites may be readily apparent after a thorough review of
+ your log files.
+
+5.6.3 Administrative Response to Incidents
+
+ When a security incident involves a user, the site's security policy
+ should describe what action is to be taken. The transgression should
+ be taken seriously, but it is very important to be sure of the role
+ the user played. Was the user naive? Could there be a mistake in
+ attributing the security breach to the user? Applying administrative
+ action that assumes the user intentionally caused the incident may
+ not be appropriate for a user who simply made a mistake. It may be
+ appropriate to include sanctions more suitable for such a situation
+
+
+
+Site Security Working Group [Page 48]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ in your policies (e.g., education or reprimand of a user) in addition
+ to more stern measures for intentional acts of intrusion and system
+ misuse.
+
+6. Ongoing Activities
+
+ At this point in time, your site has hopefully developed a complete
+ security policy and developed procedures to assist in the
+ configuration and management of your technology in support of those
+ policies. How nice it would be if you could sit back and relax at
+ this point and know that you were finished with the job of security.
+ Unfortunately, that isn't the case. Your systems and networks are
+ not a static environment, so you will need to review policies and
+ procedures on a regular basis. There are a number of steps you can
+ take to help you keep up with the changes around you so that you can
+ initiate corresponding actions to address those changes. The
+ following is a starter set and you may add others as appropriate for
+ your site.
+
+ (1) Subscribe to advisories that are issued by various security incide=
+nt
+ response teams, like those of the CERT Coordination Center [ref], =
+and
+ update your systems against those threats that apply to your site'=
+s
+ technology.
+
+ (2) Monitor security patches that are produced by the vendors of your
+ equipment, and obtain and install all that apply.
+
+ (3) Actively watch the configurations of your systems to identify any
+ changes that may have occurred, then investigate all anomalies.
+
+ (4) Review all security policies and procedures annually (at a minimum=
+)
+
+ (5) Read appropriate mailing lists and USENET newsgroups to keep up to
+ date with the latest information being shared by fellow
+ administrators.
+
+ (6) Regularly check for compliance to policies and procedures. This
+ audit should be performed by someone other than the people who
+ define or implement the policies and procedures.
+
+7. Tools and Locations
+
+ This section provides a brief overview of publicly available security
+ technology which can be downloaded from the Internet. Many of the
+ items described below will undoubtedly be surpassed or made obsolete
+ before this document is published. This section is divided into two
+ major subsections, applications and tools. The applications heading
+ will include all end user programs (clients) and their supporting
+ system infrastructure (servers). The tools heading will deal with
+ the tools that a general user will never see or need to use, but
+ which may be part of or used by applications, used to troubleshoot
+ security problems or guard against intruders by system and network
+ administrators.
+
+
+
+
+Site Security Working Group [Page 49]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ The emphasis will be on UNIX applications and tools, but other
+ platforms, particularly PC's and Macintoshes, will be mentioned where
+ information is available.
+
+ Most of the tools and applications described below can be found in
+ one of the following two archive sites:
+
+ (1) CERT Coordination Center
+ ftp://info.cert.org:/pub/tools
+ (2) DFN-CERT
+ ftp://ftp.cert.dfn.de/pub/tools/
+ (3) Computer Operations, Audit, and Security Tools (COAST)
+ coast.cs.purdue.edu:/pub/tools
+
+ Any references to CERT or COAST will refer to these two locations.
+ These two sites act as repositories for most tools, exceptions will
+ be noted in the text. *** It is important to note that many sites,
+ including CERT and COAST are mirrored throughout the Internet. Be
+ careful to use a "well known" mirror site to retrieve software and to
+ use whatever verification tools possible, checksums, md5 checksums,
+ etc... to validate that software. A clever cracker might advertise
+ security software with designed flaws in order to gain access to data
+ or machines. ***
+
+Applications
+
+ The sad truth is that there are very few security conscious
+ applications currently available. The real reason is the need for a
+ security infrastructure which must be first put into place for most
+ applications to operate securely. There is considerable effort
+ currently taking place to place this infrastructure so that
+ applications can take advantage of secure communications.
+
+Unix based applications
+
+ COPS
+ DES
+ Drawbridge
+ identd (not really a security tool)
+ ISS
+ Kerberos
+ logdaemon
+ lsof
+ MD5
+ PEM
+ PGP
+ rpcbind/portmapper replacement
+ SATAN
+ sfingerd
+ S/KEY
+ smrsh
+ ssh
+ swatch
+ TCP-Wrapper
+
+
+
+Site Security Working Group [Page 50]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ tiger
+ Tripwire
+ TROJAN.PL
+
+8. Mailing Lists and Other Resources
+
+ It would be impossible to list all of the mail-lists and other
+ resources dealing with site security. However, these are some "jump-
+ points" from which the reader can begin. All of these references are
+ for the "INTERNET" constituency. More specific (vendor and
+ geographical) resources can be found through these references.
+
+ Mailing Lists
+
+ (1) CERT Advisory
+ Send mail to: cert-advisory-request@cert.org
+ Message Body: subscribe cert <FIRST NAME> <LAST NAME>
+
+ A CERT advisory provides information on how to obtain a patch or
+ details of a workaround for a known computer security problem.
+ The CERT Coordination Center works with vendors to produce a
+ workaround or a patch for a problem, and does not publish
+ vulnerability information until a workaround or a patch is
+ available. A CERT advisory may also be a warning to our
+ constituency about ongoing attacks (e.g.,
+ "CA-91:18.Active.Internet.tftp.Attacks").
+
+
+ CERT advisories are also published on the USENET newsgroup:
+ comp.security.announce
+
+ CERT advisory archives are available via anonymous FTP from
+ info.cert.org in the /pub/cert_advisories directory.
+
+ (2) CERT Tools Mailing List
+ Send mail to: cert-tools-request@cert.sei.cmu.edu
+ Message Body: subscribe cert-tools FIRSTNAME LASTNAME
+
+ The purpose of this moderated mailing list is to
+ encourage the exchange of information on security
+ tools and techniques. The list should not be used
+ for security problem reports.
+
+ (3) VIRUS-L List
+ Send mail to: listserv%lehiibm1.bitnet@mitvma.mit.edu
+ Message Body: subscribe virus-L FIRSTNAME LASTNAME
+
+ VIRUS-L is a moderated mailing list with a focus
+ on computer virus issues. For more information,
+ including a copy of the posting guidelines, see
+ the file "virus-l.README", available by anonymous
+ FTP from cs.ucr.edu.
+
+ (4) Academic Firewalls
+
+
+
+Site Security Working Group [Page 51]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Send mail to: majordomo@greatcircle.com
+ Message Body: subscribe firewalls user@host
+
+ The Firewalls mailing list is a discussion forum for
+ firewall administrators and implementors.
+
+ USENET newsgroups
+
+ (1) comp.security.announce
+ The comp.security.announce newsgroup is moderated
+ and is used solely for the distribution of CERT
+ advisories.
+
+ (2) comp.security.misc
+ The comp.security.misc is a forum for the
+ discussion of computer security, especially as it
+ relates to the UNIX(r) Operating System.
+
+ (3) alt.security
+ The alt.security newsgroup is also a forum for the
+ discussion of computer security, as well as other
+ issues such as car locks and alarm systems.
+
+ (4) comp.virus
+ The comp.virus newsgroup is a moderated newsgroup
+ with a focus on computer virus issues. For more
+ information, including a copy of the posting
+ guidelines, see the file "virus-l.README",
+ available via anonymous FTP on info.cert.org
+ in the /pub/virus-l directory.
+
+ (5) comp.risks
+ The comp.risks newsgroup is a moderated forum on
+ the risks to the public in computers and related
+ systems.
+
+ World-Wide Web Pages
+
+ (1) http://www.first.org/
+
+ Computer Security Resource Clearinghouse. The main focus is on
+ crisis response information; information on computer
+ security-related threats, vulnerabilities, and solutions. At the
+ same time, the Clearinghouse strives to be a general index to
+ computer security information on a broad variety of subjects,
+ including general risks, privacy, legal issues, viruses,
+ assurance, policy, and training.
+
+ (2) http://www.telstra.com.au/info/security.html
+
+ This Reference Index contains a list of links to information
+ sources on Network and Computer Security. There is no implied
+ fitness to the Tools, Techniques and Documents contained within th=
+is
+ archive. Many if not all of these items work well, but we do
+
+
+
+Site Security Working Group [Page 52]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ not guarantee that this will be so. This information is for the
+ education and legitimate use of computer security techniques only.
+
+ (3) http://www.alw.nih.gov/Security/security.html
+
+ This page features general information about computer security.
+ Information is organized by source and each section is organized
+ by topic. Recent modifications are noted in What's New page.
+
+
+9. References
+
+ [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and
+ McAuliffe, "The Law and The Internet", USENIX 1995 Technical
+ Conference on UNIX and Advanced Computing, New Orleans, LA, January
+ 16-20, 1995.
+
+ [ABA, 1989] American Bar Association, Section of Science and
+ Technology, "Guide to the Prosecution of Telecommunication Fraud by
+ the Use of Computer Crime Statutes", American Bar Association, 1989.
+
+ [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery",
+ Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989.
+
+ [Barrett, 1996] D. Barrett, "Bandits on the Information
+ Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.
+
+ [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks,
+ Telecommunications and Data Communications", McGraw-Hill, 1992.
+
+ [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP
+ Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48,
+ April 1989.
+
+ [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the
+ Kerberos Authentication System", Computer Communications Review,
+ October 1990.
+
+ [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings
+ of the Third Usenix Security Symposium, Baltimore, MD. September,
+ 1992.
+
+ [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M.
+ Bender, New York, NY, 1978-present.
+
+ [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes",
+ Dow Jones- Irwin, Homewood, IL. 1990.
+
+ [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security
+ Incidents: A Primer from Prevention through Recovery", R. Brand, 8
+ June 1990.
+
+ [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and
+ the Vulnerability of National Telecommunications Networks to Computer
+
+
+
+Site Security Working Group [Page 53]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.
+
+ [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt,
+ "BS 7799 : 1995 Code of Practice for Information Security
+ Management", British Standards Institution, London, 54, Effective 15
+ February 1995.
+
+ [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of
+ Information", Proceedings of the Fifth IFIP International Conference
+ on Computer Security, IFIP/Sec '88.
+
+ [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition,
+ Butterworth Publishers, Stoneham, MA, 1987.
+
+ [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and
+ The Law", MIT Press, Cambridge, MA, 1995.
+
+ [CCH, 1989] Commerce Clearing House, "Guide to Computer Law",
+ (Topical Law Reports), Chicago, IL., 1989.
+
+ [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet
+ Filtering", USSENIX: Proceedings of the Thrid UNIX Security
+ Symposium, Baltimore, MD, September 1992.
+
+ [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building
+ Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.
+
+ [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet
+ Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA,
+ June 1990.
+
+ [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker
+ is Lured, Endured, and Studied", AT&T Bell Laboratories.
+
+ [Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls
+ and Internet Security: Repelling the Wily Hacker", Addison-Wesley,
+ Reading, MA, 1994.
+
+ [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation
+ and Prosecution", U.S. Dept. of Justice, Office of Justice Programs,
+ Under Contract Number OJP-86-C-002, National Institute of Justice,
+ Washington, DC, July 1989.
+
+ [Cooper, 1989] J. Cooper, "Computer and Communications Security:
+ Strategies for the 1990s", McGraw-Hill, 1989.
+
+ [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR
+ Statement on the Computer Virus", CPSR, Communications of the ACM,
+ Vol. 32, No. 6, Pg. 699, June 1989.
+
+ [CSC-STD-002-85, 1985] Department of Defense, "Password Management
+ Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.
+
+ [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System",
+
+
+
+Site Security Working Group [Page 54]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ SRI International Report ITSTD-721-FR-90-21, April 1990.
+
+ [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and
+ Systems Administrators", Addision-Wesley, Reading, MA, 1992.
+
+ [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem
+ Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3
+ November 1988.
+
+ [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin
+ 03", DDN Security Coordination Center, 17 October 1989.
+
+ [Denning, 1990] P. Denning, Editor, "Computers Under Attack:
+ Intruders, Worms, and Viruses", ACM Press, 1990.
+
+ [Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With
+ Microscope and Tweezers: An Analysis of the Internet Virus of
+ November 1988", Massachusetts Institute of Technology, February 1989.
+
+ [Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D.
+ Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell
+ University, 6 February 1989.
+
+ [Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and
+ C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford
+ University Press, NY, 1990. (376 pages, includes bibliographical
+ references).
+
+ [Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS
+ Security Checker System", Proceedings of the Summer 1990 USENIX
+ Conference, Anaheim, CA, Pgs. 165-170, June 1990.
+
+ [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley,
+ Reading, MA, 1991.
+
+ [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial
+ Tactics and Techniques", Litigation Course Handbook Series No. 280,
+ Prepared for distribution at the Computer Litigation, 1985: Trial
+ Tactics and Techniques Program, February-March 1985.
+
+ [Fites, Kratz, and Brebner, 1989] M. Fites, P. Kratz, and A. Brebner,
+ "Control and Security of Computer Information Systems", Computer
+ Science Press, 1989.
+
+ [Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The
+ Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.
+
+ [Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer
+ Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
+ Cambridge, MA, 1990.
+
+ [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer
+ Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
+ Cambridge, MA, 1990. (192 pages including index.)
+
+
+
+Site Security Working Group [Page 55]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer
+ Security - Virus Highlights Need for Improved Internet Management",
+ United States General Accounting Office, Washington, DC, 1989.
+
+ [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford,
+ "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2,
+ May 1991.
+
+ [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly &
+ Associates, Sebastopol, CA, 1996.
+
+ [Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford,
+ "Practical UNIX and Internet Security", O'Reilly & Associates,
+ Sebastopol, CA, 1996.
+
+ [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law",
+ Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
+
+ [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True
+ Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell
+ Publishing, 328pp, 1996.
+
+ [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and
+ Social Implications of Computer Networking", Westview Press, Boulder,
+ CO, 1989.
+
+ [Greenia, 1989] M. Greenia, "Computer Security Information
+ Sourcebook", Lexikon Services, Sacramento, CA, 1989.
+
+ [Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk:
+ Outlaws and Hackers on the Computer Frontier", Touchstone, Simon &
+ Schuster, 1991.
+
+ [Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix
+ Network Protocol Security Study: Network Information Service", Texas
+ A&M University.
+
+ [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and
+ Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages,
+ includes bibliographical references and index.)
+
+ [Howard, 1995] G. Howard, "Introduction to Internet Security: From
+ Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.
+
+ [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors,
+ "Protection of Computer Systems and Software: New Approaches for
+ Combating Theft of Software and Unauthorized Intrusion", Papers
+ presented at a workshop sponsored by the National Science Foundation,
+ 1986.
+
+ [Hughes, 1995] L. Hughes Jr., "Actually Useful: Internet Security
+ Techniques", New Riders Publishing, Indianapolis, IN, 1995.
+
+ [IAB-RFC1087, 89] Internet Activities Board, "Ethics and the
+
+
+
+Site Security Working Group [Page 56]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Internet", RFC 1087, IAB, January 1989. Also appears in the
+ Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.
+
+ [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W.
+ VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly &
+ Associates, Sebastopol, CA, 1995.
+
+ [IVPC, 1996] IVPC, "International Virus Prevention Conference '96
+ Proceedings", NCSA, 1996.
+
+ [Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A
+ Company Policy on Access to and Use and Disclosure of Electronic Mail
+ on Company Computer Systems".
+
+ [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The
+ Ongoing War Against Information Sabotage", M&T Books, 1994.
+
+ [Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M.
+ Speciner, "Network Security: PRIVATE Communication in a PUBLIC
+ World", Prentice Hall, Englewood Cliffs, NJ, 1995.
+
+ [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software
+ and Strict Registration Procedures will be Implemented this Year",
+ Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January
+ 1990.
+
+ [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution",
+ Delta, 1984.
+
+ [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems
+ Audit Group, 1996.
+
+ [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin
+ Mitnick", Little, Brown, Boston, MA. 333p, 1996.
+
+ [Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure
+ Communication in Internet Environments: A Hierarchical Key Management
+ Scheme for End-to-End Encryption", IEEE Transactions on
+ Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
+
+ [Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for
+ Multilevel Security in Computer Networks", IEEE Transactions on
+ Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.
+
+ [Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics
+ in Engineering", McGraw Hill, 2nd Edition, 1989.
+
+ [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal
+ of Cryptology, Vol. 3, No. 1.
+
+ [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report
+ Contributors: D. Fester and H. Nugent, Prepared for the National
+ Institute of Justice, U.S. Department of Justice, by Institute for
+ Law and Justice, Inc., under contract number OJP-85-C-006,
+
+
+
+Site Security Working Group [Page 57]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Washington, DC, 1989.
+
+ [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students
+ About Responsible Use of Computers", MIT, 1985-1986. Also reprinted
+ in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena
+ Project, MIT, June 1989.
+
+ [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access
+ Controls for UNIX-based Gateways", Digital Western Research
+ Laboratory Research Report 89/4, March 1989.
+
+ [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password
+ Checker for Unix"
+
+ [NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995.
+
+ [NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention
+ Policy Model", NCSA, 1995.
+
+ [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96
+ Proceedings", 1996.
+
+ [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines
+ for Formal Verification Systems", Shipping list no.: 89-660-P, The
+ Center, Fort George G. Meade, MD, 1 April 1990.
+
+ [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of
+ Computer Security Terms", Shipping list no.: 89-254-P, The Center,
+ Fort George G. Meade, MD, 21 October 1988.
+
+ [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention,
+ Detection, and Treatment", National Computer Security Center C1
+ Technical Report C1-001-89, June 1989.
+
+ [NCSC Conference, 1989] National Computer Security Conference, "12th
+ National Computer Security Conference: Baltimore Convention Center,
+ Baltimore, MD, 10-13 October, 1989: Information Systems Security,
+ Solutions for Today - Concepts for Tomorrow", National Institute of
+ Standards and National Computer Security Center, 1989.
+
+ [NCSC-CSC-STD-003-85, 1985] National Computer Security Center,
+ "Guidance for Applying the Department of Defense Trusted Computer
+ System Evaluation Criteria in Specific Environments", CSC-STD-003-85,
+ NCSC, 25 June 1985.
+
+ [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical
+ Rationale Behind CSC-STD-003-85: Computer Security Requirements",
+ CSC-STD-004-85, NCSC, 25 June 1985.
+
+ [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic
+ Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November
+ 1985.
+
+ [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted
+
+
+
+Site Security Working Group [Page 58]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-
+ 83, NCSC, December 1985.
+
+ [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY
+ ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30
+ September 1987, 29 pages.
+
+ [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted
+ Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
+
+ [NCSC-TG-004, 1988] National Computer Security Center, "Glossary of
+ Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
+
+ [NCSC-TG-005, 1987] National Computer Security Center, "Trusted
+ Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
+
+ [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION
+ MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March
+ 1988, 31 pages.
+
+ [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX
+ Working Group (TRUSIX) rationale for selecting access control list
+ features for the UNIX system", Shipping list no.: 90-076-P, The
+ Center, Fort George G. Meade, MD, 1990.
+
+ [NRC, 1991] National Research Council, "Computers at Risk: Safe
+ Computing in the Information Age", National Academy Press, 1991.
+
+ [Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein,
+ "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood
+ Cliffs, NJ, 2ed. 1995.
+
+ [NIST, 1989] National Institute of Standards and Technology,
+ "Computer Viruses and Related Threats: A Management Guide", NIST
+ Special Publication 500-166, August 1989.
+
+ [NSA] National Security Agency, "Information Systems Security
+ Products and Services Catalog", NSA, Quarterly Publication.
+
+ [NSF, 1988] National Science Foundation, "NSF Poses Code of
+ Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg.
+ 688, June 1989. Also appears in the minutes of the regular meeting
+ of the Division Advisory Panel for Networking and Communications
+ Research and Infrastructure, Dave Farber, Chair, November 29-30,
+ 1988.
+
+ [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation
+ Security Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987, 58
+ pages.
+
+ [OTA-CIT-310, 1987] United States Congress, Office of Technology
+ Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for
+ Electronic Information", OTA-CIT-310, October 1987.
+
+
+
+
+Site Security Working Group [Page 59]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [OTA-TCT-606] Congress of the United States, Office of Technology
+ Assessment, "Information Security and Privacy in Network
+ Environments", OTA-TCT-606, September 1994.
+
+ [Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer
+ Security Risk Management", Van Nostrand Reinhold, NY, 1989.
+
+ [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource
+ Manual", U.S. Dept. of Justice, National Institute of Justice, Office
+ of Justice Programs, Under Contract Number OJP-86-C-002, Washington,
+ D.C., August 1989.
+
+ [Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker,
+ "Ethical Conflicts: Information and Computer Science, Technology and
+ Business", QED Information Sciences, Inc., Wellesley, MA. (245
+ pages).
+
+ [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall,
+ Englewood Cliffs, NJ, 1989.
+
+ [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks
+ and Conferencing Systems Worldwide", Digital Press, Bedford, MA,
+ 1990.
+
+ [Ranum1, 1992] M. Ranum, "An Internet Firwall", Proceedings of World
+ Conference on Systems Management and Security, 1992.
+
+ [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment
+ Corporation Washington Open Systems Resource Center, June 12, 1992.
+
+ [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993.
+
+ [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and
+ Methods for Internet Firewalls", Trustest Information Systems, 1994.
+
+ [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX
+ Network Security"
+
+ [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX
+ Network Security", ARINC Research Corporation, February 18, 1993.
+
+ [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135,
+ USC/Information Sciences Institute, Marina del Rey, CA, December
+ 1989.
+
+ [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer
+ Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991.
+
+ [Schneier 1996] B. Schneier, "Applied Cryptography: Protocols,
+ Algorithms, and Source Code in C", John Wiley & Sons, New York,
+ second edition, 1996.
+
+ [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989
+ Winter USENIX Conference, Usenix Association, San Diego, CA, February
+
+
+
+Site Security Working Group [Page 60]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ 1989.
+
+ [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986",
+ Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.
+
+ [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit
+ and Capture of Kevin Mitnick, America's Most Wanted Comptuer Outlaw-
+ by the Man Who Did It", Hyperion, 324p, 1996.
+
+ [Shirey, 1990] R. Shirey, "Defense Data Network Security
+ Architecture", Computer Communication Review, Vol. 20, No. 2, Page
+ 66, 1 April 1990.
+
+ [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters
+ of Deception: The Gang that Ruled Cyberspace", Harper Collins
+ Publishers, 1995.
+
+ [Smith, 1989] M. Smith, "Commonsense Computer Security: Your
+ Practical Guide to Preventing Accidental and Deliberate Electronic
+ Data Loss", McGraw-Hill, New York, NY, 1989.
+
+ [Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth
+ Annual Computer Security Incident Handling Workshop, Boston, MA, July
+ 25-29, 1995.
+
+ [Spafford, 1988] E. Spafford, "The Internet Worm Program: An
+ Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM,
+ January 1989. Also issued as Purdue CS Technical Report CSD-TR-823,
+ 28 November 1988.
+
+ [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm",
+ Proceedings of the European Software Engineering Conference 1989,
+ Warwick England, September 1989. Proceedings published by Springer-
+ Verlag as: Lecture Notes in Computer Science #387. Also issued as
+ Purdue Technical Report #CSD-TR-933.
+
+ [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and
+ D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism
+ and Programmed Threats", ADAPSO, 1989. (109 pages.)
+
+ [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG
+ Books, Foster City CA, 1995.
+
+ [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security",
+ Prentice Hall, , 1995.
+
+ [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for
+ PGP Users" PTR Prentice Hall, 1995.
+
+ [Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of
+ the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988.
+
+ [Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2,
+ Doubleday, 1989.
+
+
+
+Site Security Working Group [Page 61]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the
+ Firewall, and Other Applications Relays", Digital Equipment
+ Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993.
+
+ [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986",
+ U.S. Senate Committee on the Judiciary, 1986.
+
+ [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control,
+ and booby traps", Mathematics and Computing Science, Eindhoven
+ University of Technology, The Netherlands.
+
+ [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop",
+ Portland, OR, August 29-30, 1988.
+
+ [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II
+ Workshop", Portland, OR, August 27-28, 1990.
+
+ [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security
+ III", Baltimore, MD, September 14-16, 1992.
+
+ [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security
+ IV", Santa Clara, CA, October 4-6, 1993.
+
+ [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium",
+ Salt Lake City, UT, June 5-7, 1995.
+
+ [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V.
+ Hampel, and H. Sartorio, "Computer Security: A Comprehensive
+ Controls Checklist", John Wiley and Sons, Interscience Publication,
+ 1987.
+
+ [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for
+ Telecommunications Networks and LANS", Artech House, 1993.
+
+ [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A
+ Manual with Case Studies", Wiley, New York, NY, 1989.
+
+10. Annotated Bibliography
+
+ The intent of this annotated bibliography is to offer a
+ representative collection of resources of information that will help
+ the user of this handbook. It is meant provide a starting point for
+ further research in the security area. Included are references to
+ other sources of information for those who wish to pursue issues of
+ the computer security environment.
+
+10.1 Computer Law
+
+ [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and
+ McAuliffe, "The Law and The Internet", USENIX 1995 Technical
+ Conference on UNIX and Advanced Computing, New Orleans, LA, January
+ 16-20, 1995.
+
+ [ABA, 1989] American Bar Association, Section of Science and
+
+
+
+Site Security Working Group [Page 62]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Technology, "Guide to the Prosecution of Telecommunication Fraud by
+ the Use of Computer Crime Statutes", American Bar Association, 1989.
+
+ [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M.
+ Bender, New York, NY, 1978-present.
+
+ Kept up to date with supplements. Years covering 1978-1984 focuses
+ on: Computer law, evidence and procedures. The years 1984 to the
+ current focus on general computer law. Bibliographical references
+ and index included.
+
+ [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes",
+ Dow Jones- Irwin, Homewood, IL. 1990.
+
+ [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and
+ The Law", MIT Press, Cambridge, MA, 1995.
+
+ [CCH, 1989] Commerce Clearing House, "Guide to Computer Law",
+ (Topical Law Reports), Chicago, IL., 1989.
+
+ Court cases and decisions rendered by federal and state courts
+ throughout the United States on federal and state computer law.
+ Includes Case Table and Topical Index.
+
+ [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation
+ and Prosecution", U.S. Dept. of Justice, Office of Justice Programs,
+ Under Contract Number OJP-86-C-002, National Institute of Justice,
+ Washington, DC, July 1989.
+
+ [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial
+ Tactics and Techniques", Litigation Course Handbook Series No. 280,
+ Prepared for distribution at the Computer Litigation, 1985: Trial
+ Tactics and Techniques Program, February-March 1985.
+
+ [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law",
+ Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
+
+ [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors,
+ "Protection of Computer Systems and Software: New Approaches for
+ Combating Theft of Software and Unauthorized Intrusion", Papers
+ presented at a workshop sponsored by the National Science Foundation,
+ 1986.
+
+ [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report
+ Contributors: D. Fester and H. Nugent, Prepared for the National
+ Institute of Justice, U.S. Department of Justice, by Institute for
+ Law and Justice, Inc., under contract number OJP-85-C-006,
+ Washington, DC, 1989.
+
+ [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource
+ Manual", U.S. Dept. of Justice, National Institute of Justice, Office
+ of Justice Programs, Under Contract Number OJP-86-C-002, Washington,
+ D.C., August 1989.
+
+
+
+
+Site Security Working Group [Page 63]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986,
+ Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.
+
+ [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986",
+ U.S. Senate Committee on the Judiciary, 1986.
+
+
+10.2 Computer and Network Security
+
+ [Brand, 1990] Brand, R., "Coping with the Threat of Computer Security
+ Incidents: A Primer from Prevention through Recovery", R. Brand,
+ available on-line from: cert.sei.cmu.edu:/pub/info/primer, 8 June
+ 1990.
+
+ [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP
+ Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48,
+ April 1989.
+
+ [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the
+ Kerberos Authentication System", Computer Communications Review,
+ October 1990.
+
+ [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt,
+ "BS 7799 : 1995 Code of Practice for Information Security
+ Management", British Standards Institution, London, 54, Effective 15
+ February 1995.
+
+ Based on PD 0003: Price c. GBP 35
+
+ The code is divided into 10 sections: security policy, security
+ organization, assets classification and control, personnel security,
+ physical and environmental security, computer and network management,
+ system and access control, system development and maintenance,
+ business continuity planning, and compliance.
+
+ [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of
+ Information", Proceedings of the Fifth IFIP International Conference
+ on Computer Security, IFIP/Sec '88.
+
+ [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition,
+ Butterworth Publishers, Stoneham, MA, 1987.
+
+ [Cooper, 1989] J. Cooper, "Computer and Communications Security:
+ Strategies for the 1990s", McGraw-Hill, 1989.
+
+ [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security
+ Incidents: A Primer from Prevention through Recovery", R. Brand, 8
+ June 1990.
+
+ As computer security becomes a more important issue in modern
+ society, it begins to warrant a systematic approach. The vast
+ majority of the computer security problems and the costs associated
+ with them can be prevented with simple inexpensive measures. The
+ most important and cost effective of these measures are available in
+
+
+
+Site Security Working Group [Page 64]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ the prevention and planning phases. These methods are presented in
+ this paper, followed by a simplified guide to incident handling and
+ recovery. Available on-line from:
+ cert.sei.cmu.edu:/pub/info/primer.
+
+ [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet
+ Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA,
+ June 1990.
+
+ Brief abstract (slight paraphrase from the original abstract): AT&T
+ maintains a large internal Internet that needs to be protected from
+ outside attacks, while providing useful services between the two.
+ This paper describes AT&T's Internet gateway. This gateway passes
+ mail and many of the common Internet services between AT&T internal
+ machines and the Internet. This is accomplished without IP
+ connectivity using a pair of machines: a trusted internal machine and
+ an untrusted external gateway. These are connected by a private
+ link. The internal machine provides a few carefully-guarded services
+ to the external gateway. This configuration helps protect the
+ internal internet even if the external machine is fully compromised.
+
+ This is a very useful and interesting design. Most firewall gateway
+ systems rely on a system that, if compromised, could allow access to
+ the machines behind the firewall. Also, most firewall systems
+ require users who want access to Internet services to have accounts
+ on the firewall machine. AT&T's design allows AT&T internal internet
+ users access to the standard services of TELNET and FTP from their
+ own workstations without accounts on the firewall machine. A very
+ useful paper that shows how to maintain some of the benefits of
+ Internet connectivity while still maintaining strong security.
+
+ [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and
+ Systems Administrators", Addision-Wesley, Reading, MA, 1992.
+
+ [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System",
+ SRI International Report ITSTD-721-FR-90-21, April 1990.
+
+ This paper describes measures that you, as a system administrator can
+ take to make your UNIX system(s) more secure. Oriented primarily at
+ SunOS 4.x, most of the information covered applies equally well to
+ any Berkeley UNIX system with or without NFS and/or Yellow Pages
+ (NIS). Some of the information can also be applied to System V,
+ although this is not a primary focus of the paper. A very useful
+ reference, this is also available on the Internet in various
+ locations, including the directory cert.sei.cmu.edu:/pub/info.
+
+ [Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS
+ Security Checker System", Proceedings of the Summer 1990 USENIX
+ Conference, Anaheim, CA, Pgs. 165-170, June 1990.
+
+ [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley,
+ Reading, MA, 1991.
+
+ [Fites, Kratz, and Brebner, 1989] M. Fites, P. Kratz, and A. Brebner,
+
+
+
+Site Security Working Group [Page 65]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ "Control and Security of Computer Information Systems", Computer
+ Science Press, 1989.
+
+ This book serves as a good guide to the issues encountered in forming
+ computer security policies and procedures. The book is designed as a
+ textbook for an introductory course in information systems security.
+
+ The book is divided into five sections: Risk Management (I),
+ Safeguards: security and control measures, organizational and
+ administrative (II), Safeguards: Security and Control Measures,
+ Technical (III), Legal Environment and Professionalism (IV), and CICA
+ Computer Control Guidelines (V).
+
+ The book is particularly notable for its straight-forward approach to
+ security, emphasizing that common sense is the first consideration in
+ designing a security program. The authors note that there is a
+ tendency to look to more technical solutions to security problems
+ while overlooking organizational controls which are often cheaper and
+ much more effective. 298 pages, including references and index.
+
+ [Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer
+ Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
+ Cambridge, MA, 1990.
+
+ [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford,
+ "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2,
+ May 1991.
+
+ Approx 450 pages, $29.95. Orders: 1-800-338-6887 (US & Canada),
+ 1-707-829-0515 (Europe), email: nuts@ora.com
+
+ This is one of the most useful books available on Unix security. The
+ first part of the book covers standard Unix and Unix security basics,
+ with particular emphasis on passwords. The second section covers
+ enforcing security on the system. Of particular interest to the
+ Internet user are the sections on network security, which address
+ many of the common security problems that afflict Internet Unix
+ users. Four chapters deal with handling security incidents, and the
+ book concludes with discussions of encryption, physical security, and
+ useful checklists and lists of resources. The book lives up to its
+ name; it is filled with specific references to possible security
+ holes, files to check, and things to do to improve security. This
+ book is an excellent complement to this handbook.
+
+ [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly &
+ Associates, Sebastopol, CA, 1996.
+
+ [Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford,
+ "Practical UNIX and Internet Security", O'Reilly & Associates,
+ Sebastopol, CA, 1996.
+
+ If you thought that the first edition was good, well this is better.
+
+ [Greenia, 1989] M. Greenia, "Computer Security Information
+
+
+
+Site Security Working Group [Page 66]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Sourcebook", Lexikon Services, Sacramento, CA, 1989.
+
+ A manager's guide to computer security. Contains a sourcebook of key
+ reference materials including access control and computer crimes
+ bibliographies.
+
+ [Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix
+ Network Protocol Security Study: Network Information Service", Texas
+ A&M University.
+
+ [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and
+ Trojan Horses", Van Nostrand Reinhold, NY, 1990. (384 pages,
+ includes bibliographical references and index.)
+
+ [Hughes, 1995] L. Hughes Jr., "Actually Useful: Internet Security
+ Techniques", New Riders Publishing, Indianapolis, IN, 1995.
+
+ [Howard, 1995] G. Howard, "Introduction to Internet Security: From
+ Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.
+
+ [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W.
+ VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly &
+ Associates, Sebastopol, CA, 1995.
+
+ [Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A
+ Company Policy on Access to and Use and Disclosure of Electronic Mail
+ on Company Computer Systems".
+
+ A white paper prepared for the EMA, written by two experts in privacy
+ law. Gives background on the issues, and presents some policy
+ options.
+
+ Available from: The Electronic Mail Association (EMA) 1555 Wilson
+ Blvd, Suite 555, Arlington, VA, 22209. (703) 522-7111.
+
+ [Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M.
+ Speciner, "Network Security: PRIVATE Communication in a PUBLIC
+ World", Prentice Hall, Englewood Cliffs, NJ, 1995.
+
+ A comprehensive guide to the latest advances in computer network
+ security protocols. 504 pages.
+
+ [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software
+ and Strict Registration Procedures will be Implemented this Year",
+ Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January
+ 1990.
+
+ [Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure
+ Communication in Internet Environments: A Hierarchical Key Management
+ Scheme for End-to-End Encryption", IEEE Transactions on
+ Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
+
+ [Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for
+ Multilevel Security in Computer Networks", IEEE Transactions on
+
+
+
+Site Security Working Group [Page 67]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.
+
+ [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal
+ of Cryptology, Vol. 3, No. 1.
+
+ [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access
+ Controls for UNIX-based Gateways", Digital Western Research
+ Laboratory Research Report 89/4, March 1989.
+
+ [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password
+ Checker for Unix"
+
+ [NRC, 1991] National Research Council, "Computers at Risk: Safe
+ Computing int the Information Age", National Academy Press, 1991.
+
+ [Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein,
+ "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood
+ Cliffs, NJ, 2ed. 1995.
+
+ Best book on UNIX System Administration. Also addresses UNIX
+ security in easy understandable way.
+
+ [NSA] National Security Agency, "Information Systems Security
+ Products and Services Catalog", NSA, Quarterly Publication.
+
+ NSA's catalogue contains chapter on: Endorsed Cryptographic Products
+ List; NSA Endorsed Data Encryption Standard (DES) Products List;
+ Protected Services List; Evaluated Products List; Preferred Products
+ List; and Endorsed Tools List.
+
+ The catalogue is available from the Superintendent of Documents, U.S.
+ Government Printing Office, Washington, D.C. One may place telephone
+ orders by calling: (202) 783-3238.
+
+ [OTA-CIT-310, 1987] United States Congress, Office of Technology
+ Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for
+ Electronic Information", OTA-CIT-310, October 1987.
+
+ This report, prepared for congressional committee considering Federal
+ policy on the protection of electronic information, is interesting
+ because of the issues it raises regarding the impact of technology
+ used to protect information. It also serves as a reasonable
+ introduction to the various encryption and information protection
+ mechanisms. 185 pages. Available from the U.S. Government Printing
+ Office.
+
+ [OTA-TCT-606] Congress of the United States, Office of Technology
+ Assessment, "Information Security and Privacy in Network
+ Environments", OTA-TCT-606, September 1994.
+
+ "This report was prepared in response to a request by the Senate
+ Committee on Governmental Affairs and the House Subcommittee on
+ Telecommunications and Finance. The report focuses on policy issues
+ in three areas: 1)national cryptography policy, including federal
+
+
+
+Site Security Working Group [Page 68]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ information processing standards and export controls; 2)guidance on
+ safeguarding unclassified information in federal agencies; and
+ 3)legal issues and information security, including electronic
+ commerce, privacy, and intellectual property." 244 pages. Available
+ from the U.S. Government Printing Office.
+
+ [Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer
+ Security Risk Management", Van Nostrand Reinhold, NY, 1989.
+
+ [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall,
+ Englewood Cliffs, NJ, 1989.
+
+ A general textbook in computer security, this book provides an
+ excellent and very readable introduction to classic computer security
+ problems and solutions, with a particular emphasis on encryption.
+ The encryption coverage serves as a good introduction to the subject.
+ Other topics covered include building secure programs and systems,
+ security of database, personal computer security, network and
+ communications security, physical security, risk analysis and
+ security planning, and legal and ethical issues. 538 pages including
+ index and bibliography.
+
+ [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks
+ and Conferencing Systems Worldwide", Digital Press, Bedford, MA,
+ 1990.
+
+ [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX
+ Network Security"
+
+ More details in USENIX Thrid UNIX Security Symposium, September 14-16
+ 1992.
+
+ [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX
+ Network Security", ARINC Research Corporation, February 18, 1993.
+
+ [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer
+ Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991.
+
+ [Shirey, 1990] R. Shirey, "Defense Data Network Security
+ Architecture", Computer Communication Review, Vol. 20, No. 2, Page
+ 66, 1 April 1990.
+
+ [Smith, 1994] D. Smith, "Forming an Incident Response Team", Sixth
+ Annual Computer Security Incident Handling Workshop, Boston, MA, July
+ 25-29, 1995.
+
+ [Smith, 1989] M. Smith, "Common Sense Computer Security: Your
+ Practical Guide to Preventing Accidental and Deliberate Electronic
+ Data Loss", McGraw-Hill, New York, NY, 1989.
+
+ A general text on computer security and how to access actual effort
+ based on need.
+
+ [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and
+
+
+
+Site Security Working Group [Page 69]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism
+ and Programmed Threats", ADAPSO, 1989. (109 pages.)
+
+ This is a good general reference on computer viruses and related
+ concerns. In addition to describing viruses in some detail, it also
+ covers more general security issues, legal recourse in case of
+ security problems, and includes lists of laws, journals focused on
+ computers security, and other security-related resources.
+
+ Available from: ADAPSO, 1300 N. 17th St, Suite 300, Arlington VA
+ 22209. (703) 522-5055.
+
+ [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG
+ Books, Foster City CA, 1995.
+
+ [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security",
+ Prentice Hall, , 1995.
+
+ [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for
+ PGP Users" PTR Prentice Hall, 1995.
+
+ [Stool, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of
+ the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988.
+
+ This article describes some of the technical means used to trace the
+ intruder that was later chronicled in "Cuckoo's Egg" (see below).
+
+ [Stool, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2,
+ Doubleday, 1989.
+
+ Clifford Stoll, an astronomer turned UNIX System Administrator,
+ recounts an exciting, true story of how he tracked a computer
+ intruder through the maze of American military and research networks.
+ This book is easy to understand and can serve as an interesting
+ introduction to the world of networking. Jon Postel says in a book
+ review, "[this book] ... is absolutely essential reading for anyone
+ that uses or operates any computer connected to the Internet or any
+ other computer network."
+
+ [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop",
+ Portland, OR, August 29-30, 1988.
+
+ [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II
+ Workshop", Portland, OR, August 27-28, 1990.
+
+ [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security
+ III", Baltimore, MD, September 14-16, 1992.
+
+ [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security
+ IV", Santa Clara, CA, October 4-6, 1993.
+
+ [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium",
+ Salt Lake City, UT, June 5-7, 1995.
+
+
+
+
+Site Security Working Group [Page 70]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A
+ Manual with Case Studies", Wiley, New York, NY, 1989.
+
+
+10.3 Ethics
+
+ [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR
+ Statement on the Computer Virus", CPSR, Communications of the ACM,
+ Vol. 32, No. 6, Pg. 699, June 1989.
+
+ This memo is a statement on the Internet Computer Virus by the
+ Computer Professionals for Social Responsibility (CPSR).
+
+ [Denning, 1990] P. Denning, Editor, "Computers Under Attack:
+ Intruders, Worms, and Viruses", ACM Press, 1990.
+
+ A collection of 40 pieces divided into six sections: the emergence of
+ worldwide computer networks, electronic break-ins, worms, viruses,
+ counterculture (articles examining the world of the "hacker"), and
+ finally a section discussing social, legal, and ethical
+ considerations.
+
+ A thoughtful collection that addresses the phenomenon of attacks on
+ computers. This includes a number of previously published articles
+ and some new ones. The previously published ones are well chosen,
+ and include some references that might be otherwise hard to obtain.
+ This book is a key reference to computer security threats that have
+ generated much of the concern over computer security in recent years.
+
+ [Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and
+ C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford
+ University Press, NY, 1990. (376 pages, includes bibliographical
+ references).
+
+ [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer
+ Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
+ Cambridge, MA, 1990. (192 pages including index.)
+
+ From the preface: "The aim of this book is two-fold: (1) to describe
+ some of the problems created by society by computers, and (2) to show
+ how these problems present ethical dilemmas for computers
+ professionals and computer users.
+
+ The problems created by computers arise, in turn, from two main
+ sources: from hardware and software malfunctions and from misuse by
+ human beings. We argue that computer systems by their very nature
+ are insecure, unreliable, and unpredictable -- and that society has
+ yet to come to terms with the consequences. We also seek to show how
+ society has become newly vulnerable to human misuse of computers in
+ the form of computer crime, software theft, hacking, the creation of
+ viruses, invasions of privacy, and so on."
+
+ The eight chapters include "Computer Crime", "Software Theft",
+ "Hacking and Viruses", "Unreliable Computers", "The Invasion of
+
+
+
+Site Security Working Group [Page 71]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Privacy", "AI and Expert Systems", and "Computerizing the Workplace."
+ Includes extensive notes on sources and an index.
+
+ [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and
+ Social Implications of Computer Networking", Westview Press, Boulder,
+ CO, 1989.
+
+ [IAB-RFC1087, 89] Internet Activities Board, "Ethics and the
+ Internet", RFC 1087, IAB, January 1989. Also appears in the
+ Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.
+
+ This memo is a statement of policy by the Internet Activities Board
+ (IAB) concerning the proper use of the resources of the Internet.
+ Available on-line on host ftp.nisc.sri.com, directory rfc, filename
+ rfc1087.txt. Also available on host nis.nsf.net, directory RFC,
+ filename RFC1087.TXT-1.
+
+ [Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics
+ in Engineering", McGraw Hill, 2nd Edition, 1989.
+
+ [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students
+ About Responsible Use of Computers", MIT, 1985-1986. Also reprinted
+ in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena
+ Project, MIT, June 1989. This memo is a statement of policy by the
+ Massachusetts Institute of Technology (MIT) on the responsible use of
+ computers.
+
+ [NIST, 1989] National Institute of Standards and Technology,
+ "Computer Viruses and Related Threats: A Management Guide", NIST
+ Special Publication 500-166, August 1989.
+
+ [NSF, 1988] National Science Foundation, "NSF Poses Code of
+ Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg.
+ 688, June 1989. Also appears in the minutes of the regular meeting
+ of the Division Advisory Panel for Networking and Communications
+ Research and Infrastructure, Dave Farber, Chair, November 29-30,
+ 1988.
+
+ This memo is a statement of policy by the National Science Foundation
+ (NSF) concerning the ethical use of the Internet.
+
+ [Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker,
+ "Ethical Conflicts: Information and Computer Science, Technology and
+ Business", QED Information Sciences, Inc., Wellesley, MA. (245
+ pages).
+
+ Additional publications on Ethics:
+
+ The University of New Mexico (UNM)
+
+ The UNM has a collection of ethics documents. Included are
+ legislation from several states and policies from many
+ institutions.
+
+
+
+
+Site Security Working Group [Page 72]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Access is via FTP, IP address ariel.umn.edu. Look in the
+ directory /ethics.
+
+
+10.4 Firewalls
+
+ [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings
+ of the Third Usenix Security Symposium, Baltimore, MD. September,
+ 1992.
+
+ [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet
+ Filtering", USSENIX: Proceedings of the Thrid UNIX Security
+ Symposium, Balimore, MD, September 1992.
+
+ [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building
+ Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.
+
+ [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker
+ is Lured, Endured, and Studied", AT&T Bell Laboratories.
+
+ [Cheswick2] W. Cheswick, "The Design of a Secure Internet Gateway",
+ Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.
+
+ [Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls
+ and Internet Security: Repelling the Wily Hacker", Addision-Wesley,
+ Reading, MA, 1994.
+
+ Landmark book on Firewalls. A must for anyone designing, installing,
+ managing firewalls.
+
+ [NCSA, 1995] NCSA, "NCSA Firewall Policy Guide", 1995.
+
+ [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96
+ Proceedings", 1996.
+
+ [Ranum, 1992] M. Ranum, "A Network Firewall", Digital Equipment
+ Corporation Washington Open Systems Resource Center, June 12, 1992.
+
+ [Ranum, 1992] M. Ranum, "An Internet Firwall", Proceedings of World
+ Conference on Systems Management and Security, 1992.
+
+ Available ftp://decuac.dec.com/pub/docs/firewall/firewall.ps
+
+ [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993.
+
+ A good start for those implementing or installing firewalls.
+ Available ftp://ftp.tis.com
+
+ [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and
+ Methods for Internet Firewalls", Trustest Information Systems, 1994.
+
+ Available ftp://ftp.tis.com
+
+ [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the
+
+
+
+Site Security Working Group [Page 73]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Firewall, and Other Applications Relays", Digital Equipment
+ Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993.
+
+ [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control,
+ and booby traps", Mathematics and Computing Science, Eindhoven
+ University of Technology, The Netherlands.
+
+ Available ftp://ftp.win.tue.nl/pub/security
+
+10.5 Internet Worms, Hackers, Computer Viruses, etc
+
+ [Barrett, 1996] D. Barrett, "Bandits on the Information
+ Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.
+
+ [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and
+ the Vulnerability of National Telecommunications Networks to Computer
+ Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.
+
+ Testimonial statement of Jack L. Brock, Director, U. S. Government
+ Information before the Subcommittee on Telecommunications and
+ Finance, Committee on Energy and
+ Commerce, House of Representatives.
+
+ [Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With
+ Microscope and Tweezers: An Analysis of the Internet Virus of
+ November 1988", Massachusetts Institute of Technology, February 1989.
+
+ Provides a detailed dissection of the worm program. The paper
+ discusses the major points of the worm program then reviews
+ strategies, chronology, lessons and open issues, Acknowledgments;
+ also included are a detailed appendix on the worm program subroutine
+ by subroutine, an appendix on the cast of characters, and a reference
+ section.
+
+ [Eisenbery, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D.
+ Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell
+ University, 6 February 1989.
+
+ A Cornell University Report presented to the Provost of the
+ University on 6 February 1989 on the Internet Worm.
+
+ [Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The
+ Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.
+
+ [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer
+ Security - Virus Highlights Need for Improved Internet Management",
+ United States General Accounting Office, Washington, DC, 1989.
+
+ This 36 page report (GAO/IMTEC-89-57), by the U.S. Government
+ Accounting Office, describes the Internet worm and its effects. It
+ gives a good overview of the various U.S. agencies involved in the
+ Internet today and their concerns vis-a-vis computer security and
+ networking.
+
+
+
+
+Site Security Working Group [Page 74]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Available on-line on host nnsc.nsf.net, directory pub, filename
+ GAO_RPT; and on nis.nsf.net, directory nsfnet, filename GAO_RPT.TXT.
+
+ [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True
+ Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell
+ Publishing, 328pp, 1996.
+
+ [Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk:
+ Outlaws and Hackers on the Computer Frontier", Touchstone, Simon &
+ Schuster, 1991.
+
+ [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The
+ Ongoing War Against Information Sabotage", M&T Books, 1994.
+
+ [IVPC, 1996] IVPC, "International Virus Prevention Conference '96
+ Proceedings", NCSA, 1996.
+
+ [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution",
+ Delta, 1984.
+
+ The Original.
+
+ [NCSA, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention Policy
+ Model", NCSA, 1995.
+
+ [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin
+ Mitnick", Little, Brown, Boston, MA. 333p, 1996.
+
+ [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135,
+ USC/Information Sciences Institute, Marina del Rey, CA, December
+ 1989.
+
+ This report looks back at the helminthiasis (infestation with, or
+ disease caused by parasitic worms) of the Internet that was unleashed
+ the evening of 2 November 1988. This document provides a glimpse at
+ the infection,its festering, and cure. The impact of the worm on the
+ Internet community, ethics statements, the role of the news media,
+ crime in the computer world, and future prevention is discussed. A
+ documentation review presents four publications that describe in
+ detail this particular parasitic computer program. Reference and
+ bibliography sections are also included. Available on-line on host
+ ftp.nisc.sri.com directory rfc, filename rfc1135.txt. Also available
+ on host nis.nsf.net, directory RFC, filename RFC1135.TXT-1.
+
+ [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989
+ Winter USENIX Conference, Usenix Association, San Diego, CA, February
+ 1989.
+
+ Details are presented as a "walk through" of this particular worm
+ program. The paper opened with an abstract, introduction, detailed
+ chronology of events upon the discovery of the worm, an overview, the
+ internals of the worm, personal opinions, and conclusion.
+
+ [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit
+
+
+
+Site Security Working Group [Page 75]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw-
+ by the Man Who Did It", Hyperion, 324p, 1996.
+
+ [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters
+ of Deception: The Gang that Ruled Cyberspace", Harper Collins
+ Publishers, 1995.
+
+ [Spafford, 1988] E. Spafford, "The Internet Worm Program: An
+ Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM,
+ January 1989. Also issued as Purdue CS Technical Report CSD-TR-823,
+ 28 November 1988.
+
+ Describes the infection of the Internet as a worm program that
+ exploited flaws in utility programs in UNIX based systems. The
+ report gives a detailed description of the components of the worm
+ program: data and functions. Spafford focuses his study on two
+ completely independent reverse-compilations of the worm and a version
+ disassembled to VAX assembly language.
+
+ [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm",
+ Proceedings of the European Software Engineering Conference 1989,
+ Warwick England, September 1989. Proceedings published by Springer-
+ Verlag as: Lecture Notes in Computer Science #387. Also issued as
+ Purdue Technical Report #CSD-TR-933.
+
+
+10.6 National Computer Security Center (NCSC)
+
+ All NCSC publications, approved for public release, are available
+ from the NCSC Superintendent of Documents.
+
+ NCSC =3D National Computer Security Center 9800 Savage Road Ft Meade,
+ MD 20755-6000
+
+ CSC =3D Computer Security Center: an older name for the NCSC
+
+ NTISS =3D National Telecommunications and Information Systems Security
+ NTISS Committee, National Security Agency Ft Meade, MD 20755-6000
+
+ [CSC-STD-002-85, 1985] Department of Defense, "Password Management
+ Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.
+
+ The security provided by a password system depends on the passwords
+ being kept secret at all times. Thus, a password is vulnerable to
+ compromise whenever it is used, stored, or even known. In a
+ password-based authentication mechanism implemented on an ADP system,
+ passwords are vulnerable to compromise due to five essential aspects
+ of the password system: 1) a password must be initially assigned to a
+ user when enrolled on the ADP system; 2) a user's password must be
+ changed periodically; 3) the ADP system must maintain a 'password
+ database'; 4) users must remember their passwords; and 5) users must
+ enter their passwords into the ADP system at authentication time.
+ This guideline prescribes steps to be taken to minimize the
+ vulnerability of passwords in each of these circumstances.
+
+
+
+Site Security Working Group [Page 76]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted
+ Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
+
+ Audit trails are used to detect and deter penetration of a computer
+ system and to reveal usage that identifies misuse. At the discretion
+ of the auditor, audit trails may be limited to specific events or may
+ encompass all of the activities on a system. Although not required
+ by the criteria, it should be possible for the target of the audit
+ mechanism to be either a subject or an object. That is to say, the
+ audit mechanism should be capable of monitoring every time John
+ accessed the system as well as every time the nuclear reactor file
+ was accessed; and likewise every time John accessed the nuclear
+ reactor file.
+
+ [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY
+ ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30
+ September 1987, 29 pages.
+
+ Discretionary control is the most common type of access control
+ mechanism implemented in computer systems today. The basis of this
+ kind of security is that an individual user, or program operating on
+ the user's behalf, is allowed to specify explicitly the types of
+ access other users (or programs executing on their behalf) may have
+ to information under the user's control. [...] Discretionary
+ controls are not a replacement for mandatory controls. In any
+ environment in which information is protected, discretionary security
+ provides for a finer granularity of control within the overall
+ constraints of the mandatory policy.
+
+ [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION
+ MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March
+ 1988, 31 pages.
+
+ Configuration management consists of four separate tasks:
+ identification, control, status accounting, and auditing. For every
+ change that is made to an automated data processing (ADP) system, the
+ design and requirements of the changed version of the system should
+ be identified. The control task of configuration management is
+ performed by subjecting every change to documentation, hardware, and
+ software/firmware to review and approval by an authorized authority.
+ Configuration status accounting is responsible for recording and
+ reporting on the configuration of the product throughout the change.
+ Finally, though the process of a configuration audit, the completed
+ change can be verified to be functionally correct, and for trusted
+ systems, consistent with the security policy of the system.
+
+ [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation
+ Security Guideline", NTISSAM CONPUSEC/1-87, 16 January 1987, 58
+ pages.
+
+ This document provides guidance to users, managers, security
+ officers, and procurement officers of Office Automation Systems.
+ Areas addressed include: physical security, personnel security,
+ procedural security, hardware/software security, emanations security
+
+
+
+Site Security Working Group [Page 77]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ (TEMPEST), and communications security for stand-alone OA Systems, OA
+ Systems used as terminals connected to mainframe computer systems,
+ and OA Systems used as hosts in a Local Area Network (LAN).
+ Differentiation is made between those Office Automation Systems
+ equipped with removable storage media only (e.g., floppy disks,
+ cassette tapes, removable hard disks) and those Office Automation
+ Systems equipped with fixed media (e.g., Winchester disks).
+
+ Additional NCSC Publications:
+
+ [NCSC-TG-004, 1988] National Computer Security Center, "Glossary of
+ Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
+
+ [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted
+ Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-
+ 83, NCSC, December 1985.
+
+ [NCSC-CSC-STD-003-85, 1985] National Computer Security Center,
+ "Guidance for Applying the Department of Defense Trusted Computer
+ System Evaluation Criteria in Specific Environments", CSC-STD-003-85,
+ NCSC, 25 June 1985.
+
+ [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical
+ Rationale Behind CSC-STD-003-85: Computer Security Requirements",
+ CSC-STD-004-85, NCSC, 25 June 1985.
+
+ [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic
+ Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November
+ 1985.
+
+ This guideline is tagged as a "For Official Use Only" exemption under
+ Section 6, Public Law 86-36 (50 U.S. Code 402). Distribution
+ authorized of U.S. Government agencies and their contractors to
+ protect unclassified technical, operational, or administrative data
+ relating to operations of the National Security Agency.
+
+ [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines
+ for Formal Verification Systems", Shipping list no.: 89-660-P, The
+ Center, Fort George G. Meade, MD, 1 April 1990.
+
+ [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of
+ Computer Security Terms", Shipping list no.: 89-254-P, The Center,
+ Fort George G. Meade, MD, 21 October 1988.
+
+ [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX
+ Working Group (TRUSIX) rationale for selecting access control list
+ features for the UNIX system", Shipping list no.: 90-076-P, The
+ Center, Fort George G. Meade, MD, 1990.
+
+ [NCSC-TG-005, 1987] National Computer Security Center, "Trusted
+ Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
+
+ [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention,
+ Detection, and Treatment", National Computer Security Center C1
+
+
+
+Site Security Working Group [Page 78]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ Technical Report C1-001-89, June 1989.
+
+ [NCSC Conference, 1989] National Computer Security Conference, "12th
+ National Computer Security Conference: Baltimore Convention Center,
+ Baltimore, MD, 10-13 October, 1989: Information Systems Security,
+ Solutions for Today - Concepts for Tomorrow", National Institute of
+ Standards and National Computer Security Center, 1989.
+
+
+10.7 Security Checklists
+
+ [Aucion, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery",
+ Computers in Libraries, Vol. 9, No. 2, Pg. 4, 1 February 1989.
+
+ [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V.
+ Hampel, and H. Sartorio, "Computer Security: A Comprehensive
+ Controls Checklist", John Wiley and Sons, Interscience Publication,
+ 1987.
+
+10.8 Disaster Recovery
+
+ [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks,
+ Telecommunications and Data Communications", McGraw-Hill, 1992.
+
+ [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems
+ Audit Group, 1996.
+
+ [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for
+ Telecommunications Networks and LANS", Artech House, 1993.
+
+10.9 Additional Publications
+
+10.9.1 Defense Data Network's Network Information Center (DDN NIC)
+
+ The DDN NIC maintains DDN Security bulletins and DDN Management
+ bulletins online on the machine: NIC.DDN.MIL. They are available via
+ anonymous FTP. The DDN Security bulletins are in the directory: SCC,
+ and the DDN Management bulletins are in the directory: DDN-NEWS.
+
+ For additional information, you may send a message to:
+ NIC@NIC.DDN.MIL, or call the DDN NIC at: 1-800-235-3155.
+
+ [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem
+ Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3
+ November 1988.
+
+ A Defense Data Network Management Bulletin announcement on the 4.2bsd
+ and 4.3bsd software fixes to the Internet worm.
+
+ [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin
+ 03", DDN Security Coordination Center, 17 October 1989.
+
+10.9.2 IEEE Proceedings
+
+
+
+
+Site Security Working Group [Page 79]
+
+
+
+
+
+Internet Draft Site Security Handbook May 1996
+
+
+ [IEEE] "Proceedings of the IEEE Symposium on Security and Privacy",
+ published annually.
+
+ IEEE Proceedings are available from:
+
+ Computer Society of the IEEE P.O. Box 80452 Worldway Postal Center
+ Los Angeles, CA 90080
+
+10.9.3 Other Publications:
+
+ Computer Law and Tax Report Computers and Security Security
+ Management Magazine Journal of Information Systems Management Data
+ Processing & Communications Security SIG Security, Audit & Control
+ Review
+
+ Editor Information
+
+ Barbara Y. Fraser
+ Software Engineering Institute
+ Carnegie Mellon University
+ 5000 Forbes Avenue
+ Pittsburgh, PA 15213
+
+ Phone: (412) 268-5010
+ Fax: (412) 268-6989
+ email: byf@cert.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Site Security Working Group [Page 80]
+
+
--- /dev/null
+
+
+
+
+draft-ietf-userglos-glossary2-01.txt G. Malkin / Xylogics, Inc.
+Obsoletes RFC 1392 (FYI 18) May 1996
+
+ Internet Users' Glossary
+
+
+Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ To learn the current status of any Internet-Draft, please check the
+ "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+ Directories on ds.internic.net (US East Coast), nic.nordu.net
+ (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+ Rim).
+
+
+Abstract
+
+ There are many networking glossaries in existence. This glossary
+ concentrates on terms which are specific to the Internet. Naturally,
+ there are entries for some basic terms and acronyms because other
+ entries refer to them.
+
+
+Acknowledgements
+
+ This document is the work of the User Glossary Working Group of the
+ User Services Area of the Internet Engineering Task Force. I would
+ especially like to thank Ryan Moats/InterNIC for his careful review
+ and many contributions to this document.
+
+
+Table of Contents
+
+ non-letter . . 3 I . . . . . . . 26 R . . . . . . . 46
+ A . . . . . . . 3 J . . . . . . . 33 S . . . . . . . 49
+ B . . . . . . . 8 K . . . . . . . 33 T . . . . . . . 52
+ C . . . . . . . 11 L . . . . . . . 33 U . . . . . . . 55
+ D . . . . . . . 15 M . . . . . . . 35 V . . . . . . . 57
+
+
+
+Malkin Expires: 2Nov96 [Page 1]
+\f
+Internet Draft Glossary May 1996
+
+
+ E . . . . . . . 18 N . . . . . . . 39 W . . . . . . . 57
+ F . . . . . . . 20 O . . . . . . . 43 X . . . . . . . 59
+ G . . . . . . . 23 P . . . . . . . 43 Y . . . . . . . 60
+ H . . . . . . . 24 Q . . . . . . . 46 Z . . . . . . . 60
+
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
+ Security Considerations . . . . . . . . . . . . . . . . . . . . 62
+ Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 62
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 2]
+\f
+Internet Draft Glossary May 1996
+
+
+Glossary
+
+ 10Base2
+ A physical layer communications specification for 10Mbps, baseband
+ data transmission over a coaxial cable (Thinnet) with a maximum
+ cable segment length of 200 meters.
+
+ 10Base5
+ A physical layer communications specification for 10Mbps, baseband
+ data transmission over a coaxial cable (Thicknet) with a maximum
+ cable segment length of 500 meters.
+
+ 10BaseF
+ A physical layer communications specification for 10Mbps, baseband
+ data transmission over a fiber-optic cable.
+
+ 10BaseT
+ A physical layer communications specification for 10Mbps, baseband
+ data transmission over a twisted-pair copper wire.
+
+ 802.x
+ The set of IEEE standards for the definition of LAN protocols.
+ See also: IEEE.
+
+ 822
+ See: RFC 822
+
+ :-)
+ This odd symbol is one of the ways a person can portray "mood" in
+ the very flat medium of computers--by using "smiley faces". This
+ is "metacommunication", and there are literally hundreds of such
+ symbols, from the obvious to the obscure. This particular example
+ expresses "happiness". Don't see it? Tilt your head to the left
+ 90 degrees. Smiles are also used to denote sarcasm.
+ [Source: ZEN]
+
+ abstract syntax
+ A description of a data structure that is independent of machine-
+ oriented structures and encodings.
+ [Source: RFC1208]
+
+ Abstract Syntax Notation One (ASN.1)
+ The language used by the OSI protocols for describing abstract
+ syntax. This language is also used to encode SNMP packets. ASN.1
+ is defined in ISO documents 8824.2 and 8825.2. See also: Basic
+ Encoding Rules.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 3]
+\f
+Internet Draft Glossary May 1996
+
+
+ Acceptable Use Policy (AUP)
+ Many transit networks have policies which restrict the use to
+ which the network may be put. For example, some networks may only
+ be used for non-commercial purposes. Some AUPs limit the type of
+ material which can be made available to the public (e.g.,
+ pornographic material). Enforcement of AUPs varies with the
+ network. See also: netiquette.
+
+ Access Control List (ACL)
+ Most network security systems operate by allowing selective use of
+ services. An Access Control List is the usual means by which
+ access to, and denial of, services is controlled. It is simply a
+ list of the services available, each with a list of the hosts
+ permitted to use the service.
+
+ ACK
+ See: Acknowledgment
+
+ acknowledgment (ACK)
+ A type of message sent to indicate that a block of data arrived at
+ its destination without error. See also: Negative
+ Acknowledgement.
+ [Source: NNSC]
+
+ ACL
+ See: Access Control List
+
+ AD
+ See: Administrative Domain
+
+ address
+ There are four types of addresses in common use within the
+ Internet. They are email address; IP, internet or Internet
+ address; hardware or MAC address; and URL. See also: email
+ address, IP address, internet address, MAC address, Uniform
+ Resource Locator.
+
+ address mask
+ A bit mask used to identify which bits in an IP address correspond
+ to the network and subnet portions of the address. This mask is
+ often referred to as the subnet mask because the network portion
+ of the address (i.e., the network mask) can be determined by the
+ encoding inherent in an IP address. See also: Classless Inter-
+ domain Routing.
+
+ address resolution
+ Conversion of a network-layer address (e.g. IP address) into the
+ corresponding physical address (e.g., MAC address). See also: IP
+
+
+
+Malkin Expires: 2Nov96 [Page 4]
+\f
+Internet Draft Glossary May 1996
+
+
+ address, MAC address.
+
+ Address Resolution Protocol (ARP)
+ Used to dynamically discover the low level physical network
+ hardware address that corresponds to the high level IP address for
+ a given host. ARP is limited to physical network systems that
+ support broadcast packets that can be heard by all hosts on the
+ network. See also: proxy ARP, Reverse Address Resolution
+ Protocol.
+
+ Administrative Domain (AD)
+ A collection of hosts and routers, and the interconnecting
+ network(s), managed by a single administrative authority.
+
+ Advanced Research Projects Agency (ARPA)
+ An agency of the U.S. Department of Defense responsible for the
+ development of new technology for use by the military. ARPA
+ (formerly known as DARPA, nee ARPA) was responsible for funding
+ much of the development of the Internet we know today, including
+ the Berkeley version of Unix and TCP/IP.
+ [Source: NNSC]
+
+ Advanced Research Projects Agency Network (ARPANET)
+ A pioneering longhaul network funded by ARPA. Now retired, it
+ served as the basis for early networking research as well as a
+ central backbone during the development of the Internet. The
+ ARPANET consisted of individual packet switching computers
+ interconnected by leased lines. See also: Advanced Research
+ Projects Agency.
+ [Source: FYI4]
+
+ agent
+ In the client-server model, the part of the system that performs
+ information preparation and exchange on behalf of a client or
+ server application.
+ [Source: RFC1208]
+
+ alias
+ A name, usually short and easy to remember, that is translated
+ into another name, usually long and difficult to remember.
+
+ American National Standards Institute (ANSI)
+ This organization is responsible for approving U.S. standards in
+ many areas, including computers and communications. Standards
+ approved by this organization are often called ANSI standards
+ (e.g., ANSI C is the version of the C language approved by ANSI).
+ ANSI is a member of ISO. See also: International Organization for
+ Standardization.
+
+
+
+Malkin Expires: 2Nov96 [Page 5]
+\f
+Internet Draft Glossary May 1996
+
+
+ [Source: NNSC]
+
+ American Standard Code for Information Interchange (ASCII)
+ A standard character-to-number encoding widely used in the
+ computer industry. See also: EBCDIC.
+
+ anonymous FTP
+ Anonymous FTP allows a user to retrieve documents, files,
+ programs, and other archived data from anywhere in the Internet
+ without having to establish a userid and password. By using the
+ special userid of "anonymous" the network user will bypass local
+ security checks and will have access to publicly accessible files
+ on the remote system. See also: archive site, File Transfer
+ Protocol, World Wide Web.
+
+ ANSI
+ See: American National Standards Institute
+
+ API
+ See: Application Program Interface
+
+ Appletalk
+ A networking protocol developed by Apple Computer for
+ communication between Apple Computer products and other computers.
+ This protocol is independent of the network layer on which it is
+ run. Current implementations exist for Localtalk, a 235Kb/s local
+ area network; and Ethertalk, a 10Mb/s local area network.
+ [Source: NNSC]
+
+ application
+ A program that performs a function directly for a user. FTP, mail
+ and Telnet clients are examples of network applications.
+
+ application layer
+ The top layer of the network protocol stack. The application
+ layer is concerned with the semantics of work (e.g. formatting
+ electronic mail messages). How to represent that data and how to
+ reach the foreign node are issues for lower layers of the network.
+ [Source: MALAMUD]
+
+ Application Program Interface (API)
+ A set of calling conventions which define how a service is invoked
+ through a software package.
+ [Source: RFC1208]
+
+ archie
+ A system to automatically gather, index and serve information on
+ the Internet. The initial implementation of archie provided an
+
+
+
+Malkin Expires: 2Nov96 [Page 6]
+\f
+Internet Draft Glossary May 1996
+
+
+ indexed directory of filenames from all anonymous FTP archives on
+ the Internet. Later versions provide other collections of
+ information. See also: archive site, Gopher, Prospero, Wide Area
+ Information Servers.
+
+ archive site
+ A machine that provides access to a collection of files across the
+ Internet. For example, an anonymous FTP archive site provides
+ access to arcived material via the FTP protocol. WWW servers can
+ also serve as archive sites. See also: anonymous FTP, archie,
+ Gopher, Prospero, Wide Area Information Servers, World Wide Web.
+
+ ARP
+ See: Address Resolution Protocol
+
+ ARPA
+ See: Advanced Research Projects Agency
+
+ ARPANET
+ See: Advanced Research Projects Agency Network
+
+ AS
+ See: Autonomous System
+
+ ASCII
+ See: American Standard Code for Information Interchange
+
+ ASN.1
+ See: Abstract Syntax Notation One
+
+ assigned numbers
+ The RFC [STD2] which documents the currently assigned values from
+ several series of numbers used in network protocol
+ implementations. This RFC is updated periodically and, in any
+ case, current information can be obtained from the Internet
+ Assigned Numbers Authority (IANA). If you are developing a
+ protocol or application that will require the use of a link,
+ socket, port, protocol, etc., please contact the IANA to receive a
+ number assignment. See also: Internet Assigned Numbers Authority,
+ STD.
+ [Source: STD2]
+
+ Asynchronous Transfer Mode (ATM)
+ A standard which defines high-load, high-speed (1.544Mbps through
+ 1.2Gbps), fixed-size packet (cell) switching with dynamic
+ bandwidth allocation. ATM is also known as "fast packet."
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 7]
+\f
+Internet Draft Glossary May 1996
+
+
+ ATM
+ See: Asynchronous Transfer Mode
+
+ AUP
+ See: Acceptable Use Policy
+
+ authentication
+ The verification of the identity of a person or process.
+ [Source: MALAMUD]
+
+ Autonomous System (AS)
+ A collection of routers under a single administrative authority
+ using a common Interior Gateway Protocol for routing packets.
+
+ backbone
+ The top level in a hierarchical network. Stub and transit
+ networks which connect to the same backbone are guaranteed to be
+ interconnected. See also: stub network, transit network.
+
+ bandwidth
+ Technically, the difference, in Hertz (Hz), between the highest
+ and lowest frequencies of a transmission channel. However, as
+ typically used, the amount of data that can be sent through a
+ given communications circuit.
+
+ bang path
+ A series of machine names used to direct electronic mail from one
+ user to another, typically by specifying an explicit UUCP path
+ through which the mail is to be routed. See also: email address,
+ mail path, UNIX-to-UNIX CoPy.
+
+ baseband
+ A transmission medium through which digital signals are sent
+ without complicated frequency shifting. In general, only one
+ communication channel is available at any given time. Ethernet is
+ an example of a baseband network. See also: broadband, Ethernet.
+ [Source: NNSC]
+
+ Basic Encoding Rules (BER)
+ Standard rules for encoding data units described in ASN.1.
+ Sometimes incorrectly lumped under the term ASN.1, which properly
+ refers only to the abstract syntax description language, not the
+ encoding technique. See also: Abstract Syntax Notation One.
+ [Source: NNSC]
+
+ BBS
+ See: Bulletin Board System
+
+
+
+
+Malkin Expires: 2Nov96 [Page 8]
+\f
+Internet Draft Glossary May 1996
+
+
+ BCNU
+ Be Seein' You
+
+ BCP
+ The newest subseries of RFCs which are written to describe Best
+ Current Practices in the Internet. Rather than specifying a
+ protocol, these documents specify the best ways to use the
+ protocols and the best ways to configure options to ensure
+ interoperability between various vendors' products. BCPs carry
+ the endorsement of the IESG. See also: Request For Comments,
+ Internet Engineering Steering Group.
+
+ BER
+ See: Basic Encoding Rules
+
+ Berkeley Internet Name Domain (BIND)
+ Implementation of a DNS server developed and distributed by the
+ University of California at Berkeley. Many Internet hosts run
+ BIND, and it is the ancestor of many commercial BIND
+ implementations. See also: Domain Name System.
+
+ Berkeley Software Distribution (BSD)
+ Implementation of the UNIX operating system and its utilities
+ developed and distributed by the University of California at
+ Berkeley. "BSD" is usually preceded by the version number of the
+ distribution, e.g., "4.3 BSD" is version 4.3 of the Berkeley UNIX
+ distribution. Many Internet hosts run BSD software, and it is the
+ ancestor of many commercial UNIX implementations.
+ [Source: NNSC]
+
+ BGP
+ See: Border Gateway Protocol
+
+ big-endian
+ A format for storage or transmission of binary data in which the
+ most significant bit (or byte) comes first. The term comes from
+ "Gulliver's Travels" by Jonathan Swift. The Lilliputians, being
+ very small, had correspondingly small political problems. The
+ Big-Endian and Little-Endian parties debated over whether soft-
+ boiled eggs should be opened at the big end or the little end.
+ See also: little-endian.
+ [Source: RFC1208]
+
+ binary
+ 11001001
+
+ BIND
+ See: Berkeley Internet Name Domain
+
+
+
+Malkin Expires: 2Nov96 [Page 9]
+\f
+Internet Draft Glossary May 1996
+
+
+ Birds Of a Feather (BOF)
+ A Birds Of a Feather (flocking together) is an informal discussion
+ group. It is formed, often ad hoc, to consider a specific issue
+ and, therefore, has a narrow focus. See also: Working Group.
+
+ Bitnet
+ An academic computer network that provides interactive electronic
+ mail and file transfer services, using a store-and-forward
+ protocol, based on IBM Network Job Entry protocols. Bitnet-II
+ encapsulates the Bitnet protocol within IP packets and depends on
+ the Internet to route them.
+
+ BOF
+ See: Birds Of a Feather
+
+ BOOTP
+ The Bootstrap Protocol, described in RFC 1542, is used for booting
+ diskless nodes. See also: Dynamic Host Configuration Protocol,
+ Reverse Address Resolution Protocol.
+
+ Border Gateway Protocol (BGP)
+ The Border Gateway Protocol is an exterior gateway protocol
+ defined in RFC 1771. It's design is based on experience gained
+ with EGP, as defined in RFC 904, and EGP usage in the NSFNET
+ Backbone, as described in RFCs 1092 and 1093. See also: Exterior
+ Gateway Protocol.
+
+ bounce
+ The return of a piece of mail because of an error in its delivery.
+ [Source: ZEN]
+
+ bridge
+ A device which forwards traffic between network segments based on
+ datalink layer information. These segments would have a common
+ network layer address. See also: gateway, router.
+
+ broadband
+ A transmission medium capable of supporting a wide range of
+ frequencies. It can carry multiple signals by dividing the total
+ capacity of the medium into multiple, independent bandwidth
+ channels, where each channel operates only on a specific range of
+ frequencies. See also: baseband.
+
+ broadcast
+ A special type of multicast packet which all nodes on the network
+ are always willing to receive. See also: multicast, unicast.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 10]
+\f
+Internet Draft Glossary May 1996
+
+
+ broadcast storm
+ An incorrect packet broadcast onto a network that causes multiple
+ hosts to respond all at once, typically with equally incorrect
+ packets which causes the storm to grow exponentially in severity.
+ See also: Ethernet meltdown.
+
+ brouter
+ A device which bridges some packets (i.e. forwards based on
+ datalink layer information) and routes other packets (i.e.
+ forwards based on network layer information). The bridge/route
+ decision is based on configuration information. See also: bridge,
+ router.
+
+ BSD
+ See: Berkeley Software Distribution
+
+ BTW
+ By The Way
+
+ Bulletin Board System (BBS)
+ A computer, and associated software, which typically provides
+ electronic messaging services, archives of files, and any other
+ services or activities of interest to the bulletin board system's
+ operator. Although BBS's have traditionally been the domain of
+ hobbyists, an increasing number of BBS's are connected directly to
+ the Internet, and many BBS's are currently operated by government,
+ educational, and research institutions. See also: Electronic
+ Mail, Internet, Usenet.
+ [Source: NWNET]
+
+ Campus Wide Information System (CWIS)
+ A CWIS makes information and services publicly available on campus
+ via kiosks, and makes interactive computing available via kiosks,
+ interactive computing systems and campus networks. Services
+ routinely include directory information, calendars, bulletin
+ boards, databases.
+
+ CCIRN
+ See: Coordinating Committee for Intercontinental Research Networks
+
+ CCITT
+ See: Comite Consultatif International de Telegraphique et
+ Telephonique
+
+ CERT
+ See: Computer Emergency Response Team
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 11]
+\f
+Internet Draft Glossary May 1996
+
+
+ checksum
+ A computed value which is dependent upon the contents of a packet.
+ This value is sent along with the packet when it is transmitted.
+ The receiving system computes a new checksum based upon the
+ received data and compares this value with the one sent with the
+ packet. If the two values are the same, the receiver has a high
+ degree of confidence that the data was received correctly. See
+ also: Cyclic Redundancy Check.
+ [Source: NNSC]
+
+ CIDR
+ See: Classless Inter-domain Routing
+
+ circuit switching
+ A communications paradigm in which a dedicated communication path
+ is established between two hosts, and on which all packets travel.
+ The telephone system is an example of a circuit switched network.
+ See also: connection-oriented, connectionless, packet switching.
+
+ Classless Inter-domain Routing (CIDR)
+ A proposal, set forth in RFC 1519, to allocate IP addresses so as
+ to allow the addresses to be aggregated when advertised as routes.
+ It is based on the elimination of intrinsic IP network addresses;
+ that is, the determination of the network address based on the
+ first few bits of the IP address. See also: IP address, network
+ address, supernet.
+
+ client
+ A computer system or process that requests a service of another
+ computer system or process. A workstation requesting the contents
+ of a file from a file server is a client of the file server. See
+ also: client-server model, server.
+ [Source: NNSC]
+
+ client-server model
+ A common way to describe the paradigm of many network protocols.
+ Examples include the name-server/name-resolver relationship in DNS
+ and the file-server/file-client relationship in NFS. See also:
+ client, server, Domain Name System, Network File System.
+
+ CNI
+ See: Coalition for Networked Information
+
+ Coalition for Networked Information (CNI)
+ A consortium formed by American Research Libraries, CAUSE, and
+ EDUCOM (no, they are not acronyms) to promote the creation of, and
+ access to, information resources in networked environments in
+ order to enrich scholarship and enhance intellectual productivity.
+
+
+
+Malkin Expires: 2Nov96 [Page 12]
+\f
+Internet Draft Glossary May 1996
+
+
+ Comite Consultatif International de Telegraphique et Telephonique (
+ CCITT)
+ This organization is now part of the International
+ Telecommunications Union and is responsible for making technical
+ recommendations about telephone and data communications systems.
+ Every four years CCITT holds plenary sessions where they adopt new
+ standards; the most recent was in 1992. Recently, the ITU
+ reorganized and CCITT was renamed the ITU-TSS. See also:
+ International Telecommunications Union - Telecommunications
+ Standards Sector.
+
+ Computer Emergency Response Team (CERT)
+ The CERT was formed by ARPA in November 1988 in response to the
+ needs exhibited during the Internet worm incident. The CERT
+ charter is to work with the Internet community to facilitate its
+ response to computer security events involving Internet hosts, to
+ take proactive steps to raise the community's awareness of
+ computer security issues, and to conduct research targeted at
+ improving the security of existing systems. CERT products and
+ services include 24-hour technical assistance for responding to
+ computer security incidents, product vulnerability assistance,
+ technical documents, and tutorials. In addition, the team
+ maintains a number of mailing lists (including one for CERT
+ Advisories), and provides an anonymous FTP server, at "cert.org",
+ where security-related documents and tools are archived. The CERT
+ may be reached by email at "cert@cert.org" and by telephone at
+ +1-412-268-7090 (24-hour hotline). See also: Advanced Research
+ Projects Agency, worm.
+
+ congestion
+ Congestion occurs when the offered load exceeds the capacity of a
+ data communication path.
+
+ connection-oriented
+ The data communication method in which communication proceeds
+ through three well-defined phases: connection establishment, data
+ transfer, connection release. TCP is a connection-oriented
+ protocol. See also: circuit switching, connectionless, packet
+ switching, Transmission Control Protocol.
+
+ connectionless
+ The data communication method in which communication occurs
+ between hosts with no previous setup. Packets between two hosts
+ may take different routes, as each is independent of the other.
+ UDP is a connectionless protocol. See also: circuit switching,
+ connection-oriented, packet switching, User Datagram Protocol.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 13]
+\f
+Internet Draft Glossary May 1996
+
+
+ Coordinating Committee for Intercontinental Research Networks (CCIRN)
+ A committee that includes the United States FNC and its
+ counterparts in North America and Europe. Co-chaired by the
+ executive directors of the FNC and the European Association of
+ Research Networks (RARE), the CCIRN provides a forum for
+ cooperative planning among the principal North American and
+ European research networking bodies. See also: Federal Networking
+ Council, RARE.
+ [Source: MALAMUD]
+
+ core gateway
+ Historically, one of a set of gateways (routers) operated by the
+ Internet Network Operations Center at Bolt, Beranek and Newman
+ (BBN). The core gateway system formed a central part of Internet
+ routing in that all groups must advertise paths to their networks
+ from a core gateway.
+ [Source: MALAMUD]
+
+ Corporation for Research and Educational Networking (CREN)
+ This organization was formed in October 1989, when Bitnet and
+ CSNET (Computer + Science NETwork) were combined under one
+ administrative authority. CSNET is no longer operational, but
+ CREN still runs Bitnet. See also: Bitnet.
+ [Source: NNSC]
+
+ cracker
+ A cracker is an individual who attempts to access computer systems
+ without authorization. These individuals are often malicious, as
+ opposed to hackers, and have many means at their disposal for
+ breaking into a system. See also: hacker, Computer Emergency
+ Response Team, Trojan Horse, virus, worm.
+
+ CRC
+ See: cyclic redundancy check
+
+ CREN
+ See: Corporation for Research and Educational Networking
+
+ CU-SeeMe
+ Pronnounced "See you, See me," CU-SeeMe is a publicly available
+ videoconferencing program developed at Cornell University. It
+ allows anyone with audio/video capabilites and an Internet
+ connection to videoconference with anyone else with the same
+ capabilities. It also allows multiple people to tie into the same
+ videoconference.
+
+ CWIS
+ See: Campus Wide Information system
+
+
+
+Malkin Expires: 2Nov96 [Page 14]
+\f
+Internet Draft Glossary May 1996
+
+
+ Cyberspace
+ A term coined by William Gibson in his fantasy novel Neuromancer
+ to describe the "world" of computers, and the society that gathers
+ around them.
+ [Source: ZEN]
+
+ Cyclic Redundancy Check (CRC)
+ A number derived from a set of data that will be transmitted. By
+ recalculating the CRC at the remote end and comparing it to the
+ value originally transmitted, the receiving node can detect some
+ types of transmission errors. See also: checksum.
+ [Source: MALAMUD]
+
+ DANTE
+ A non-profit company founded in July 1993 to help the European
+ research community enhance their networking facilities. It
+ focuses on the establishment of a high-speed computer network
+ infrastructure.
+
+ DARPA
+ Defense Advanced Research Projects Agency
+ See: Advanced Research Projects Agency
+
+ Data Encryption Key (DEK)
+ Used for the encryption of message text and for the computation of
+ message integrity checks (signatures). See also: encryption.
+
+ Data Encryption Standard (DES)
+ A popular, standard encryption scheme. See also: encryption,
+ Pretty Good Privacy, RSA.
+
+ datagram
+ A self-contained, independent entity of data carrying sufficient
+ information to be routed from the source to the destination
+ computer without reliance on earlier exchanges between this source
+ and destination computer and the transporting network. See also:
+ frame, packet.
+ [Source: J. Postel]
+
+ DCA
+ See: Defense Information Systems Agency
+
+ DCE
+ Data Circuit-terminating Equipment
+
+ DCE
+ See: Distributed Computing Environment
+
+
+
+
+Malkin Expires: 2Nov96 [Page 15]
+\f
+Internet Draft Glossary May 1996
+
+
+ DDN
+ See: Defense Data Network
+
+ DDN NIC
+ See: Defense Data Network Network Information Center
+
+ DECnet
+ A proprietary network protocol designed by Digital Equipment
+ Corporation. The functionality of each Phase of the
+ implementation, such as Phase IV and Phase V, is different.
+
+ default route
+ A routing table entry which is used to direct packets addressed to
+ networks not explicitly listed in the routing table.
+ [Source: MALAMUD]
+
+ Defense Data Network (DDN)
+ A global communications network serving the US Department of
+ Defense composed of MILNET, other portions of the Internet, and
+ classified networks which are not part of the Internet. The DDN
+ is used to connect military installations and is managed by the
+ Defense Information Systems Agency. See also: Defense Information
+ Systems Agency.
+
+ Defense Data Network Network Information Center (DDN NIC)
+ Previously called "The NIC", the DDN NIC's primary responsibility
+ was the assignment of Internet network addresses and Autonomous
+ System numbers, the administration of the root domain, and
+ providing information and support services to the Internet for the
+ DDN. Since the creation of the InterNIC, the DDN NIC performs
+ these functions only for the DDN. See also: Autonomous System,
+ network address, Internet Registry, InterNIC, Network Information
+ Center, Request For Comments.
+
+ Defense Information Systems Agency (DISA)
+ Formerly called the Defense Communications Agency (DCA), this is
+ the government agency responsible for managing the DDN portion of
+ the Internet, including the MILNET. Currently, DISA administers
+ the DDN, and supports the user assistance services of the DDN NIC.
+ See also: Defense Data Network.
+
+ DEK
+ See: Data Encryption Key
+
+ DES
+ See: Data Encryption Standard
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 16]
+\f
+Internet Draft Glossary May 1996
+
+
+ dialup
+ A temporary, as opposed to dedicated, connection between machines
+ established over a phone line (analog or ISDN). See also:
+ Integrated Services Digital Network.
+
+ Directory Access Protocol
+ X.500 protocol used for communication between a Directory User
+ Agent and a Directory System Agent.
+ [Source: MALAMUD]
+
+ Directory System Agent (DSA)
+ The software that provides the X.500 Directory Service for a
+ portion of the directory information base. Generally, each DSA is
+ responsible for the directory information for a single
+ organization or organizational unit.
+ [Source: RFC1208]
+
+ Directory User Agent (DUA)
+ The software that accesses the X.500 Directory Service on behalf
+ of the directory user. The directory user may be a person or
+ another software element.
+ [Source: RFC1208]
+
+ DISA
+ See: Defense Information Systems Agency
+
+ Distributed Computing Environment (DCE)
+ An architecture of standard programming interfaces, conventions,
+ and server functionalities (e.g., naming, distributed file system,
+ remote procedure call) for distributing applications transparently
+ across networks of heterogeneous computers. Promoted and
+ controlled by the Open Software Foundation (OSF), a consortium led
+ by Digital, IBM and Hewlett Packard.
+ [Source: RFC1208]
+
+ distributed database
+ A collection of several different data repositories that looks
+ like a single database to the user. A prime example in the
+ Internet is the Domain Name System.
+
+ DIX Ethernet
+ See: Ethernet
+
+ DNS
+ See: Domain Name System
+
+ domain
+ "Domain" is a heavily overused term in the Internet. It can be
+
+
+
+Malkin Expires: 2Nov96 [Page 17]
+\f
+Internet Draft Glossary May 1996
+
+
+ used in the Administrative Domain context, or the Domain Name
+ context. See also: Administrative Domain, Domain Name System.
+
+ Domain Name System (DNS)
+ The DNS is a general purpose distributed, replicated, data query
+ service. The principal use is the lookup of host IP addresses
+ based on host names. The style of host names now used in the
+ Internet is called "domain name", because they are the style of
+ names used to look up anything in the DNS. Some important domains
+ are: .COM (commercial), .EDU (educational), .NET (network
+ operations), .GOV (U.S. government), and .MIL (U.S. military).
+ Most countries also have a domain. The country domain names are
+ based on ISO 3166. For example, .US (United States), .UK (United
+ Kingdom), .AU (Australia). See also: Fully Qualified Domain Name,
+ Mail Exchange Record.
+
+ dot address (dotted decimal notation)
+ Dot address refers to the common notation for IP addresses of the
+ form A.B.C.D; where each letter represents, in decimal, one byte
+ of a four byte IP address. See also: IP address.
+ [Source: FYI4]
+
+ DSA
+ See: Directory System Agent
+
+ DTE
+ Data Terminal Equipment
+
+ DUA
+ See: Directory User Agent
+
+ dynamic adaptive routing
+ Automatic rerouting of traffic based on a sensing and analysis of
+ current actual network conditions. NOTE: this does not include
+ cases of routing decisions taken on predefined information.
+ [Source: J. Postel]
+
+ E1
+ The basic building block for European multi-megabit data rates,
+ with a bandwidth of 2.048Mbps. See also: T1.
+
+ E3
+ A European standard for transmitting data at 57.344Mbps. See
+ also: T3.
+
+ EARN
+ European Academic and Research Network. See: Trans-European
+ Research and Education Networking Association.
+
+
+
+Malkin Expires: 2Nov96 [Page 18]
+\f
+Internet Draft Glossary May 1996
+
+
+ EBCDIC
+ See: Extended Binary Coded Decimal Interchange Code
+
+ Ebone
+ A pan-European backbone service.
+
+ EFF
+ See: Electronic Frontier Foundation
+
+ EGP
+ See: Exterior Gateway Protocol
+
+ Electronic Frontier Foundation (EFF)
+ A foundation established to address social and legal issues
+ arising from the impact on society of the increasingly pervasive
+ use of computers as a means of communication and information
+ distribution.
+
+ Electronic Mail (email)
+ A system whereby a computer user can exchange messages with other
+ computer users (or groups of users) via a communications network.
+ Electronic mail is one of the most popular uses of the Internet.
+ [Source: NNSC]
+
+ email
+ See: Electronic mail
+
+ email address
+ The domain-based or UUCP address that is used to send electronic
+ mail to a specified destination. For example an editor's address
+ is "gmalkin@xylogics.com". See also: bang path, mail path, UNIX-
+ to-UNIX CoPy.
+ [Source: ZEN]
+
+ encapsulation
+ The technique used by layered protocols in which a layer adds
+ header information to the protocol data unit (PDU) from the layer
+ above. For example, in Internet terminology, a packet would
+ contain a header from the physical layer, followed by a header
+ from the datalink layer (e.g. Ethernet), followed by a header
+ from the network layer (IP), followed by a header from the
+ transport layer (e.g. TCP), followed by the application protocol
+ data.
+ [Source: RFC1208]
+
+ encryption
+ Encryption is the manipulation of a packet's data in order to
+ prevent any but the intended recipient from reading that data.
+
+
+
+Malkin Expires: 2Nov96 [Page 19]
+\f
+Internet Draft Glossary May 1996
+
+
+ There are many types of data encryption, and they are the basis of
+ network security. See also: Data Encryption Standard.
+
+ error checking
+ The examination of received data for transmission errors. See
+ also: checksum, Cyclic Redundancy Check.
+
+ Ethernet
+ A 10-Mb/s standard for LANs, initially developed by Xerox, and
+ later refined by Digital, Intel and Xerox (DIX). All hosts are
+ connected to a coaxial cable where they contend for network access
+ using a Carrier Sense Multiple Access with Collision Detection
+ (CSMA/CD) paradigm. See also: 802.x, Local Area Network, token
+ ring.
+
+ Ethernet meltdown
+ An event that causes saturation, or near saturation, on an
+ Ethernet. It usually results from illegal or misrouted packets
+ and typically lasts only a short time. See also: broadcast storm.
+ [Source: COMER]
+
+ Extended Binary Coded Decimal Interchange Code (EBCDIC)
+ A standard character-to-number encoding used primarily by IBM
+ computer systems. See also: ASCII.
+
+ Exterior Gateway Protocol (EGP)
+ A protocol which distributes routing information to the routers
+ which connect autonomous systems. The term "gateway" is
+ historical, as "router" is currently the preferred term. There is
+ also a routing protocol called EGP defined in RFC 904. See also:
+ Autonomous System, Border Gateway Protocol, Interior Gateway
+ Protocol.
+
+ eXternal Data Representation (XDR)
+ A standard for machine independent data structures developed by
+ Sun Microsystems and defined in RFCs 1014 and 1832. It is similar
+ to ASN.1. See also: Abstract Syntax Notation One.
+ [Source: RFC1208]
+
+ FARNET
+ A non-profit corporation, established in 1987, whose mission is to
+ advance the use of computer networks to improve research and
+ education.
+
+ FAQ
+ Frequently Asked Question
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 20]
+\f
+Internet Draft Glossary May 1996
+
+
+ FDDI
+ See: Fiber Distributed Data Interface
+
+ Federal Information Exchange (FIX)
+ One of the connection points between the American governmental
+ internets and the Internet.
+ [Source: SURA]
+
+ Federal Networking Council (FNC)
+ The coordinating group of representatives from those federal
+ agencies involved in the development and use of federal
+ networking, especially those networks using TCP/IP and the
+ Internet. Current members include representatives from DOD, DOE,
+ ARPA, NSF, NASA, and HHS. See also: Advanced Research Projects
+ Agency, National Science Foundation.
+
+ Fiber Distributed Data Interface (FDDI)
+ A high-speed (100Mb/s) LAN standard. The underlying medium is
+ fiber optics, and the topology is a dual-attached, counter-
+ rotating token ring. See also: Local Area Network, token ring.
+ [Source: RFC1208]
+
+ file transfer
+ The copying of a file from one computer to another over a computer
+ network. See also: File Transfer Protocol, Kermit, Gopher, World
+ Wide Web.
+
+ File Transfer Protocol (FTP)
+ A protocol which allows a user on one host to access, and transfer
+ files to and from, another host over a network. Also, FTP is
+ usually the name of the program the user invokes to execute the
+ protocol. See also: anonymous FTP.
+
+ finger
+ A protocol, defined in RFC 1288, that allows information about a
+ system or user on a system to be retrived. Finger also refers to
+ the commonly used program which retrieves this information.
+ Information about all logged in users, as well is information
+ about specific users may be retrieved from local or remote
+ systems. Some sites consider finger to be a security risk and
+ have either disabled it, or replaced it with a simple message.
+
+ FIX
+ See: Federal Information Exchange
+
+ flame
+ A strong opinion and/or criticism of something, usually as a frank
+ inflammatory statement, in an electronic mail message. It is
+
+
+
+Malkin Expires: 2Nov96 [Page 21]
+\f
+Internet Draft Glossary May 1996
+
+
+ common to precede a flame with an indication of pending fire (i.e.
+ FLAME ON!). Flame Wars occur when people start flaming other
+ people for flaming when they shouldn't have. See also: Electronic
+ Mail, Usenet.
+
+ FLEA
+ See: Four Letter Extended Acronym
+
+ FNC
+ See: Federal Networking Council
+
+ Four Letter Extended Acronym (FLEA)
+ A recognition of the fact that there are far too many TLAs. See
+ also: Three Letter Acronym.
+
+ FQDN
+ See: Fully Qualified Domain Name
+
+ fragment
+ A piece of a packet. When a router is forwarding an IP packet to
+ a network that has a maximum transmission unit smaller than the
+ packet size, it is forced to break up that packet into multiple
+ fragments. These fragments will be reassembled by the IP layer at
+ the destination host. See also: Maximum Transmission Unit.
+
+ fragmentation
+ The IP process in which a packet is broken into smaller pieces to
+ fit the requirements of a physical network over which the packet
+ must pass. See also: reassembly.
+
+ frame
+ A frame is a datalink layer "packet" which contains the header and
+ trailer information required by the physical medium. That is,
+ network layer packets are encapsulated to become frames. See
+ also: datagram, encapsulation, packet.
+
+ freenet
+ Community-based bulletin board system with email, information
+ services, interactive communications, and conferencing. Freenets
+ are funded and operated by individuals and volunteers -- in one
+ sense, like public television. They are part of the National
+ Public Telecomputing Network (NPTN), an organization based in
+ Cleveland, Ohio, devoted to making computer telecommunication and
+ networking services as freely available as public libraries.
+ [Source: LAQUEY]
+
+ FTP
+ See: File Transfer Protocol
+
+
+
+Malkin Expires: 2Nov96 [Page 22]
+\f
+Internet Draft Glossary May 1996
+
+
+ Fully Qualified Domain Name (FQDN)
+ The FQDN is the full name of a system, rather than just its
+ hostname. For example, "venera" is a hostname and
+ "venera.isi.edu" is an FQDN. See also: hostname, Domain Name
+ System.
+
+ FYI
+ For Your Information
+
+ FYI
+ A subseries of RFCs that are not technical standards or
+ descriptions of protocols. FYIs convey general information about
+ topics related to TCP/IP or the Internet. See also: Request For
+ Comments.
+
+ gated
+ Gatedaemon. A program which supports multiple routing protocols
+ and protocol families. It may be used for routing, and makes an
+ effective platform for routing protocol research. The software is
+ freely available by anonymous FTP from "gated.cornell.edu".
+ Pronounced "gate-dee". See also: Exterior Gateway Protocol, Open
+ Shortest-Path First, Routing Information Protocol, routed.
+
+ gateway
+ The term "router" is now used in place of the original definition
+ of "gateway". Currently, a gateway is a communications
+ device/program which passes data between networks having similar
+ functions but dissimilar implementations. This should not be
+ confused with a protocol converter. By this definition, a router
+ is a layer 3 (network layer) gateway, and a mail gateway is a
+ layer 7 (application layer) gateway. See also: mail gateway,
+ router, protocol converter.
+
+ Gopher
+ A distributed information service, developed at the University of
+ Minnesota, that makes hierarchical collections of information
+ available across the Internet. Gopher uses a simple protocol,
+ defined in RFC 1436, that allows a single Gopher client to access
+ information from any accessible Gopher server, providing the user
+ with a single "Gopher space" of information. Public domain
+ versions of the client and server are available. See also:
+ archie, archive site, Prospero, Wide Area Information Servers.
+
+ GOSIP
+ See: Government OSI Profile
+
+ Government OSI Profile (GOSIP)
+ A subset of OSI standards specific to U.S. Government
+
+
+
+Malkin Expires: 2Nov96 [Page 23]
+\f
+Internet Draft Glossary May 1996
+
+
+ procurements, designed to maximize interoperability in areas where
+ plain OSI standards are ambiguous or allow excessive options.
+
+ hacker
+ A person who delights in having an intimate understanding of the
+ internal workings of a system, computers and computer networks in
+ particular. The term is often misused in a pejorative context,
+ where "cracker" would be the correct term. See also: cracker.
+
+ header
+ The portion of a packet, preceding the actual data, containing
+ source and destination information. It may also error checking and
+ other fields. A header is also the part of an electronic mail
+ message which precedes the body of a message and contains, among
+ other things, the message originator, date and time. See also:
+ Electronic Mail, packet, error checking.
+
+ heterogeneous network
+ A network running multiple network layer protocols. See also:
+ DECnet, IP, IPX, XNS, homogeneous network.
+
+ hierarchical routing
+ The complex problem of routing on large networks can be simplified
+ by reducing the size of the networks. This is accomplished by
+ breaking a network into a hierarchy of networks, where each level
+ is responsible for its own routing. The Internet has, basically,
+ three levels: the backbones, the mid-levels, and the stub
+ networks. The backbones know how to route between the mid-levels,
+ the mid-levels know how to route between the sites, and each site
+ (being an autonomous system) knows how to route internally. See
+ also: Autonomous System, Exterior Gateway Protocol, Interior
+ Gateway Protocol, stub network, transit network.
+
+ High Performance Computing and Communications (HPCC)
+ High performance computing encompasses advanced computing,
+ communications, and information technologies, including scientific
+ workstations, supercomputer systems, high speed networks, special
+ purpose and experimental systems, the new generation of large
+ scale parallel systems, and application and systems software with
+ all components well integrated and linked over a high speed
+ network.
+ [Source: HPCC]
+
+ High Performance Parallel Interface (HIPPI)
+ An emerging ANSI standard which extends the computer bus over
+ fairly short distances at speeds of 800 and 1600 Mb/s. HIPPI is
+ often used in a computer room to connect a supercomputer to
+ routers, frame buffers, mass-storage peripherals, and other
+
+
+
+Malkin Expires: 2Nov96 [Page 24]
+\f
+Internet Draft Glossary May 1996
+
+
+ computers. See also: American National Standards Institute
+ [Source: MALAMUD]
+
+ HIPPI
+ See: High Performance Parallel Interface
+
+ HTML
+ See: Hypertext Markup Language
+
+ homogeneous network
+ A network running a single network layer protocol. See also:
+ DECnet, IP, IPX, XNS, heterogeneous network.
+
+ hop
+ A term used in routing. A path to a destination on a network is a
+ series of hops, through routers, away from the origin.
+
+ host
+ A computer that allows users to communicate with other host
+ computers on a network. Individual users communicate by using
+ application programs, such as electronic mail, Telnet and FTP.
+ [Source: NNSC]
+
+ host address
+ See: internet address
+
+ hostname
+ The name given to a machine. See also: Fully Qualified Domain
+ Name.
+ [Source: ZEN]
+
+ host number
+ See: host address
+
+ HPCC
+ See: High Performance Computing and Communications
+
+ HTTP
+ See: Hypertext Transfer Protocol
+
+ hub
+ A device connected to several other devices. In ARCnet, a hub is
+ used to connect several computers together. In a message handling
+ service, a hub is used for the transfer of messages across the
+ network.
+ [Source: MALAMUD]
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 25]
+\f
+Internet Draft Glossary May 1996
+
+
+ hyperlink
+ A pointer within a hypertext document which points (links) to
+ another document, which may or may not also be a hypertext
+ document. See also: hypertext.
+
+ hypertext
+ A document, written in HTML, which contains hyperlinks to other
+ documents, which may or may not also be hypertext documents.
+ Hypertext documents are usually retrieved using WWW. See also:
+ hyperlink, Hypertext Markup Language, World Wide Web.
+
+ Hypertext Markup Language (HTML)
+ The language used to create hypertext documents. It is a subset
+ of SGML and includes the mechanisms to establish hyperlinks to
+ other documents. See also: hypertext, hyperlink, Standardized
+ General Markup Language.
+
+ Hypertext Transfer Protocol (HTTP)
+ The protocol used by WWW to transfer HTML files. A formal
+ standard is still under development in the IETF. See also:
+ hyperlink, hypertext, Hypertext Markup Language, World Wide Web.
+
+ I-D
+ See: Internet-Draft
+
+ IAB
+ See: Internet Architecture Board
+
+ IANA
+ See: Internet Assigned Numbers Authority
+
+ ICMP
+ See: Internet Control Message Protocol
+
+ IEEE
+ Institute of Electrical and Electronics Engineers
+
+ IEEE 802
+ See: 802.x
+
+ IEN
+ See: Internet Experiment Note
+
+ IEPG
+ See: Internet Engineering Planning Group
+
+ IESG
+ See: Internet Engineering Steering Group
+
+
+
+Malkin Expires: 2Nov96 [Page 26]
+\f
+Internet Draft Glossary May 1996
+
+
+ IETF
+ See: Internet Engineering Task Force
+
+ IINREN
+ See: Interagency Interim National Research and Education Network
+
+ IGP
+ See: Interior Gateway Protocol
+
+ IMHO
+ In My Humble Opinion
+
+ IMR
+ See: Internet Monthly Report
+
+ Integrated Services Digital Network (ISDN)
+ An emerging technology which is beginning to be offered by the
+ telephone carriers of the world. ISDN combines voice and digital
+ network services in a single medium, making it possible to offer
+ customers digital data services as well as voice connections
+ through a single "wire." The standards that define ISDN are
+ specified by CCITT. See also: CCITT.
+ [Source: RFC1208]
+
+ Interagency Interim National Research and Education Network (IINREN)
+ An evolving operating network system. Near term (1992-1996)
+ research and development activities will provide for the smooth
+ evolution of this networking infrastructure into the future
+ gigabit NREN.
+ [Source: HPCC]
+
+ Interior Gateway Protocol (IGP)
+ A protocol which distributes routing information to the routers
+ within an autonomous system. The term "gateway" is historical, as
+ "router" is currently the preferred term. See also: Autonomous
+ System, Exterior Gateway Protocol, Open Shortest-Path First,
+ Routing Information Protocol.
+
+ Intermediate System (IS)
+ An OSI system which performs network layer forwarding. It is
+ analogous to an IP router. See also: Open Systems
+ Interconnection, router.
+
+ Intermediate System-Intermediate System (IS-IS)
+ The OSI IGP. See also: Open Systems Interconnection, Interior
+ Gateway Protocol.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 27]
+\f
+Internet Draft Glossary May 1996
+
+
+ International Organization for Standardization (ISO)
+ A voluntary, nontreaty organization founded in 1946 which is
+ responsible for creating international standards in many areas,
+ including computers and communications. Its members are the
+ national standards organizations of the 89 member countries,
+ including ANSI for the U.S. See also: American National Standards
+ Institute, Open Systems Interconnection.
+ [Source: TAN]
+
+ International Telecommunications Union (ITU)
+ An agency of the United Nations which coordinates the various
+ national telecommunications standards so that people in one
+ country can communicate with people in another country.
+
+ International Telecommunications Union -
+ Telecommunications Standards Sector (ITU-TSS)
+ The new name for CCITT since the ITU reorganization. The function
+ is the same; only the name has been changed
+
+ internet
+ While an internet is a network, the term "internet" is usually
+ used to refer to a collection of networks interconnected with
+ routers. See also: network.
+
+ Internet
+ (note the capital "I") The Internet is the largest internet in the
+ world. Is a three level hierarchy composed of backbone networks
+ (e.g. Ultranet), mid-level networks (e.g., NEARnet) and stub
+ networks. The Internet is a multiprotocol internet. See also:
+ backbone, mid-level network, stub network, transit network,
+ Internet Protocol.
+
+ internet address
+ A IP address that uniquely identifies a node on an internet. An
+ Internet address (capital "I"), uniquely identifies a node on the
+ Internet. See also: internet, Internet, IP address.
+
+ Internet Architecture Board (IAB)
+
+ The IAB has been many things over the years. Originally the
+ Internet Activities Board, it was responsible for the development
+ of the protocols which make up the Internet. It later changed its
+ name and charter to become the group most responsible for the
+ architecture of the Internet, leaving the protocol details to the
+ IESG. In June of 1992, it was chartered as a component of the
+ Internet Society; this is the charter it holds today. The IAB is
+ responsible for approving nominations to the IESG, architectural
+ oversight for Internet Standard Protocols, IETF standards process
+
+
+
+Malkin Expires: 2Nov96 [Page 28]
+\f
+Internet Draft Glossary May 1996
+
+
+ oversight and appeals, IANA and RFC activities, and liaison to
+ peer standards groups (e.g., ISO). See also: Internet Engineering
+ Task Force, Internet Research Task Force, Internet Engineering
+ Steering Group, Internet Assigned Numbers Authority, Request for
+ Comments.
+
+ Internet Assigned Numbers Authority (IANA)
+ The central registry for various Internet protocol parameters,
+ such as port, protocol and enterprise numbers, and options, codes
+ and types. The currently assigned values are listed in the
+ "Assigned Numbers" document [STD2]. To request a number
+ assignment, contact the IANA at "iana@isi.edu". See also:
+ assigned numbers, STD.
+
+ Internet Control Message Protocol (ICMP)
+ ICMP is an extension to the Internet Protocol. It allows for the
+ generation of error messages, test packets and informational
+ messages related to IP.
+ [Source: FYI4]
+
+ Internet-Draft (I-D)
+ Internet-Drafts are working documents of the IETF, its Areas, and
+ its Working Groups. As the name implies, Internet-Drafts are
+ draft documents. They are valid for a maximum of six months and
+ may be updated, replaced, or obsoleted by other documents at any
+ time. Very often, I-Ds are precursors to RFCs. See also:
+ Internet Engineering Task Force, Request For Comments.
+
+ Internet Engineering Planning Group (IEPG)
+ A group, primarily composed of Internet service operators, whose
+ goal is to promote a globally coordinated Internet operating
+ environment. Membership is open to all.
+
+ Internet Engineering Steering Group (IESG)
+ The IESG is composed of the IETF Area Directors and the IETF
+ Chair. It provides the first technical review of Internet
+ standards and is responsible for day-to-day "management" of the
+ IETF. See also: Internet Engineering Task Force.
+
+ Internet Engineering Task Force (IETF)
+ The IETF is a large, open community of network designers,
+ operators, vendors, and researchers whose purpose is to coordinate
+ the operation, management and evolution of the Internet, and to
+ resolve short-range and mid-range protocol and architectural
+ issues. It is a major source of proposals for protocol standards
+ which are submitted to the IAB for final approval. The IETF meets
+ three times a year and extensive minutes are included in the IETF
+ Proceedings. See also: Internet, Internet Architecture Board.
+
+
+
+Malkin Expires: 2Nov96 [Page 29]
+\f
+Internet Draft Glossary May 1996
+
+
+ [Source: FYI4]
+
+ Internet Experiment Note (IEN)
+ A series of reports pertinent to the Internet. IENs were
+ published in parallel to RFCs and were intended to be "working
+ documents." They have been replaced by Internet-Drafts and are
+ currently of historic value only. See also: Internet-Draft,
+ Request For Comments.
+
+ Internet Monthly Report (IMR)
+ Published monthly, the purpose of the Internet Monthly Reports is
+ to communicate to the Internet Research Group the accomplishments,
+ milestones reached, or problems discovered by the participating
+ organizations.
+
+ internet number
+ See: internet address
+
+ Internet Protocol (IP, IPv4)
+ The Internet Protocol (version 4), defined in RFC 791, is the
+ network layer for the TCP/IP Protocol Suite. It is a
+ connectionless, best-effort packet switching protocol. See also:
+ packet switching, TCP/IP Protocol Suite, Internet Protocol Version
+ 6.
+
+ Internet Protocol Version 6 (IPng, IPv6)
+ IPv6 (version 5 is a stream protocol used for special
+ applications) is a new version of the Internet Protocol which is
+ designed to be an evolutionary step from its predecessor, version
+ 4. There are many RFCs defining various portions of the protocol,
+ its auxiliary protocols, and the transition plan from IPv4. The
+ core RFCs are 1883 through 1886. The name IPng (IP next
+ generation) is a nod to STNG (Star Trek Next Generation).
+
+ Internet Registry (IR)
+ The IANA has the discretionary authority to delegate portions of
+ its responsibility and, with respect to network address and
+ Autonomous System identifiers, has lodged this responsibility with
+ an IR. The IR function is performed by the DDN NIC. See also:
+ Autonomous System, network address, Defense Data Network...,
+ Internet Assigned Numbers Authority.
+
+ Internet Relay Chat (IRC)
+ A world-wide "party line" protocol that allows one to converse
+ with others in real time. IRC is structured as a network of
+ servers, each of which accepts connections from client programs,
+ one per user. See also: talk.
+ [Source: HACKER]
+
+
+
+Malkin Expires: 2Nov96 [Page 30]
+\f
+Internet Draft Glossary May 1996
+
+
+ Internet Research Steering Group (IRSG)
+ The "governing body" of the IRTF. See also: Internet Research
+ Task Force.
+ [Source: MALAMUD]
+
+ Internet Research Task Force (IRTF)
+ The IRTF is chartered by the IAB to consider long-term Internet
+ issues from a theoretical point of view. It has Research Groups,
+ similar to IETF Working Groups, which are each tasked to discuss
+ different research topics. Multi-cast audio/video conferencing
+ and privacy enhanced mail are samples of IRTF output. See also:
+ Internet Architecture Board, Internet Engineering Task Force,
+ Privacy Enhanced Mail.
+
+ Internet Society (ISOC)
+ The Internet Society is a non-profit, professional membership
+ organization which facilitates and supports the technical
+ evolution of the Internet, stimulates interest in and educates the
+ scientific and academic communities, industry and the public about
+ the technology, uses and applications of the Internet, and
+ promotes the development of new applications for the system. The
+ Society provides a forum for discussion and collaboration in the
+ operation and use of the global Internet infrastructure. The
+ Internet Society publishes a quarterly newsletter, the Internet
+ Society News, and holds an annual conference, INET. The
+ development of Internet technical standards takes place under the
+ auspices of the Internet Society with substantial support from the
+ Corporation for National Research Initiatives under a cooperative
+ agreement with the US Federal Government.
+ [Source: V. Cerf]
+
+ Internetwork Packet eXchange (IPX)
+ Novell's protocol used by Netware. A router with IPX routing can
+ interconnect LANs so that Novell Netware clients and servers can
+ communicate. See also: Local Area Network.
+
+ InterNIC
+ A five year project, partially supported by the National Science
+ Foundation, to provide network information services to the
+ networking community. The InterNIC began operations in April of
+ 1993 and is now a collaborative project of two organizations:
+ AT&T, which provides Directory and Database Services from South
+ Plainsfield, NJ; and Network Solutions, Inc., which provides
+ Registration Services from their headquarters in Herndon, VA.
+ Services are provided via the Internet, and by telephone, FAX, and
+ hardcopy.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 31]
+\f
+Internet Draft Glossary May 1996
+
+
+ interoperability
+ The ability of software and hardware on multiple machines from
+ multiple vendors to communicate meaningfully.
+
+ IP (IPv4)
+ See: Internet Protocol
+
+ IPng (IPv6)
+ See: Internet Protocol Version 6
+
+ IP address
+ The 32-bit address defined by the Internet Protocol in RFC 791.
+ It is usually represented in dotted decimal notation. See also:
+ dot address, internet address, Internet Protocol, network address,
+ subnet address, host address.
+
+ IP datagram
+ See: datagram
+
+ IPX
+ See: Internetwork Packet eXchange
+
+ IR
+ See: Internet Registry
+
+ IRC
+ See: Internet Relay Chat
+
+ IRSG
+ See: Internet Research Steering Group
+
+ IRTF
+ See: Internet Research Task Force
+
+ IS
+ See: Intermediate System
+
+ IS-IS
+ See: Intermediate System-Intermediate System
+
+ ISDN
+ See: Integrated Services Digital Network
+
+ ISO
+ See: International Organization for Standardization
+
+ ISO Development Environment (ISODE)
+ Software that allows OSI services to use a TCP/IP network.
+
+
+
+Malkin Expires: 2Nov96 [Page 32]
+\f
+Internet Draft Glossary May 1996
+
+
+ Pronounced eye-so-dee-eee. See also: Open Systems
+ Interconnection, TCP/IP Protocol Suite.
+
+ ISOC
+ See: Internet Society
+
+ ISODE
+ See: ISO Development Environment
+
+ ITU
+ See: International Telecommunications Union -
+ Telecommunications Standards Sector
+
+ ITU-TSS
+ See: International Telecommunications Union
+
+ JKREY
+ Joyce K. Reynolds
+
+ KA9Q
+ A popular implementation of TCP/IP and associated protocols for
+ amateur packet radio systems. See also: TCP/IP Protocol Suite.
+ [Source: RFC1208]
+
+ Kerberos
+ Kerberos is the security system of MIT's Project Athena. It is
+ based on symmetric key cryptography. See also: encryption.
+
+ Kermit
+ A popular file transfer protocol developed by Columbia University.
+ Because Kermit runs in most operating environments, it provides an
+ easy method of file transfer. Kermit is NOT the same as FTP. See
+ also: File Transfer Protocol
+ [Source: MALAMUD]
+
+ Knowbot
+ A "Knowledge Robot" is a program which seeks out information based
+ on specified criteria. "Knowbot," as trademarked by CNRI, refers
+ specifically to the search engine for Knowbot Information
+ Services. See also: Corporation for National Research
+ Initiatives, X.500, white pages, whois, netfind.
+
+ Knowbot Information Services
+ An experimental directory service. See also: white pages, whois,
+ X.500.
+
+ LAN
+ See: Local Area Network
+
+
+
+Malkin Expires: 2Nov96 [Page 33]
+\f
+Internet Draft Glossary May 1996
+
+
+ layer
+ Communication networks for computers may be organized as a set of
+ more or less independent protocols, each in a different layer
+ (also called level). The lowest layer governs direct host-to-host
+ communication between the hardware at different hosts; the highest
+ consists of user applications. Each layer builds on the layer
+ beneath it. For each layer, programs at different hosts use
+ protocols appropriate to the layer to communicate with each other.
+ TCP/IP has five layers of protocols; OSI has seven. The
+ advantages of different layers of protocols is that the methods of
+ passing information from one layer to another are specified
+ clearly as part of the protocol suite, and changes within a
+ protocol layer are prevented from affecting the other layers.
+ This greatly simplifies the task of designing and maintaining
+ communication programs. See also: Open Systems Interconnection,
+ TCP/IP Protocol Suite.
+
+ LDAP
+ See: Lightweight Directory Access Protocol
+
+ Lightweight Directory Access Protocol
+ This protocol provides access for management and browser
+ applications that provide read/write interactive access to the
+ X.500 Directory. See also: X.500.
+
+ link
+ A pointer which may be used to retreive the file or data to which
+ the pointer points.
+
+ list server
+ An automated mailing list distribution system. List servers
+ handle the administrivia of mailing list maintenance, such as the
+ adding and deleting of list members.
+
+ little-endian
+ A format for storage or transmission of binary data in which the
+ least significant byte (bit) comes first. See also: big-endian.
+ [Source: RFC1208]
+
+ LLC
+ See: Logical Link Control
+
+ Local Area Network (LAN)
+ A data network intended to serve an area of only a few square
+ kilometers or less. Because the network is known to cover only a
+ small area, optimizations can be made in the network signal
+ protocols that permit data rates up to 100Mb/s. See also:
+ Ethernet, Fiber Distributed Data Interface, token ring,
+
+
+
+Malkin Expires: 2Nov96 [Page 34]
+\f
+Internet Draft Glossary May 1996
+
+
+ Metropolitan Area Network, Wide Area Network.
+ [Source: NNSC]
+
+ Logical Link Control (LLC)
+ The upper portion of the datalink layer, as defined in IEEE 802.2.
+ The LLC sublayer presents a uniform interface to the user of the
+ datalink service, usually the network layer. Beneath the LLC
+ sublayer is the MAC sublayer. See also: 802.x, layer, Media
+ Access Control.
+
+ Lurking
+ No active participation on the part of a subscriber to an mailing
+ list or USENET newsgroup. A person who is lurking is just
+ listening to the discussion. Lurking is encouraged for beginners
+ who need to get up to speed on the history of the group. See
+ also: Electronic Mail, mailing list, Usenet.
+ [Source: LAQUEY]
+
+ Lycos
+ Lycos, Inc. is a new venture formed in late June 1995, to develop
+ and market the Lycos technology originally developed under the
+ direction of Dr. Michael ("Fuzzy") Mauldin at Carnegie Mellon
+ University. The part of Lycos you see when you do a search is the
+ search engine. "Lycos" comes from Lycosidae, a cosmopolitan
+ family of relatively large active ground spiders (Wolf Spiders)
+ that catch their prey by pursuit, rather than in a web.
+ [Source: Lycos's FAQ]
+
+ MAC
+ See: Media Access Control
+
+ MAC address
+ The hardware address of a device connected to a shared media. See
+ also: Media Access Control, Ethernet, token ring.
+ [Source: MALAMUD]
+
+ mail bridge
+ A mail gateway that forwards electronic mail between two or more
+ networks while ensuring that the messages it forwards meet certain
+ administrative criteria. A mail bridge is simply a specialized
+ form of mail gateway that enforces an administrative policy with
+ regard to what mail it forwards. See also: Electronic Mail, mail
+ gateway.
+ [Source: NNSC]
+
+ Mail Exchange Record (MX Record)
+ A DNS resource record type indicating which host can handle mail
+ for a particular domain. See also: Domain Name System, Electronic
+
+
+
+Malkin Expires: 2Nov96 [Page 35]
+\f
+Internet Draft Glossary May 1996
+
+
+ Mail.
+ [Source: MALAMUD]
+
+ mail exploder
+ Part of an electronic mail delivery system which allows a message
+ to be delivered to a list of addresses. Mail exploders are used
+ to implement mailing lists. Users send messages to a single
+ address and the mail exploder takes care of delivery to the
+ individual mailboxes in the list. See also: Electronic Mail,
+ email address, mailing list.
+ [Source: RFC1208]
+
+ mail gateway
+ A machine that connects two or more electronic mail systems
+ (including dissimilar mail systems) and transfers messages between
+ them. Sometimes the mapping and translation can be quite complex,
+ and it generally requires a store-and-forward scheme whereby the
+ message is received from one system completely before it is
+ transmitted to the next system, after suitable translations. See
+ also: Electronic Mail.
+ [Source: RFC1208]
+
+ mail path
+ A series of machine names used to direct electronic mail from one
+ user to another. This system of email addressing has been used
+ primarily in UUCP networks which are trying to eliminate its use
+ altogether. See also: bang path, email address, UNIX-to-UNIX
+ CoPy.
+
+ mail server
+ A software program that distributes files or information in
+ response to requests sent via email. Internet examples include
+ Almanac and netlib. Mail servers have also been used in Bitnet to
+ provide FTP-like services. See also: Bitnet, Electronic Mail,
+ FTP.
+ [Source: NWNET]
+
+ mailing list
+ A list of email addresses, used by a mail exploder, to forward
+ messages to groups of people. Generally, a mailing list is used
+ to discuss certain set of topics, and different mailing lists
+ discuss different topics. A mailing list may be moderated. This
+ means that messages sent to the list are actually sent to a
+ moderator who determines whether or not to send the messages on to
+ everyone else. Requests to subscribe to, or leave, a mailing list
+ should ALWAYS be sent to the list's "-request" address (e.g.
+ ietf-request@cnri.reston.va.us for the IETF mailing list) or
+ majordomo server. See also: Electronic Mail, mail exploder, email
+
+
+
+Malkin Expires: 2Nov96 [Page 36]
+\f
+Internet Draft Glossary May 1996
+
+
+ address, moderator, majordomo.
+
+ majordomo
+ A program which handles mailing list maintenance (affectionately
+ known as administrivia) such as adding and removing addresses from
+ mailing lists. See also: email address, mailing list.
+
+ MAN
+ See: Metropolitan Area Network
+
+ Management Information Base (MIB)
+ The set of parameters an SNMP management station can query or set
+ in the SNMP agent of a network device (e.g. router). Standard,
+ minimal MIBs have been defined, and vendors often have Private
+ enterprise MIBs. In theory, any SNMP manager can talk to any SNMP
+ agent with a properly defined MIB. See also: client-server model,
+ Simple Network Management Protocol.
+ [Source: BIG-LAN]
+
+ Martian
+ A humorous term applied to packets that turn up unexpectedly on
+ the wrong network because of bogus routing entries. Also used as
+ a name for a packet which has an altogether bogus (non-registered
+ or ill-formed) internet address.
+ [Source: RFC1208]
+
+ Maximum Transmission Unit (MTU)
+ The largest frame length which may be sent on a physical medium.
+ See also: frame, fragment, fragmentation.
+
+ mbone
+ The Multicast Backbone is based on IP multicasting using class-D
+ addresses. The mbone concept was adopted at the March 1992 IETF
+ in San Diego, during which it was used to audiocast to 40 people
+ throughout the world. At the following meeting, in Cambridge, the
+ name mbone was adopted. Since then the audiocast has become full
+ two-way audio/video conferencing using two video channels, four
+ audio channels, and involving hundreds of remote users. See also:
+ multicast, Internet Engineering Task Force.
+
+ MD-2, MD-4, MD-5
+ See: Message Digest
+
+ Media Access Control (MAC)
+ The lower portion of the datalink layer. The MAC differs for
+ various physical media. See also: MAC Address, Ethernet, Logical
+ Link Control, token ring.
+
+
+
+
+Malkin Expires: 2Nov96 [Page 37]
+\f
+Internet Draft Glossary May 1996
+
+
+ Message Digest (MD-2, MD-4, MD-5)
+ Message digests are algorithmic operations, generally performed on
+ text, which produce a unique signature for that text. MD-2,
+ described in RFC 1319; MD-4, described in RFC 1320; and MD-5,
+ described in RFC 1321 all produce a 128-bit signature. They
+ differ in their operating speed and resistance to crypto-analytic
+ attack. Generally, one must be traded off for the other.
+
+ message switching
+ See: packet switching
+
+ Metropolitan Area Network (MAN)
+ A data network intended to serve an area approximating that of a
+ large city. Such networks are being implemented by innovative
+ techniques, such as running fiber cables through subway tunnels.
+ A popular example of a MAN is SMDS. See also: Local Area Network,
+ Switched Multimegabit Data Service, Wide Area Network.
+ [Source: NNSC]
+
+ MIB
+ See: Management Information Base
+
+ Microcom Networking Protocol (MNP)
+ A series of protocols built into most modems which error-check or
+ compress data being transmitted over a phone line.
+
+ mid-level network
+ Mid-level networks (a.k.a. regionals) make up the second level of
+ the Internet hierarchy. They are the transit networks which
+ connect the stub networks to the backbone networks. See also:
+ backbone, Internet, stub network, transit network.
+
+ MIME
+ See: Multipurpose Internet Mail Extensions
+
+ MNP
+ See: Microcom Networking Protocol
+
+ moderator
+ A person, or small group of people, who manage moderated mailing
+ lists and newsgroups. Moderators are responsible for determining
+ which email submissions are passed on to list. See also:
+ Electronic Mail, mailing list, Usenet.
+
+ MOSPF
+ Multicast Open Shortest-Path First. See: Open Shortest-Path First.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 38]
+\f
+Internet Draft Glossary May 1996
+
+
+ MTU
+ See: Maximum Transmission Unit
+
+ MUD
+ See: Multi-User Dungeon
+
+ multicast
+ A packet with a special destination address which multiple nodes
+ on the network may be willing to receive. See also: broadcast,
+ unicast.
+
+ multihomed host
+ A host which has more than one connection to a network. The host
+ may send and receive data over any of the links but will not route
+ traffic for other nodes. See also: host, router.
+ [Source: MALAMUD]
+
+ Multipurpose Internet Mail Extensions (MIME)
+ An extension to Internet email which provides the ability to
+ transfer non-textual data, such as graphics, audio and fax. See
+ also: Electronic Mail
+
+ Multi-User Dungeon (MUD)
+ Adventure, role playing games, or simulations played on the
+ Internet. Devotees call them "text-based virtual reality
+ adventures." The games can feature fantasy combat, booby traps
+ and magic. Players interact in real time and can change the
+ "world" in the game as they play it. Most MUDs are based on the
+ Telnet protocol. See also: Telnet.
+ [Source: LAQUEY]
+
+ MX Record
+ See: Mail Exchange Record
+
+ NAK
+ See: Negative Acknowledgment
+
+ name resolution
+ The process of mapping a name into its corresponding address. See
+ also: Domain Name System.
+ [Source: RFC1208]
+
+ namespace
+ A commonly distributed set of names in which all names are unique.
+ [Source: MALAMUD]
+
+ National Institute of Standards and Technology (NIST)
+ United States governmental body that provides assistance in
+
+
+
+Malkin Expires: 2Nov96 [Page 39]
+\f
+Internet Draft Glossary May 1996
+
+
+ developing standards. Formerly the National Bureau of Standards.
+ [Source: MALAMUD]
+
+ National Research and Education Network (NREN)
+ The NREN is the realization of an interconnected gigabit computer
+ network devoted to Hign Performance Computing and Communications.
+ See also: HPPC, IINREN.
+ [Source: HPCC]
+
+ National Science Foundation (NSF)
+ A U.S. government agency whose purpose is to promote the
+ advancement of science. NSF funds science researchers, scientific
+ projects, and infrastructure to improve the quality of scientific
+ research. The NSFNET, funded by NSF, was once an essential part
+ of academic and research communications. It was a highspeed,
+ hierarchical "network of networks." At the highest level, it had
+ a backbone network of nodes, interconnected with T3 (45Mbps)
+ facilities which spaned the continental United States. Attached
+ to that were mid-level networks, and attached to the mid-levels
+ were campus and local networks. See also: backbone network, mid-
+ level network.
+
+ Negative Acknowledgment (NAK)
+ Response to the receipt of either a corrupted or unnexpected
+ packet of information. See also: Acknowledgement.
+
+ netfind
+ A research prototype to provide a simple Internet "white pages"
+ user directory. Developed at the University of Colorado, Boulder,
+ it tries to locate telephone and email information given a
+ person's name and a rough description of where the person works.
+ See also: Knowbot, whois, white pages, X.500.
+ [Source: Ryan Moats]
+
+ netiquette
+ A pun on "etiquette" referring to proper behavior on a network.
+ RFC 1855 (FYI 28) contains a netiquette guide produced by the User
+ Services area of the IETF. See also: Acceptable Use Policy,
+ Internet Engineering Task Force.
+
+ Netnews
+ See: Usenet
+
+ network
+ A computer network is a data communications system which
+ interconnects computer systems at various different sites. A
+ network may be composed of any combination of LANs, MANs or WANs.
+ See also: Local Area Network, Metropolitan Area Network, Wide Area
+
+
+
+Malkin Expires: 2Nov96 [Page 40]
+\f
+Internet Draft Glossary May 1996
+
+
+ Network, internet.
+
+ network address
+ The network portion of an IP address. For a class A network, the
+ network address is the first byte of the IP address. For a class
+ B network, the network address is the first two bytes of the IP
+ address. For a class C network, the network address is the first
+ three bytes of the IP address. In each case, the remainder is the
+ host address. In the Internet, assigned network addresses are
+ globally unique. See also: Internet, IP address, subnet address,
+ host address, Internet Registry.
+
+ Network File System (NFS)
+ A protocol developed by Sun Microsystems, and defined in RFC 1094
+ (RFC 1813 defines Version 3), which allows a computer system to
+ access files over a network as if they were on its local disks.
+ This protocol has been incorporated in products by more than two
+ hundred companies, and is now a de facto Internet standard.
+ [Source: NNSC]
+
+ Network Information Center (NIC)
+ A NIC provides information, assistance and services to network
+ users. See also: Network Operations Center.
+
+ Network Information Services (NIS)
+ A set of services, generally provided by a NIC, to assist users in
+ using the network. See also: Network Information Center.
+
+ Network News Transfer Protocol (NNTP)
+ A protocol, defined in RFC 977, for the distribution, inquiry,
+ retrieval, and posting of news articles. See also: Usenet.
+
+ network mask
+ See: address mask
+
+ network number
+ See: network address
+
+ Network Operations Center (NOC)
+ A location from which the operation of a network or internet is
+ monitored. Additionally, this center usually serves as a
+ clearinghouse for connectivity problems and efforts to resolve
+ those problems. See also: Network Information Center.
+ [Source: NNSC]
+
+ Network Time Protocol (NTP)
+ A protocol that assures accurate local timekeeping with reference
+ to radio and atomic clocks located on the Internet. This protocol
+
+
+
+Malkin Expires: 2Nov96 [Page 41]
+\f
+Internet Draft Glossary May 1996
+
+
+ is capable of synchronizing distributed clocks within milliseconds
+ over long time periods. See also: Internet.
+ [Source: NNSC]
+
+ NFS
+ See: Network File System
+
+ NIC
+ See: Network Information Center
+
+ NIC.DDN.MIL
+ This is the domain name of the DDN NIC. See also: Defense Data
+ Network, Domain Name System, Network Information Center.
+
+ NIS
+ See: Network Information Services
+
+ NIST
+ See: National Institute of Standards and Technology
+
+ NNTP
+ See: Network News Transfer Protocol
+
+ NOC
+ See: Network Operations Center
+
+ Nodal Switching System (NSS)
+ Main routing nodes in the NSFnet backbone. See also: backbone,
+ National Science Foundation.
+ [Source: MALAMUD]
+
+ node
+ An addressable device attached to a computer network. See also:
+ host, router.
+
+ NREN
+ See: National Research and Education Network
+
+ NSF
+ See: National Science Foundation
+
+ NSS
+ See: Nodal Switching System
+
+ NTP
+ See: Network Time Protocol
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 42]
+\f
+Internet Draft Glossary May 1996
+
+
+ OCLC
+ See: Online Computer Library Catalog
+
+ octet
+ An octet is 8 bits. This term is used in networking, rather than
+ byte, because some systems have bytes that are not 8 bits long.
+
+ Online Computer Library Catalog
+ OCLC is a nonprofit membership organization offering computer-
+ based services to libraries, educational organizations, and their
+ users. The OCLC library information network connects more than
+ 10,000 libraries worldwide. Libraries use the OCLC System for
+ cataloging, interlibrary loan, collection development,
+ bibliographic verification, and reference searching.
+ [Source: OCLC]
+
+ Open Shortest-Path First (OSPF)
+ A link state, as opposed to distance vector, routing protocol. It
+ is an Internet standard IGP defined in RFCs 1583 and 1793. The
+ multicast version, MOSPF, is defined in RFC 1584. See also:
+ Interior Gateway Protocol, Routing Information Protocol.
+
+ Open Systems Interconnection (OSI)
+ A suite of protocols, designed by ISO committees, to be the
+ international standard computer network architecture. See also:
+ International Organization for Standardization.
+
+ OSI
+ See: Open Systems Interconnection
+
+ OSI Reference Model
+ A seven-layer structure designed to describe computer network
+ architectures and the way that data passes through them. This
+ model was developed by the ISO in 1978 to clearly define the
+ interfaces in multivendor networks, and to provide users of those
+ networks with conceptual guidelines in the construction of such
+ networks. See also: International Organization for
+ Standardization.
+ [Source: NNSC]
+
+ OSPF
+ See: Open Shortest-Path First
+
+ packet
+ The unit of data sent across a network. "Packet" a generic term
+ used to describe unit of data at all levels of the protocol stack,
+ but it is most correctly used to describe application data units.
+ See also: datagram, frame.
+
+
+
+Malkin Expires: 2Nov96 [Page 43]
+\f
+Internet Draft Glossary May 1996
+
+
+ Packet InterNet Groper (PING)
+ A program used to test reachability of destinations by sending
+ them an ICMP echo request and waiting for a reply. The term is
+ used as a verb: "Ping host X to see if it is up!" See also:
+ Internet Control Message Protocol.
+ [Source: RFC1208]
+
+ Packet Switch Node (PSN)
+ A dedicated computer whose purpose is to accept, route and forward
+ packets in a packet switched network. See also: packet switching,
+ router.
+ [Source: NNSC]
+
+ packet switching
+ A communications paradigm in which packets (messages) are
+ individually routed between hosts, with no previously established
+ communication path. See also: circuit switching, connection-
+ oriented, connectionless.
+
+ PD
+ Public Domain
+
+ PDU
+ See: Protocol Data Unit
+
+ PEM
+ See: Privacy Enhanced Mail
+
+ PGP
+ See: Pretty Good Privacy
+
+ PING
+ See: Packet INternet Groper
+
+ Point Of Presence (POP)
+ A site where there exists a collection of telecommunications
+ equipment, usually digital leased lines and multi-protocol
+ routers.
+
+ Point-to-Point Protocol (PPP)
+ The Point-to-Point Protocol, defined in RFC 1661, provides a
+ method for transmitting packets over serial point-to-point links.
+ There are many other RFCs which define extensions to the basic
+ protocol. See also: Serial Line IP.
+ [Source: FYI4]
+
+ POP
+ See: Post Office Protocol and Point Of Presence
+
+
+
+Malkin Expires: 2Nov96 [Page 44]
+\f
+Internet Draft Glossary May 1996
+
+
+ port
+ A port is a transport layer demultiplexing value. Each
+ application has a unique port number associated with it. See
+ also: Transmission Control Protocol, User Datagram Protocol.
+
+ Post Office Protocol (POP)
+ A protocol designed to allow single user hosts to read electronic
+ mail from a server. Version 3, the most recent and most widely
+ used, is defined in RFC 1725. See also: Electronic Mail.
+
+ Postal Telegraph and Telephone (PTT)
+ Outside the USA, PTT refers to a telephone service provider, which
+ is usually a monopoly, in a particular country.
+
+ postmaster
+ The person responsible for taking care of electronic mail
+ problems, answering queries about users, and other related work at
+ a site. See also: Electronic Mail.
+ [Source: ZEN]
+
+ PPP
+ See: Point-to-Point Protocol
+
+ Pretty Good Privacy (PGP)
+ A program, developed by Phil Zimmerman, which cryptographically
+ protects files and electronic mail from being read by others. It
+ may also be used to digitally sign a document or message, thus
+ authenticating the creator. See also: encryption, Data Encryption
+ Standard, RSA.
+
+ Privacy Enhanced Mail (PEM)
+ Internet email which provides confidentiality, authentication and
+ message integrity using various encryption methods. See also:
+ Electronic Mail, encryption.
+
+ Prospero
+ A distributed filesystem which provides the user with the ability
+ to create multiple views of a single collection of files
+ distributed across the Internet. Prospero provides a file naming
+ system, and file access is provided by existing access methods
+ (e.g. anonymous FTP and NFS). The Prospero protocol is also used
+ for communication between clients and servers in the archie
+ system. See also: anonymous FTP, archie, archive site, Gopher,
+ Network File System, Wide Area Information Servers.
+
+ protocol
+ A formal description of message formats and the rules two
+ computers must follow to exchange those messages. Protocols can
+
+
+
+Malkin Expires: 2Nov96 [Page 45]
+\f
+Internet Draft Glossary May 1996
+
+
+ describe low-level details of machine-to-machine interfaces (e.g.,
+ the order in which bits and bytes are sent across a wire) or
+ high-level exchanges between allocation programs (e.g., the way in
+ which two programs transfer a file across the Internet).
+ [Source: MALAMUD]
+
+ protocol converter
+ A device/program which translates between different protocols
+ which serve similar functions (e.g. TCP and TP4).
+
+ Protocol Data Unit (PDU)
+ "PDU" is internationalstandardscomitteespeak for packet. See
+ also: packet.
+
+ protocol stack
+ A layered set of protocols which work together to provide a set of
+ network functions. See also: layer, protocol.
+
+ proxy ARP
+ The technique in which one machine, usually a router, answers ARP
+ requests intended for another machine. By "faking" its identity,
+ the router accepts responsibility for routing packets to the
+ "real" destination. Proxy ARP allows a site to use a single IP
+ address with two physical networks. Subnetting would normally be
+ a better solution. See also: Address Resolution Protocol
+ [Source: RFC1208]
+
+ PSN
+ See: Packet Switch Node.
+
+ PTT
+ See: Postal, Telegraph and Telephone
+
+ queue
+ A backup of packets awaiting processing.
+
+ RARE
+ Reseaux Associes pour la Recherche Europeenne. See: Trans-
+ European Research and Education Networking Association.
+
+ RARP
+ See: Reverse Address Resolution Protocol
+
+ RBOC
+ Regional Bell Operating Company
+
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 46]
+\f
+Internet Draft Glossary May 1996
+
+
+ Read The F*cking Manual (RTFM)
+ This acronym is often used when someone asks a simple or common
+ question.
+
+ Read The Source Code (RTSC)
+ This acronym is often used when a software developer asks a
+ question about undocumented code.
+
+ reassembly
+ The IP process in which a previously fragmented packet is
+ reassembled before being passed to the transport layer. See also:
+ fragmentation.
+
+ recursive
+ See: recursive
+
+ regional
+ See: mid-level network
+
+ remote login
+ Operating on a remote computer, using a protocol over a computer
+ network, as though locally attached. See also: Telnet.
+
+ Remote Procedure Call (RPC)
+ An easy and popular paradigm for implementing the client-server
+ model of distributed computing. In general, a request is sent to
+ a remote system to execute a designated procedure, using arguments
+ supplied, and the result returned to the caller. There are many
+ variations and subtleties in various implementations, resulting in
+ a variety of different (incompatible) RPC protocols.
+ [Source: RFC1208]
+
+ repeater
+ A device which propagates electrical signals from one cable to
+ another. See also: bridge, gateway, router.
+
+ Request For Comments (RFC)
+ The document series, begun in 1969, which describes the Internet
+ suite of protocols and related experiments. Not all (in fact very
+ few) RFCs describe Internet standards, but all Internet standards
+ are written up as RFCs. The RFC series of documents is unusual in
+ that the proposed protocols are forwarded by the Internet research
+ and development community, acting on their own behalf, as opposed
+ to the formally reviewed and standardized protocols that are
+ promoted by organizations such as CCITT and ANSI. See also: BCP,
+ FYI, STD.
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 47]
+\f
+Internet Draft Glossary May 1996
+
+
+ Reseaux IP Europeenne (RIPE)
+ A collaboration between European networks which use the TCP/IP
+ protocol suite.
+
+ Reverse Address Resolution Protocol (RARP)
+ A protocol, defined in RFC 903, which provides the reverse
+ function of ARP. RARP maps a hardware (MAC) address to an
+ internet address. It is used primarily by diskless nodes when
+ they first initialize to find their internet address. See also:
+ Address Resolution Protocol, BOOTP, internet address, MAC address.
+
+ RFC
+ See: Request For Comments
+
+ RFC 822
+ The Internet standard format for electronic mail message headers.
+ Mail experts often refer to "822 messages." The name comes from
+ RFC 822, which contains the specification. 822 format was
+ previously known as 733 format. See also: Electronic Mail.
+ [Source: COMER]
+
+ RIP
+ See: Routing Information Protocol
+
+ RIPE
+ See: Reseaux IP Europeenne
+
+ Round-Trip Time (RTT)
+ A measure of the current delay on a network.
+ [Source: MALAMUD]
+
+ route
+ The path that network traffic takes from its source to its
+ destination. Also, a possible path from a given host to another
+ host or destination.
+
+ routed
+ Route Daemon. A program which runs under 4.2BSD/4.3BSD UNIX
+ systems (and derived operating systems) to propagate routes among
+ machines on a local area network, using the RIP protocol.
+ Pronounced "route-dee". See also: Routing Information Protocol,
+ gated.
+
+ router
+ A device which forwards traffic between networks. The forwarding
+ decision is based on network layer information and routing tables,
+ often constructed by routing protocols. See also: bridge,
+ gateway, Exterior Gateway Protocol, Interior Gateway Protocol.
+
+
+
+Malkin Expires: 2Nov96 [Page 48]
+\f
+Internet Draft Glossary May 1996
+
+
+ routing
+ The process of selecting the correct interface and next hop for a
+ packet being forwarded. See also: hop, router, Exterior Gateway
+ Protocol, Interior Gateway Protocol.
+
+ routing domain
+ A set of routers exchanging routing information within an
+ administrative domain. See also: Administrative Domain, router.
+
+ Routing Information Protocol (RIP)
+ A distance vector, as opposed to link state, routing protocol. It
+ is an Internet standard IGP defined in RFC 1058. See also:
+ Interior Gateway Protocol, Open Shortest-Path First.
+
+ RPC
+ See: Remote Procedure Call
+
+ RSA
+ A public-key cryptographic system which may be used for encryption
+ and authentication. It was invented in 1977 and named for its
+ inventors: Ron Rivest, Adi Shamir, and Leonard Adleman. See also:
+ encryption, Data Encryption Standard, Pretty Good Privacy.
+
+ RTFM
+ See: Read The F*cking Manual
+
+ RTSC
+ See: Read The Source Code
+
+ RTT
+ See: Round-Trip Time
+
+ SDH
+ See: Synchronous Digital Hierarchy
+
+ Serial Line IP (SLIP)
+ A protocol used to run IP over serial lines, such as telephone
+ circuits or RS-232 cables, interconnecting two systems. SLIP is
+ defined in RFC 1055, but is not an Internet Standard. It is being
+ replaced by PPP. See also: Point-to-Point Protocol.
+
+ server
+ A provider of resources (e.g. file servers and name servers). See
+ also: client, Domain Name System, Network File System.
+
+ SGML
+ See: Standardized Generalized Markup Language
+
+
+
+
+Malkin Expires: 2Nov96 [Page 49]
+\f
+Internet Draft Glossary May 1996
+
+
+ SIG
+ Special Interest Group
+
+ signature
+ The three or four line message at the bottom of a piece of email
+ or a Usenet article which identifies the sender. Large signatures
+ (over five lines) are generally frowned upon. See also:
+ Electronic Mail, Usenet.
+
+ Simple Mail Transfer Protocol (SMTP)
+ A protocol used to transfer electronic mail between computers. It
+ is specified in RFC 821, with extensions specified in many other
+ RFCs. It is a server to server protocol, so other protocols are
+ used to access the messages. See also: Electronic Mail, Post
+ Office Protocol, RFC 822.
+
+ Simple Network Management Protocol (SNMP)
+ The Internet standard protocol developed to manage nodes on an IP
+ network. The first version is defined in RFC 1157 (STD 15).
+ SNMPv2 (version 2) is defined in too many RFCs to list. It is
+ currently possible to manage wiring hubs, toasters, jukeboxes,
+ etc. See also: Management Information Base.
+
+ SLIP
+ See: Serial Line IP
+
+ SMDS
+ See: Switched Multimegabit Data Service
+
+ SMI
+ See: Structure of Management Information
+
+ SMTP
+ See: Simple Mail Transfer Protocol
+
+ SNA
+ See: Systems Network Architecture
+
+ snail mail
+ A pejorative term referring to the U.S. postal service.
+
+ SNMP
+ See: Simple Network Management Protocol
+
+ SONET
+ See: Synchronous Optical NETwork
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 50]
+\f
+Internet Draft Glossary May 1996
+
+
+ Standardized Generalized Markup Language (SGML)
+ An international standard for the definition of system-
+ independent, device-independent methods of representing text in
+ electronic form. See also: Hypertext Markup Language.
+
+ STD
+ A subseries of RFCs that specify Internet standards. The official
+ list of Internet standards is in STD 1. See also: Request For
+ Comments.
+
+ stream-oriented
+ A type of transport service that allows its client to send data in
+ a continuous stream. The transport service will guarantee that
+ all data will be delivered to the other end in the same order as
+ sent and without duplicates. See also: Transmission Control
+ Protocol.
+ [Source: MALAMUD]
+
+ Structure of Management Information (SMI)
+ The rules used to define the objects that can be accessed via a
+ network management protocol. These rules are defined in RFC 1155
+ (STD 17). The acronym is pronounced "Ess Em Eye." See also:
+ Management Information Base. .br [Source: RFC1208]
+
+ stub network
+ A stub network only carries packets to and from local hosts. Even
+ if it has paths to more than one other network, it does not carry
+ traffic for other networks. See also: backbone, transit network.
+
+ subnet
+ A portion of a network, which may be a physically independent
+ network segment, which shares a network address with other
+ portions of the network and is distinguished by a subnet number.
+ A subnet is to a network what a network is to an internet. See
+ also: internet, network.
+ [Source: FYI4]
+
+ subnet address
+ The subnet portion of an IP address. In a subnetted network, the
+ host portion of an IP address is split into a subnet portion and a
+ host portion using an address (subnet) mask. See also: address
+ mask, IP address, network address, host address.
+
+ subnet mask
+ See: address mask
+
+ subnet number
+ See: subnet address
+
+
+
+Malkin Expires: 2Nov96 [Page 51]
+\f
+Internet Draft Glossary May 1996
+
+
+ supernet
+ An aggregation of IP network addresses advertised as a single
+ classless network address. For example, given four Class C IP
+ networks: 192.0.8.0, 192.0.9.0, 192.0.10.0 and 192.0.11.0, each
+ having the intrinsic network mask of 255.255.255.0; one can
+ advertise the address 192.0.8.0 with a subnet mask of
+ 255.255.252.0. See also: IP address, network address, network
+ mask, Classless Inter-domain Routing.
+
+ Switched Multimegabit Data Service (SMDS)
+ An emerging high-speed datagram-based public data network service
+ developed by Bellcore and expected to be widely used by telephone
+ companies as the basis for their data networks. See also:
+ Metropolitan Area Network.
+ [Source: RFC1208]
+
+ Synchronous Digital Hierarchy (SDH)
+ The European standard for high-speed data communications over
+ fiber-optic media. The transmission rates range from 155.52Mbps
+ to 2.5Gbps.
+
+ Synchronous Optical NETwork (SONET)
+ SONET is an international standard for high-speed data
+ communications over fiber-optic media. The transmission rates
+ range from 51.84Mbps to 2.5Gbps.
+
+ Systems Network Architecture (SNA)
+ A proprietary networking architecture used by IBM and IBM-
+ compatible mainframe computers.
+ [Source: NNSC]
+
+ T1
+ A term for a digital carrier facility used to transmit a DS-1
+ formatted digital signal at 1.544 megabits per second.
+
+ T3
+ A term for a digital carrier facility used to transmit a DS-3
+ formatted digital signal at 44.746 megabits per second.
+ [Source: FYI4]
+
+ TAC
+ See: Terminal Access Controller (TAC)
+
+ talk
+ A protocol which allows two people on remote computers to
+ communicate in a real-time fashion. See also: Internet Relay
+ Chat.
+
+
+
+
+Malkin Expires: 2Nov96 [Page 52]
+\f
+Internet Draft Glossary May 1996
+
+
+ TCP
+ See: Transmission Control Protocol
+
+ TCP/IP Protocol Suite
+ Transmission Control Protocol over Internet Protocol. This is a
+ common shorthand which refers to the suite of transport and
+ application protocols which runs over IP. See also: IP, ICMP,
+ TCP, UDP, FTP, Telnet, SMTP, SNMP.
+
+ TELENET
+ The original name for what is now SprintNet. It should not be
+ confused with the Telnet protocol or application program.
+
+ Telnet
+ Telnet is the Internet standard protocol for remote terminal
+ connection service. It is defined in RFC 854 and extended with
+ options by many other RFCs.
+
+ TERENA
+ See: Trans-European Research and Education Networking Association
+
+ Terminal Access Controller (TAC)
+ A device which was once used to connect terminals to the Internet,
+ usually using dialup modem connections and the TACACS protocol.
+ While the device is no longer in use, TACACS+ is a protocol in
+ current use.
+
+ terminal emulator
+ A program that allows a computer to emulate a terminal. The
+ workstation thus appears as a terminal to the remote host.
+ [Source: MALAMUD]
+
+ terminal server
+ A device which connects many terminals to a LAN through one
+ network connection. A terminal server can also connect many
+ network users to its asynchronous ports for dial-out capabilities
+ and printer access. See also: Local Area Network.
+
+ Three Letter Acronym (TLA)
+ A tribute to the use of acronyms in the computer field. See also:
+ Extended Four Letter Acronym.
+
+ Time to Live (TTL)
+ A field in the IP header which indicates how long this packet
+ should be allowed to survive before being discarded. It is
+ primarily used as a hop count. See also: Internet Protocol.
+ [Source: MALAMUD]
+
+
+
+
+Malkin Expires: 2Nov96 [Page 53]
+\f
+Internet Draft Glossary May 1996
+
+
+ TLA
+ See: Three Letter Acronym
+
+ TN3270
+ A variant of the Telnet program that allows one to attach to IBM
+ mainframes and use the mainframe as if you had a 3270 or similar
+ terminal.
+ [Source: BIG-LAN]
+
+ token ring
+ A token ring is a type of LAN with nodes wired into a ring. Each
+ node constantly passes a control message (token) on to the next;
+ whichever node has the token can send a message. Often, "Token
+ Ring" is used to refer to the IEEE 802.5 token ring standard,
+ which is the most common type of token ring. See also: 802.x,
+ Local Area Network.
+
+ topology
+ A network topology shows the computers and the links between them.
+ A network layer must stay abreast of the current network topology
+ to be able to route packets to their final destination.
+ [Source: MALAMUD]
+
+ traceroute
+ A program available on many systems which traces the path a packet
+ takes to a destination. It is mostly used to debug routing
+ problems between hosts. There is also a traceroute protocol
+ defined in RFC 1393.
+
+ Trans-European Research and Education Networking Association (TERENA)
+ TERENA was formed in October 1994 by the merger of RARE and EARN
+ to promote and participate in the development of a high quality
+ international information and telecommunications infrastructure
+ for the benefit of research and education. See also: Reseaux
+ Associes pour la Recherche Europeenne, European Academic and
+ Research Network.
+ [Source: TERENA Statutes]
+
+ transceiver
+ Transmitter-receiver. The physical device that connects a host
+ interface to a local area network, such as Ethernet. Ethernet
+ transceivers contain electronics that apply signals to the cable
+ and sense collisions.
+ [Source: RFC1208]
+
+ transit network
+ A transit network passes traffic between networks in addition to
+ carrying traffic for its own hosts. It must have paths to at
+
+
+
+Malkin Expires: 2Nov96 [Page 54]
+\f
+Internet Draft Glossary May 1996
+
+
+ least two other networks. See also: backbone, stub network.
+
+ Transmission Control Protocol (TCP)
+ An Internet Standard transport layer protocol defined in RFC 793.
+ It is connection-oriented and stream-oriented, as opposed to UDP.
+ See also: connection-oriented, stream-oriented, User Datagram
+ Protocol.
+
+ Trojan Horse
+ A computer program which carries within itself a means to allow
+ the creator of the program access to the system using it. See
+ also: virus, worm.
+
+ TTFN
+ Ta-Ta For Now
+
+ TTL
+ See: Time to Live
+
+ tunnelling
+ Tunnelling refers to encapsulation of protocol A within protocol
+ B, such that A treats B as though it were a datalink layer.
+ Tunnelling is used to get data between administrative domains
+ which use a protocol that is not supported by the internet
+ connecting those domains. See also: Administrative Domain.
+
+ twisted pair
+ A type of cable in which pairs of conductors are twisted together
+ to produce certain electrical properties.
+
+ UDP
+ See: User Datagram Protocol
+
+ unicast
+ An address which only one host will recognize. See also:
+ broadcast, multicast.
+
+ Uniform Resource Locators (URL)
+ A URL is a compact (most of the time) string representation for a
+ resource available on the Internet. URLs are primarily used to
+ retrieve information using WWW. The syntax and semantics for URLs
+ are defined in RFC 1738. See also: World Wide Web.
+
+ Universal Time Coordinated (UTC)
+ This is Greenwich Mean Time.
+ [Source: MALAMUD]
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 55]
+\f
+Internet Draft Glossary May 1996
+
+
+ UNIX-to-UNIX CoPy (UUCP)
+ This was initially a program run under the UNIX operating system
+ that allowed one UNIX system to send files to another UNIX system
+ via dial-up phone lines. Today, the term is more commonly used to
+ describe the large international network which uses the UUCP
+ protocol to pass news and electronic mail. See also: Electronic
+ Mail, Usenet.
+
+ urban legend
+ A story, which may have started with a grain of truth, that has
+ been embroidered and retold until it has passed into the realm of
+ myth. It is an interesting phenonmenon that these stories get
+ spread so far, so fast and so often. Urban legends never die,
+ they just end up on the Internet! Some legends that periodically
+ make their rounds include "The Infamous Modem Tax," "Craig
+ Shergold/Brain Tumor/Get Well Cards," and "The $250 Cookie
+ Recipe."
+ [Source: LAQUEY]
+
+ URL
+ See: Uniform Resource Locators
+
+ Usenet
+ A collection of thousands of topically named newsgroups, the
+ computers which run the protocols, and the people who read and
+ submit Usenet news. Not all Internet hosts subscribe to Usenet
+ and not all Usenet hosts are on the Internet. See also: Network
+ News Transfer Protocol, UNIX-to-UNIX CoPy.
+ [Source: NWNET]
+
+ User Datagram Protocol (UDP)
+ An Internet Standard transport layer protocol defined in RFC 768.
+ It is a connectionless protocol which adds a level of reliability
+ and multiplexing to IP. See also: connectionless, Transmission
+ Control Protocol.
+
+ UTC
+ See: Universal Time Coordinated
+
+ UUCP
+ See: UNIX-to-UNIX CoPy
+
+ uudecode
+ A program which reverses the effect of uuencode. See also:
+ uuencode.
+
+ uuencode
+ A program which reversibly converts a binary file in ASCII. It is
+
+
+
+Malkin Expires: 2Nov96 [Page 56]
+\f
+Internet Draft Glossary May 1996
+
+
+ used to send binary files via email, which generally does not
+ allow (or garbles) the transmission of binary information. The
+ original binary can be restored with uudecode. The encoding
+ process generally creates an ASCII file larger than the original
+ binary, so compressing the binary before running uuencode is
+ highly recommended.
+
+ Veronica
+ A Gopher utility which effectively searches Gopher servers based
+ on a user's list of keywords. The name was chosen to be a "mate"
+ to another utility named "Archie." It later became an acronym for
+ Very Easy Rodent Oriented Netwide Index to Computer Archives. See
+ also: archie, Gopher.
+
+ virtual circuit
+ A network service which provides connection-oriented service
+ without necessarily doing circuit-switching. See also:
+ connection-oriented.
+
+ virus
+ A program which replicates itself on computer systems by
+ incorporating itself into other programs which are shared among
+ computer systems. See also: Trojan Horse, worm.
+
+ W3
+ See: World Wide Web
+
+ WAIS
+ See: Wide Area Information Servers
+
+ WAN
+ See: Wide area network
+
+ WebCrawler
+ A WWW search engine. The aim of the WebCrawler Project is to
+ provide a high-quality, fast, and free Internet search service.
+ The WebCrawler may be reached at "http://webcrawler.com/".
+ [Source: WebCrawler's "WebCrawler Facts"]
+
+ WG
+ See: Working Group
+
+ white pages
+ The Internet supports several databases that contain basic
+ information about users, such as e-mail addresses, telephone
+ numbers, and postal addresses. These databases can be searched to
+ get information about particular individuals. Because they serve
+ a function akin to the telephone book, these databases are often
+
+
+
+Malkin Expires: 2Nov96 [Page 57]
+\f
+Internet Draft Glossary May 1996
+
+
+ referred to as "white pages." See also: Knowbot, netfind, whois,
+ X.500, InterNIC.
+
+ whois
+ An Internet program which allows users to query a database of
+ people and other Internet entities, such as domains, networks, and
+ hosts. The primary database is kept at the InterNIC. The
+ information stored includes a person's company name, address,
+ phone number and email address. The latest version of the
+ protocol, WHOIS++, is defined in RFCs 1834 and 1835. See also:
+ InterNIC, white pages, Knowbot, netfind, X.500.
+
+ Wide Area Information Servers (WAIS)
+ A distributed information service which offers simple natural
+ language input, indexed searching for fast retrieval, and a
+ "relevance feedback" mechanism which allows the results of initial
+ searches to influence future searches. Public domain
+ implementations are available. See also: archie, Gopher,
+ Prospero.
+
+ Wide Area Network (WAN)
+ A network, usually constructed with serial lines, which covers a
+ large geographic area. See also: Local Area Network, Metropolitan
+ Area Network.
+
+ Working Group (WG)
+ A working group, within the IETF, is a group of people who work
+ under a charter to achieve a certain goal. That goal may be the
+ creation of an Informational document, the creation of a protocol
+ specification, or the resolution of problems in the Internet.
+ Most working groups have a finite lifetime. That is, once a
+ working group has achieved its goal, it disbands. There is no
+ official membership for a working group. Unofficially, a working
+ group member is somebody who is on that working group's mailing
+ list; however, anyone may attend a working group meeting. See
+ also: Internet Engineering Task Force, Birds Of a Feather.
+
+ World Wide Web (WWW, W3)
+ A hypertext-based, distributed information system created by
+ researchers at CERN in Switzerland. Users may create, edit or
+ browse hypertext documents. The clients and servers are freely
+ available.
+
+ worm
+ A computer program which replicates itself and is self-
+ propagating. Worms, as opposed to viruses, are meant to spawn in
+ network environments. Network worms were first defined by Shoch &
+ Hupp of Xerox in ACM Communications (March 1982). The Internet
+
+
+
+Malkin Expires: 2Nov96 [Page 58]
+\f
+Internet Draft Glossary May 1996
+
+
+ worm of November 1988 is perhaps the most famous; it successfully
+ propagated itself on over 6,000 systems across the Internet. See
+ also: Trojan Horse, virus.
+
+ WRT
+ With Respect To
+
+ WWW
+ See: World Wide Web
+
+ WYSIWYG
+ What You See is What You Get
+
+ X
+ X is the name for TCP/IP based network-oriented window systems.
+ Network window systems allow a program to use a display on a
+ different computer. The most widely-implemented window system is
+ X11 - a component of MIT's Project Athena.
+
+ X.25
+ A data communications interface specification developed to
+ describe how data passes into and out of public data
+ communications networks. The CCITT and ISO approved protocol
+ suite defines protocol layers 1 through 3.
+
+ X.400
+ The CCITT and ISO standard for electronic mail. It is widely used
+ in Europe and Canada.
+
+ X.500
+ The CCITT and ISO standard for electronic directory services. See
+ also: white pages, Knowbot, whois.
+
+ XDR
+ See: eXternal Data Representation
+
+ Xerox Network System (XNS)
+ A protocol suite developed by Xerox Corporation to run on LAN and
+ WAN networks, where the LANs are typically Ethernet.
+ Implementations exist for both Xerox's workstations and 4.3BSD,
+ and 4.3BSD-derived, systems. XNS denotes not only the protocol
+ stack, but also an architecture of standard programming
+ interfaces, conventions, and service functions for authentication,
+ directory, filing, email, and remote procedure call. XNS is also
+ the name of Xerox's implementation. See also: Ethernet, Berkeley
+ Software Distribution, Local Area Network, Wide Area Network.
+ [Source: Jeff Hodges]
+
+
+
+
+Malkin Expires: 2Nov96 [Page 59]
+\f
+Internet Draft Glossary May 1996
+
+
+ XNS
+ See: Xerox Network System
+
+ Yahoo!
+
+ Yahoo! is a hierarchical subject-oriented guide for the World Wide
+ Web and Internet. Yahoo! lists sites and categorizes them into
+ appropriate subject categories. Yahoo! may be reached at
+ "http://www.yahoo.com/".
+ [Source: Yahoo's "What is Yahoo?"]
+
+ Yellow Pages (YP)
+ A historic (i.e., no longer in use) service used by UNIX
+ administrators to manage databases distributed across a network.
+
+ YP
+ See: Yellow Pages
+
+ zone
+ A logical group of network devices.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 60]
+\f
+Internet Draft Glossary May 1996
+
+
+References
+
+ BIG-LAN "BIG-LAN Frequently Asked Questions Memo", BIG-LAN DIGEST
+ V4:I8, February 14, 1992.
+
+ COMER Comer, Douglas, "Internetworking with TCP/IP: Principles,
+ Protocols and Architecture", Prentice Hall, Englewood Cliffs,
+ NJ, 1991.
+
+ FYI4 Malkin, G., A. Marine, "FYI on Questions and Answers: Answers
+ to Commonly asked "New Internet User" Questions", RFC 1325
+ (FYI 4), Xylogics, SRI, May 1992.
+
+ HACKER "THIS IS THE JARGON FILE", Version 2.9.8, January 1992.
+
+ HPCC "Grand Challenges 1993: High Performance Computing and
+ Communications", Committee on Physical, Mathmatical and
+ Engineering Sciences of the Federal Coordinating Council for
+ Science, Engineering and Technology.
+
+ MALAMUD Malamud, Carl, "Analyzing Sun Networks", Van Nostrand
+ Reinhold, New York, NY, 1992.
+
+ NNSC "NNSC's Hypercard Tour of the Internet".
+
+ LAQUEY LaQuey, Tracy, with Jeanne C. Ryer, "The Internet Companion:
+ A Beginner's Guide to Global Networking", Addison-Wesley,
+ Reading, MA, 1992.
+
+ NWNET Kochmer, Jonathan, and NorthWestNet, "The Internet Passport:
+ NorthWestNets Guide to Our World Online", NorthWestNet,
+ Bellevue, WA, 1992.
+
+ RFC1208 Jacobsen, O., D. Lynch, "A Glossary of Networking Terms", RFC
+ 1208, Interop, Inc., March 1991.
+
+ STD1 Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS", RFC 1920
+ (STD 1), March 1996.
+
+ STD2 Reynolds, J., J. Postel, "ASSIGNED NUMBERS", RFC 1700 (STD
+ 2), ISI, October 1994.
+
+ TAN Tanenbaum, Andrew S., "Computer Networks; 2nd ed.", Prentice
+ Hall, Englewood Cliffs, NJ, 1989.
+
+ ZEN Kehoe, Brendan P., "Zen and the Art of the Internet",
+ February 1992.
+
+
+
+
+Malkin Expires: 2Nov96 [Page 61]
+\f
+Internet Draft Glossary May 1996
+
+
+Security Considerations
+
+ While security is not explicitly discussed in this document, some of
+ the glossary's entries are security related. See the entries for
+ Access Control List (ACL), authentication, Computer Emergency
+ Response Team (CERT), cracker, Data Encryption Key (DEK), Data
+ Encryption Standard (DES), encryption, Kerberos, Message Digest (MD-
+ 2, MD-4, MD-5), Pretty Good Privacy (PGP), Privacy Enhanced Mail
+ (PEM), RSA, Trojan Horse, virus, and worm.
+
+
+Editor's Address
+
+ Gary Scott Malkin
+ Xylogics, Inc.
+ 53 Third Avenue
+ Burlington, MA 01803
+
+ Phone: (617) 238-6237
+ EMail: gmalkin@Xylogics.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Malkin Expires: 2Nov96 [Page 62]
--- /dev/null
+
+
+
+
+Network Working Group C. Newman
+Internet Draft: Date and Time on the Internet Innosoft
+Document: draft-newman-datetime-00.txt December 1996
+
+
+ Date and Time on the Internet
+
+
+Status of this memo
+
+ This document is an Internet Draft. Internet Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its Areas,
+ and its Working Groups. Note that other groups may also distribute
+ working documents as Internet Drafts.
+
+ Internet Drafts are draft documents valid for a maximum of six
+ months. Internet Drafts may be updated, replaced, or obsoleted by
+ other documents at any time. It is not appropriate to use Internet
+ Drafts as reference material or to cite them other than as a
+ ``working draft'' or ``work in progress``.
+
+ To learn the current status of any Internet-Draft, please check the
+ 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
+ Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
+ munnari.oz.au.
+
+ A revised version of this draft document will be submitted to the
+ IESG as a Proposed Standard for the Internet Community. Discussion
+ and suggestions for improvement are requested. This document will
+ expire six months after publication. Distribution of this draft is
+ unlimited.
+
+
+
+1. Introduction
+
+ Date and time formats cause a lot of confusion and interoperability
+ problems on the Internet. This document will address many of the
+ problems encountered and make recommendations to improve
+ consistancy and interoperability when representing and using date
+ and time in Internet protocols.
+
+ This document includes an Internet profile of the ISO 8601
+ [ISO8601] standard for representation of dates and times.
+
+ [More detail work is needed, but I wanted to get this out before I
+ go on vacation to see if it meets the basic requirements coming
+ from the ASID and CALSCH working groups. Places needing work are
+
+
+
+Newman [Page 1]
+\f
+Internet Draft Date and Time December 1996
+
+
+ marked with XXX]
+
+
+2. Definitions
+
+ UTC Coordinated Universal Time as maintained by the Bureau
+ Internaational de l'Heure (International Time Bureau).
+
+ [XXX definitely need more definitions here. It would be nice to
+ reference a good time standard to define seconds, leap years, etc.]
+
+3. Two or Three Digit Years
+
+ Two digit years are expected to cause great expense to many as the
+ year 2000 approaches. Many existing computer programs simply add
+ or subtract 1900 from a two digit year. Such programs will clearly
+ stop functioning on the year 2000 and will have to be upgraded,
+ possibly at great expense [XXX - ref to Wall Street Journal article
+ on IRS year 2000 problems would be cool]. The following
+ requirements are made of Internet protocols to address this
+ problem:
+
+ o Internet Protocols MUST generate four digit years in dates.
+
+ o If a two digit year is received, the values 00-49 SHOULD be
+ interpreted as referring to the 21st century (add 2000) and the
+ values 50-99 SHOULD be interpreted as referring to the 20th century
+ (add 1900).
+
+ o Three digit years MUST be interpreted by adding 1900.
+
+
+4. Local Time
+
+4.1. Coordinated Universal Time (UTC)
+
+ Because the daylight rules for local timezones are so convoluted
+ [XXX-ref], true interoperability is best achieved by using
+ Coordinated Universal Time (UTC) [XXX-ref].
+
+
+4.2. Local Offsets
+
+ The offset between local time and UTC is often useful information.
+ For example, in electronic mail [IMAIL] the local offset provides a
+ useful heuristic to determine the probability of a prompt response.
+ Attempts to label local offsets with alphabetic strings have met
+ with poor interoperability results in the past [IMAIL], [HOST-REQ].
+
+
+
+Newman [Page 2]
+\f
+Internet Draft Date and Time December 1996
+
+
+ Therefore numeric offsets are now REQUIRED. When the local offset
+ is unknown, the offset "-00:00" MAY be used to indicate that the
+ time is in UTC and the local offset is unknown.
+
+
+4.3. Unqualified Local Time
+
+ A number of devices currently connected to the Internet run their
+ internal clocks in local time and are unaware of UTC. While the
+ Internet does have a tradition of accepting reality when creating
+ specifications, this should not be done at the expense of
+ interoperability. Since interpretation of an unqualified local
+ timezone will fail in approximately 23/24 of the globe, the
+ interoperability problems of unqualified local time are deemed
+ unacceptable for the Internet. Devices which are unaware of the
+ time in UTC MUST use one of the following techniques when
+ communicating on the Internet:
+
+ o Use Network Time Protocol [NTP] to obtain the time in UTC.
+
+ o Use another host in the same local timezone as a gateway to the
+ Internet. This host MUST correct unqualified local times before
+ they are transmitted to other hosts.
+
+ o Prompt the user for the local timezone if it is aware of the
+ daylight rules. One technique to do this is by having the user
+ select a major city in their timezone. An alternative would be to
+ show a list of the timezone labels defined in [section XXX].
+
+
+5. Date and Time formats
+
+ The date and time format defined in [IMAIL] and as amended by
+ [HOST-REQ] may be referred to as "the Internet Mail Date/Time
+ Format". The profile of ISO 8601 defined in this section may be
+ referred to as "the Internet Date/Time Format". The following
+ sections describe useful properties of a date and time format for
+ interchange on the Internet.
+
+
+5.1. Ordering
+
+ If date and time components are ordered from least precise to most
+ precise, then a useful property is achieved. Assuming that the
+ timezones of the dates and times are the same (e.g. all in UTC),
+ then the date and time strings may be sorted as strings (e.g. using
+ the strcmp() function in C) and a time-ordered sequence will
+ result. The presence of optional punctuation would violate this
+
+
+
+Newman [Page 3]
+\f
+Internet Draft Date and Time December 1996
+
+
+ characteristic.
+
+
+5.2. Human Readability
+
+ Human readability has proved to be a valuable feature of Internet
+ protocols. Human readable protocols greatly reduce the costs of
+ debugging since telnet often suffices as a test client and network
+ analysers need not be modified with knowledge of the protocol. On
+ the other hand, human readability sometimes results in
+ interoperability problems. For example, the date format
+ "10/11/1996" is completely unsuitable for global interchange
+ because it is interpreted differently in different countries. In
+ addition, the date format in [IMAIL] has resulted in
+ interoperability problems when people assumed it was simply a text
+ string and translated the three letter abbreviations to other
+ languages or substituted date formats which were easier to generate
+ (e.g. the format used by the C function ctime). For this reason, a
+ balance must be struck between human readability and
+ interoperability.
+
+ Because no date and time format is readable according to the
+ conventions of all countries, Internet clients SHOULD be prepared
+ to transform dates into a display format suitable for the locality.
+ This includes translating UTC to local time.
+
+
+5.3. Simplicity
+
+ The complete set of date and time formats specified in ISO 8601
+ [ISO8601] is quite complex in an attempt to provide multiple
+ representations and partial representations. Appendix A contains
+ an attempt to translate the complete syntax of ISO 8601 into ABNF
+ as defined in [IMAIL]. Internet protocols have somewhat different
+ requirements and simplicity has proved to be an important
+ characteristic. In addition, Internet protocols usually need
+ complete specification of data in order to achieve true
+ interoperability. Therefore, the complete grammar for ISO 8601 is
+ deemed too complex for most Internet protocols.
+
+ The following section defines an profile of ISO 8601 for use on the
+ Internet. It is a conformant subset of the ISO 8601 extended
+ format. Simplicity is achieved by making most fields and
+ punctuation mandatory.
+
+
+5.4. Internet Date/Time Format
+
+
+
+
+Newman [Page 4]
+\f
+Internet Draft Date and Time December 1996
+
+
+ The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
+ new protocols on the Internet. This is specified using ABNF as
+ defined in [IMAIL].
+
+ date-fullyear = 4DIGIT
+ date-month = 2DIGIT ; 01-12
+ date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year
+ time-hour = 2DIGIT ; 00-24
+ time-minute = 2DIGIT ; 00-59
+ time-second = 2DIGIT ; 00-60
+ time-secfrac = "," 1*DIGIT
+ time-numzone = ("+" / "-") time-hour ":" time-minute
+ time-zone = "Z" / time-numzone
+
+ full-date = date-fullyear "-" date-month "-" date-mday
+ full-time = time-hour ":" time-minute ":" time-second
+ [time-secfrac] time-zone
+
+ date-time = full-date "T" full-time
+
+
+5.5 Examples
+
+ Here are two examples of this date and time format.
+
+ 1985-04-12T23:20:50,5Z
+
+ This represents 20 minutes and 50.5 seconds after 11 PM on April
+ 12th, 1985 in UTC.
+
+ 1996-12-19T16:39:57-08:00
+
+ This represents 39 minutes and 57 seconds after 4 PM on December
+ 19th, 1996 with an offset of -08:00 from UTC (Pacific Standard
+ Time).
+
+
+6. IANA Registry of Timezone Names
+
+ [XXX - put good stuff here]
+
+
+7. References
+
+[ISO8601] "Data elements and interchange formats -- Information
+interchange -- Representation of dates and times", ISO 8601:1988(E),
+International Organization for Standardization, June, 1988.
+
+
+
+
+Newman [Page 5]
+\f
+Internet Draft Date and Time December 1996
+
+
+[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
+ Messages", RFC 822, University of Delaware, August 1982.
+
+ <ftp://ds.internic.net/rfc/rfc822.txt>
+
+[HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application
+ and Support", RFC 1123, Internet Engineering Task Force, October 1989.
+
+ <ftp://ds.internic.net/rfc/rfc1123.txt>
+
+[NTP] Mills, D., "Network Time Protocol version 2 specification and
+ implementation", RFC 1119, September 1989.
+
+ <ftp://ds.internic.net/rfc/rfc1119.ps>
+
+
+8. Security Considerations
+
+ Since the local time zone of a site may be useful for determining a
+ time when systems are less likely to be monitored and might be more
+ susceptible to a security probe, some sites may wish to emit times
+ in UTC only. Others might consider this to be loss of useful
+ functionality at the hands of paranoia.
+
+
+9. Author's Address
+
+Chris Newman
+Innosoft International, Inc.
+1050 East Garvey Ave. South
+West Covina, CA 91790 USA
+
+Email: chris.newman@innosoft.com
+
+APPENDIX
+
+A. ISO 8601 Collected ABNF
+
+ ISO 8601 does not specify a formal grammar for the date and time
+ formats it defines. The following is an attempt to create a formal
+ grammar from ISO 8601. This is informational only and may contain
+ errors. ISO 8601 remains the authoratative reference for the
+ complete syntax.
+
+ date-century = 2DIGIT ; 00-99
+ date-decade = DIGIT ; 0-9
+ date-subdecade = DIGIT ; 0-9
+ date-year = date-decade date-subdecade
+
+
+
+Newman [Page 6]
+\f
+Internet Draft Date and Time December 1996
+
+
+ date-fullyear = date-century date-year
+ date-month = 2DIGIT ; 01-12
+ date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
+ date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on month/year
+ date-yday = 3DIGIT ; 001-365, 001-366 based on year
+ date-week = 2DIGIT ; 01-52, 01-53 based on year
+
+ datepart-fullyear = [date-century] date-year ["-"]
+ datepart-ptyear = "-" [date-subdecade ["-"]]
+ datepart-wkyear = datepart-ptyear / datepart-fullyear
+
+ dateopt-century = "-" / date-century
+ dateopt-fullyear = "-" / datepart-fullyear
+ dateopt-year = "-" / (date-year ["-"])
+ dateopt-month = "-" / (date-month ["-"])
+ dateopt-week = "-" / (date-week ["-"])
+
+ datespec-full = datepart-fullyear date-month ["-"] date-mday
+ datespec-year = date-century / dateopt-century date-year
+ datespec-month = "-" dateopt-year date-month [["-"] date-mday]
+ datespec-mday = "--" dateopt-month date-mday
+ datespec-week = datepart-wkyear "W" (date-week / dateopt-week date-wday)
+ datespec-wday = "---" date-wday
+ datespec-yday = dateopt-fullyear date-yday
+
+ date = datespec-full / datespec-year / datespec-month /
+ datespec-mday / datespec-week / datespec-wday / datespec-yday
+
+ Time:
+
+ time-hour = 2DIGIT ; 00-24
+ time-minute = 2DIGIT ; 00-59
+ time-second = 2DIGIT ; 00-60
+ time-fraction = ("," / ".") 1*DIGIT
+ time-numzone = ("+" / "-") time-hour [[":"] time-minute]
+ time-zone = "Z" / time-numzone
+
+ timeopt-hour = "-" / (time-hour [":"])
+ timeopt-minute = "-" / (time-minute [":"])
+
+ timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
+ timespec-minute = timeopt-hour time-minute [[":"] time-second]
+ timespec-second = "-" timeopt-minute time-second
+ timespec-base = timespec-hour / timespec-minute / timespec-second
+
+ time = timespec-base [time-fraction] [time-zone]
+
+ iso-date-time = date "T" time
+
+
+
+Newman [Page 7]
+\f
+Internet Draft Date and Time December 1996
+
+
+ Durations (periods):
+
+ dur-second = 1*DIGIT "S" dur-minute = 1*DIGIT "M"
+ [dur-second] dur-hour = 1*DIGIT "H" [dur-minute] dur-time
+ = "T" (dur-hour / dur-minute / dur-second) dur-day =
+ 1*DIGIT "D" dur-week = 1*DIGIT "W" dur-month =
+ 1*DIGIT "M" [dur-day] dur-year = 1*DIGIT "Y" [dur-month]
+ dur-date = (dur-day / dur-month / dur-year) [dur-time]
+
+ duration = "P" (dur-date / dur-time / dur-week)
+
+ Periods:
+
+ period-explicit = date-time "/" date-time period-start =
+ date-time "/" duration period-end = duration "/" date-time
+
+ period = period-explicit / period-start / period-end
+
+
+B. Zeller's Congruence [XXX-ref]
+
+ The following is sample C code which may be used to obtain the day
+ of the week:
+
+ char *dayofweek[] = {
+ "Sunday", "Monday", "Tuesday", "Wednesday",
+ "Thursday", "Friday", "Saturday"
+ };
+
+ void main()
+ {
+ int cent, year, day, month;
+
+ printf("Enter the year (4 digits): ");
+ scanf("%d", &year);
+ printf("\nEnter the month (1-12): ");
+ scanf("%d", &month);
+ printf("\nEnter the day of the month (1-31): ");
+ scanf("%d", &day);
+ month -= 2;
+ if (month < 1) {
+ month += 12;
+ year--;
+ }
+ cent = year / 100;
+ year %= 100;
+ printf("The day of the week is: %s\n",
+ dayofweek[((26 * month - 2) / 10 + day + year
+
+
+
+Newman [Page 8]
+\f
+Internet Draft Date and Time December 1996
+
+
+ + year / 4 + cent / 4 - 2 * cent) % 7]);
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman [Page 9]
+\f
--- /dev/null
+
+ Operational Requirements Area Paul Vixie (ISC)
+ INTERNET-DRAFT May, 1996
+ <draft-vixie-ops-stdaddr-00.txt>
+
+
+ Standard Electronic Mail Addresses For Internet Operations
+
+
+ Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ To learn the current status of any Internet-Draft, please check the
+ ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+
+ Abstract
+
+ This draft enumerates and describes standard electronic mail
+ addresses to be used when contacting the operations personnel of an
+ arbitrary domain.
+
+ As an operational standard, the recommendations herein pertain to
+ vendors only inasmuch as their end user documentation should
+ recommend that these mail addresses be aliased to appropriate end
+ user personnel.
+
+ This document should be advanced as a Best Current Practice, since it
+ describes what the current practice is and should be.
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 1]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 1 - Rationale and Scope
+
+ 1.1. Several previous RFC documents have specified electronic mail
+ addresses to be used when reaching the operators of the new service; for
+ example, [RFC822 6.3, C.6] requires the presence of a
+ <POSTMASTER@domain> address on all hosts that have an SMTP server.
+
+ 1.2. Other protocols have defacto standards for well known addresses,
+ such as <USENET@domain> for NNTP (see [RFC977]), and <WEBMASTER@domain>
+ for HTTP (see [HTTP]).
+
+ 1.3. Defacto standards also exist for well known addresses which have
+ nothing to do with a particular protocol, e.g., <ABUSE@domain> and
+ <TROUBLE@domain>.
+
+ 1.4. The purpose of this draft is to collect all of these well known
+ addresses in one place, add a few new ones, and ultimately recommend
+ that IANA carry these addresses in future editions of its Defined
+ Numbers periodical.
+
+ 2 - Definitions and Invariants
+
+ 2.1. The scope of a well known mail address is its domain name. Thus,
+ the mail exchangers (see [RFC974]) for a domain must handle well known
+ addresses even though some of these addresses might pertain to services
+ not offered by the mail exchanger hosts. So, for example, if an NNTP
+ server advertises the organization's top level domain in ``Path:''
+ headers (see [RFC977]), the mail exchangers for that top level domain
+ must accept mail to <USENET@domain> even if the mail exchanger hosts do
+ not serve the NNTP protocol.
+
+ 2.2. A host is not required to run its own SMTP server, but every host
+ that implements a protocol covered by a well known mail address should
+ have an MX RRset (see [RFC974]) and the mail exchangers specified by
+ this RRset should recognize this host's domain name as ``local'' for the
+ purpose of accepting mail bound for a well known address. Note that
+ this is true even if the advertised domain name is not the same as the
+ host's domain name; for example, if an NNTP server's host name is
+ DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
+ ``Path:'' headers, then mail must be deliverable to both
+ <USENET@VIX.COM> and <USENET@DATA.RAMONA.VIX.COM>.
+
+
+
+
+
+
+
+ Expires November 1996 [Page 2]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 2.3. For well known addresses that are not related to protocols, only
+ the organization's top level domain name need be valid. For example, if
+ an Internet service provider's domain name is NETCOM.COM, then the
+ <ABUSE@NETCOM.COM> address must be deliverable, even though the
+ customers whose activity generates complaints use hosts with more
+ specific domain names like SHELL1.NETCOM.COM.
+
+ 2.4. Well known addresses ought to be recognized independent of
+ character case. For example, POSTMASTER, postmaster, Postmaster,
+ PostMaster, and even PoStMaStEr should all be deliverable and should all
+ be delivered to the same mailbox.
+
+ 2.5. Most domains do not need the full set of well known addresses,
+ since not every domain will implement the protocols or offer the service
+ described by every well known address. If a given service is offerred,
+ then the relevant well known address(es) ought to be deliverable at all
+ advertised domain names.
+
+ 3 - Well Known Addresses
+
+ 3.1. Protocol Related Addresses
+
+ Address Protocol Standard(s)
+ --------------------------------------------------------
+ POSTMASTER SMTP [RFC821], [RFC822]
+ HOSTMASTER DNS [RFC1033], [RFC1034], [RFC1035]
+ USENET NNTP [RFC977]
+ WEBMASTER HTTP [HTTP]
+ UUCP UUCP [RFC976]
+ FTP FTP [RFC959]
+
+
+ 3.2. Protocol Independent Addresses
+
+ Address Operations Area Example Usage
+ ---------------------------------------------------------------
+ ABUSE Customer Relations Inappropriate public behaviour
+ NOC Network Operations Network infrastructure problem
+ SUPPORT Customer Support Product or service not working
+ SECURITY Network Security Security bulletins or queries
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 3]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 3.3. Optional, Less Well Known Addresses
+
+ Address Purpose
+ --------------------------------------------------------------
+ NIC DNS service (usually a synonym for HOSTMASTER)
+ WWW HTTP service (usually a synonym for WEBMASTER)
+ NEWS NNTP service (usually a synonym for USENET)
+ FTP-ADMIN FTP service (usually a synonym for FTP)
+ LISTOWNER Mailing list administration (prefer *-REQUEST)
+ TROUBLE Network operations (usually a synonym for NOC)
+ ROUTING Network operations (usually a synonym for NOC)
+ HELP Customer service (usually a synonym for SUPPORT)
+ ROOT Customer service (usually a synonym for SUPPORT)
+
+
+ 4 - Other Well Known Addresses
+
+ 4.1. Many mailing lists have an administrative address to which add/drop
+ requests and other metaqueries can be sent. For a mailing list whose
+ submission address is <LIST@DOMAIN>, the usual administrative address is
+ <LIST-REQUEST@DOMAIN>. With the advent of list management software such
+ as MajorDomo, this convention is becoming less common and its absence
+ for any given mailing list should be treated as a standards violation.
+ Make sure that your lists each have a *-REQUEST address and complain to
+ remote POSTMASTERs when you discover remote lists without *-REQUEST
+ addresses.
+
+ 4.2. Several Internet registries implement mailing lists for Autonomous
+ System contacts. So, for example, mail sent to <AS3557@RA.NET> will at
+ the time of this writing reach the technical contact for Autonomous
+ System 3557 in the BGP4 (see [RFC1654], [RFC1655] and [RFC1656]). Not
+ all Autonomous Systems are registered with all registries, however, and
+ so undeliverable addresses under this scheme should be treated as an
+ inconvenience rather than as an error or a standards violation.
+
+ 4.3. In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
+ Authority record (SOA RR) has a field for specifying the mail address of
+ the zone's administrator. This field should be a simple word without
+ metacharacters (such as ``%'' or ``!'' or ``::''), and a transport level
+ alias should be used on the relevant mail exchanger hosts to direct zone
+ administration mail to the appropriate mailbox. For simplicity and
+ regularity, it is hereby recommended that the well known address
+ HOSTMASTER always be used.
+
+
+
+
+
+ Expires November 1996 [Page 4]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 5 - Security Considerations
+
+ Denial of service attacks (flooding a mailbox with junk) will be easier
+ after this document becomes a standard.
+
+ 6 - References
+
+ [RFC821]
+ J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information
+ Sciences Institute, 08/01/1982
+
+ [RFC822]
+ D. Crocker, "Standard for the format of ARPA Internet text messages",
+ RFC 822, University of Delaware, 08/13/1982.
+
+ [RFC959]
+ J. Postel (et al), "File Transfer Protocol (FTP)", RFC 959,
+ Information Sciences Institute, October 1985.
+
+ [RFC974]
+ C. Partridge, "Mail routing and the domain system", RFC 974, CSNET
+ CIC BBN Laboratories Inc, 01/01/1986.
+
+ [RFC976]
+ M. Horton, "UUCP mail interchange format standard", RFC 976, Bell
+ Laboratories, 02/01/1986.
+
+ [RFC977]
+ B. Kantor (et al), "Network News Transfer Protocol: A Proposed
+ Standard for the Stream-Based Transmission of News", RFC 977,
+ University of California, February 1986.
+
+ [RFC1033]
+ M. Lottor, "Domain administrators operations guide", RFC 1033, SRI
+ International, 11/01/1987.
+
+ [RFC1034]
+ P. Mockapetris, "Domain names - concepts and facilities", RFC 1035,
+ USC/Information Sciences Institute, 11/01/1987.
+
+ [RFC1035]
+ P. Mockapetris, ``Domain Names - Implementation and Specification,''
+ RFC 1035, USC/Information Sciences Institute, November 1987.
+
+
+
+
+
+ Expires November 1996 [Page 5]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ [RFC1654]
+ Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP-4)", RFC 1654,
+ T.J. Watson Research Center, IBM Corp., 07/21/1994.
+
+ [RFC1655]
+ Y. Rekhter (et al), "Application of the Border Gateway Protocol in
+ the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp.,
+ 07/21/1994.
+
+ [RFC1656]
+ P. Traina, "BGP-4 Protocol Document Roadmap and Implementation
+ Experience", RFC 1656, cisco Systems, July 1994.
+
+ [HTTP]
+ T. Berners-Lee (et al), "Hypertext Transfer Protocol -- HTTP/1.0",
+ <draft-ietf-http-v10-spec-05.txt>, February 19, 1996.
+
+ 7 - Acknowledgements
+
+ Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D. Falk, Peter
+ Kaminski, and Brett Watson for their comments on this document.
+
+ 8 - Author's Address
+
+ Paul Vixie
+ Internet Software Consortium
+ Star Route Box 159A
+ Woodside, CA 94062
+ +1 415 747 0204
+ <paul@vix.com>
+
+
+ $Id: draft-vixie-ops-stdaddr-00.txt,v 1.1 2004/01/15 16:02:43 pere Exp $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 6]
+\f
+
--- /dev/null
+
+ Operational Requirements Area Paul Vixie (ISC)
+ INTERNET-DRAFT May, 1996
+ <draft-vixie-ops-stdaddr-01.txt>
+
+
+ Standard Electronic Mail Addresses For Internet Operations
+
+
+ Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ To learn the current status of any Internet-Draft, please check the
+ ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+
+ Abstract
+
+ This draft enumerates and describes standard electronic mail
+ addresses to be used when contacting the operations personnel of an
+ arbitrary domain.
+
+ As an operational standard, the recommendations herein pertain to
+ vendors only inasmuch as their end user documentation should
+ recommend that these mail addresses be aliased to appropriate end
+ user personnel.
+
+ This document should be advanced as a Best Current Practice, since it
+ describes what the current practice is and should be.
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 1]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 1 - Rationale and Scope
+
+ 1.1. Several previous RFC documents have specified electronic mail
+ addresses to be used when reaching the operators of the new service; for
+ example, [RFC822 6.3, C.6] requires the presence of a
+ <POSTMASTER@domain> address on all hosts that have an SMTP server.
+
+ 1.2. Other protocols have defacto standards for well known addresses,
+ such as <USENET@domain> for NNTP (see [RFC977]), and <WEBMASTER@domain>
+ for HTTP (see [HTTP]).
+
+ 1.3. Defacto standards also exist for well known addresses which have
+ nothing to do with a particular protocol, e.g., <ABUSE@domain> and
+ <TROUBLE@domain>.
+
+ 1.4. The purpose of this draft is to collect all of these well known
+ addresses in one place, add a few new ones, and ultimately recommend
+ that IANA carry these addresses in future editions of its Defined
+ Numbers periodical.
+
+ 2 - Definitions and Invariants
+
+ 2.1. The scope of a well known mail address is its domain name. Thus,
+ the mail exchangers (see [RFC974]) for a domain must handle well known
+ addresses even though some of these addresses might pertain to services
+ not offered by the mail exchanger hosts. So, for example, if an NNTP
+ server advertises the organization's top level domain in ``Path:''
+ headers (see [RFC977]), the mail exchangers for that top level domain
+ must accept mail to <USENET@domain> even if the mail exchanger hosts do
+ not serve the NNTP protocol.
+
+ 2.2. A host is not required to run its own SMTP server, but every host
+ that implements a protocol covered by a well known mail address should
+ have an MX RRset (see [RFC974]) and the mail exchangers specified by
+ this RRset should recognize this host's domain name as ``local'' for the
+ purpose of accepting mail bound for a well known address. Note that
+ this is true even if the advertised domain name is not the same as the
+ host's domain name; for example, if an NNTP server's host name is
+ DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
+ ``Path:'' headers, then mail must be deliverable to both
+ <USENET@VIX.COM> and <USENET@DATA.RAMONA.VIX.COM>, even though these
+ addresses might be delivered to different final destinations.
+
+
+
+
+
+
+ Expires November 1996 [Page 2]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 2.3. For well known addresses that are not related to protocols, only
+ the organization's top level domain name need be valid. For example, if
+ an Internet service provider's domain name is NETCOM.COM, then the
+ <ABUSE@NETCOM.COM> address must be deliverable, even though the
+ customers whose activity generates complaints use hosts with more
+ specific domain names like SHELL1.NETCOM.COM.
+
+ 2.4. Well known addresses ought to be recognized independent of
+ character case. For example, POSTMASTER, postmaster, Postmaster,
+ PostMaster, and even PoStMaStEr should all be deliverable and should all
+ be delivered to the same mailbox.
+
+ 2.5. Most domains do not need the full set of well known addresses,
+ since not every domain will implement the protocols or offer the service
+ described by every well known address. If a given service is offerred,
+ then the relevant well known address(es) ought to be deliverable at all
+ advertised domain names.
+
+ 2.6. Implementations of these well known addresses ought to take account
+ of the expectations of the senders who will use them. Sending back an
+ automatic e-mail acknowledgement would be a kindness (though we suggest
+ caution against the possibility of ``duelling mail robots'' and the
+ resulting mail loops). Some of these addresses can be satisfied by
+ same-day problem resolution (for example, FTP and WEBMASTER), whereas
+ some should be read and handled in real time by a redundant team (for
+ example, CERT and ABUSE).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 3]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 3 - Well Known Addresses
+
+ 3.1. Protocol Related Addresses
+
+ Address Protocol Standard(s)
+ --------------------------------------------------------
+ POSTMASTER SMTP [RFC821], [RFC822]
+ HOSTMASTER DNS [RFC1033], [RFC1034], [RFC1035]
+ USENET NNTP [RFC977]
+ WEBMASTER HTTP [HTTP]
+ UUCP UUCP [RFC976]
+ FTP FTP [RFC959]
+
+
+ 3.2. Protocol Independent Addresses
+
+ Address Operations Area Usage
+ --------------------------------------------------------------------
+ ABUSE Customer Relations Inappropriate public behaviour
+ TROUBLE Operations General/miscellaneous emergency
+ ROUTING Network Operations Network infrastructure emergency
+ NOC Network Operations Network infrastructure nonemergency
+ CERT Network Security Security emergencies in progress
+ SECURITY Network Security Security bulletins or queries
+
+
+ 3.3. Optional, Less Well Known Addresses
+
+ Address Operations Area Usage
+ -----------------------------------------------------------------------
+ NIC DNS service Usually a synonym for HOSTMASTER
+ WWW HTTP service Usually a synonym for WEBMASTER
+ NEWS NNTP service Usually a synonym for USENET
+ FTP-ADMIN FTP service Usually a synonym for FTP
+ LISTOWNER E-mail service Add/drop requests (prefer *-REQUEST)
+ SUPPORT Customer Service Product or service not working
+ HELP Customer Service Usually a synonym for SUPPORT
+ ROOT Customer Service Usually a synonym for SUPPORT
+ INFO Marketing Usually an e-mail autoresponder
+ SALES Sales ``Please sign me up for your service.''
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 4]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 4 - Other Well Known Addresses
+
+ 4.1. Many mailing lists have an administrative address to which add/drop
+ requests and other metaqueries can be sent. For a mailing list whose
+ submission address is <LIST@DOMAIN>, the usual administrative address is
+ <LIST-REQUEST@DOMAIN>. With the advent of list management software such
+ as MajorDomo, this convention is becoming less common and its absence
+ for any given mailing list should be treated as a standards violation.
+ Make sure that your lists each have a *-REQUEST address and complain to
+ remote POSTMASTERs when you discover remote lists without *-REQUEST
+ addresses.
+
+ 4.2. Several Internet registries implement mailing lists for Autonomous
+ System contacts. So, for example, mail sent to <AS3557@RA.NET> will at
+ the time of this writing reach the technical contact for Autonomous
+ System 3557 in the BGP4 (see [RFC1654], [RFC1655] and [RFC1656]). Not
+ all Autonomous Systems are registered with all registries, however, and
+ so undeliverable addresses under this scheme should be treated as an
+ inconvenience rather than as an error or a standards violation.
+
+ 4.3. In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
+ Authority record (SOA RR) has a field for specifying the mail address of
+ the zone's administrator. This field should be a simple word without
+ metacharacters (such as ``%'' or ``!'' or ``::''), and a transport level
+ alias should be used on the relevant mail exchanger hosts to direct zone
+ administration mail to the appropriate mailbox. For simplicity and
+ regularity, it is hereby recommended that the well known address
+ HOSTMASTER always be used.
+
+ 5 - Security Considerations
+
+ Denial of service attacks (flooding a mailbox with junk) will be easier
+ after this document becomes a standard.
+
+ 6 - References
+
+ [RFC821]
+ J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information
+ Sciences Institute, 08/01/1982
+
+ [RFC822]
+ D. Crocker, "Standard for the format of ARPA Internet text messages",
+ RFC 822, University of Delaware, 08/13/1982.
+
+
+
+
+
+ Expires November 1996 [Page 5]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ [RFC959]
+ J. Postel (et al), "File Transfer Protocol (FTP)", RFC 959,
+ Information Sciences Institute, October 1985.
+
+ [RFC974]
+ C. Partridge, "Mail routing and the domain system", RFC 974, CSNET
+ CIC BBN Laboratories Inc, 01/01/1986.
+
+ [RFC976]
+ M. Horton, "UUCP mail interchange format standard", RFC 976, Bell
+ Laboratories, 02/01/1986.
+
+ [RFC977]
+ B. Kantor (et al), "Network News Transfer Protocol: A Proposed
+ Standard for the Stream-Based Transmission of News", RFC 977,
+ University of California, February 1986.
+
+ [RFC1033]
+ M. Lottor, "Domain administrators operations guide", RFC 1033, SRI
+ International, 11/01/1987.
+
+ [RFC1034]
+ P. Mockapetris, "Domain names - concepts and facilities", RFC 1035,
+ USC/Information Sciences Institute, 11/01/1987.
+
+ [RFC1035]
+ P. Mockapetris, ``Domain Names - Implementation and Specification,''
+ RFC 1035, USC/Information Sciences Institute, November 1987.
+
+ [RFC1654]
+ Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP-4)", RFC 1654,
+ T.J. Watson Research Center, IBM Corp., 07/21/1994.
+
+ [RFC1655]
+ Y. Rekhter (et al), "Application of the Border Gateway Protocol in
+ the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp.,
+ 07/21/1994.
+
+ [RFC1656]
+ P. Traina, "BGP-4 Protocol Document Roadmap and Implementation
+ Experience", RFC 1656, cisco Systems, July 1994.
+
+ [HTTP]
+ T. Berners-Lee (et al), "Hypertext Transfer Protocol -- HTTP/1.0",
+ <draft-ietf-http-v10-spec-05.txt>, February 19, 1996.
+
+
+
+ Expires November 1996 [Page 6]
+\f
+ INTERNET-DRAFT STD ADDR May 1996
+
+
+ 7 - Acknowledgements
+
+ Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D. Falk, Peter
+ Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and Ed Morin for
+ their comments on this document.
+
+ 8 - Author's Address
+
+ Paul Vixie
+ Internet Software Consortium
+ Star Route Box 159A
+ Woodside, CA 94062
+ +1 415 747 0204
+ <paul@vix.com>
+
+
+ $Id: draft-vixie-ops-stdaddr-01.txt,v 1.1 2004/01/15 16:02:43 pere Exp $
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Expires November 1996 [Page 7]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group D. Raggett
+Request for Comments: 1942 W3C
+Category: Experimental May 1996
+
+
+ HTML Tables
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The HyperText Markup Language (HTML) is a simple markup language used
+ to create hypertext documents that are portable from one platform to
+ another. HTML documents are SGML documents with generic semantics
+ that are appropriate for representing information from a wide range
+ of applications. This specification extends HTML to support a wide
+ variety of tables. The model is designed to work well with associated
+ style sheets, but does not require them. It also supports rendering
+ to braille, or speech, and exchange of tabular data with databases
+ and spreadsheets. The HTML table model embodies certain aspects of
+ the CALS table model, e.g. the ability to group table rows into
+ thead, tbody and tfoot sections, plus the ability to specify cell
+ alignment compactly for sets of cells according to the context.
+
+Table of Contents
+
+ Recent Changes ................................................. 1
+ Brief Introduction ............................................. 2
+ Design Rationale ............................................... 5
+ Walkthrough of the Table DTD ................................... 8
+ Recommended Layout Algorithms ................................. 23
+ HTML Table DTD ................................................ 26
+ References .................................................... 29
+ Security Considerations ....................................... 30
+ Author's Address .............................................. 30
+
+Recent Changes
+
+ This specification extends HTML to support tables. The table model
+ has grown out of early work on HTML+ and the initial draft of HTML3.
+ The earlier model has been been extended in response to requests from
+ information providers for improved control over the presentation of
+ tabular information:
+
+
+
+Raggett Experimental [Page 1]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ * alignment on designated characters such as "." and ":"
+ e.g. aligning a column of numbers on the decimal point
+
+ * more flexibility in specifying table frames and rules
+
+ * incremental display for large tables as data is received
+
+ * the ability to support scrollable tables with fixed headers plus
+ better support for breaking tables across pages for printing
+
+ * optional column based defaults for alignment properties
+
+ In addition, a major goal has been to provide backwards compatibility
+ with the widely deployed Netscape implementation of tables. A
+ subsidiary goal has been to simplify importing tables conforming to
+ the SGML CALS model. The latest draft makes the ALIGN attribute
+ compatible with the latest Netscape and Microsoft browsers. Some
+ clarifications have been made to the role of the DIR attribute and
+ recommended behaviour when absolute and relative column widths are
+ mixed.
+
+ A new element COLGROUP has been introduced to allow sets of columns
+ be grouped with different width and alignment properties specified by
+ one or more COL elements. The semantics of COLGROUP have been
+ clarified over previous drafts, and RULES=BASIC replaced by
+ RULES=GROUPS.
+
+ The FRAME and RULES attributes have been modified to avoid SGML name
+ clashes with each other, and to avoid clashes with the ALIGN and
+ VALIGN attributes. These changes were additionally motivated by the
+ desire to avoid future problems if this specification is extended to
+ allow FRAME and RULES attributes with other table elements.
+
+A Brief Introduction to HTML Tables
+
+ Tables start with an optional caption followed by one or more rows.
+ Each row is formed by one or more cells, which are differentiated
+ into header and data cells. Cells can be merged across rows and
+ columns, and include attributes assisting rendering to speech and
+ braille, or for exporting table data into databases. The model
+ provides limited support for control over appearence, for example
+ horizontal and vertical alignment of cell contents, border styles and
+ cell margins. You can further affect this by grouping rows and
+ columns together. Tables can contain a wide range of content, such as
+ headers, lists, paragraphs, forms, figures, preformatted text and
+ even nested tables.
+
+
+
+
+
+Raggett Experimental [Page 2]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+Example
+
+ <TABLE BORDER>
+ <CAPTION>A test table with merged cells</CAPTION>
+ <TR><TH ROWSPAN=2><TH COLSPAN=2>Average
+ <TH ROWSPAN=2>other<BR>category<TH>Misc
+ <TR><TH>height<TH>weight
+ <TR><TH ALIGN=LEFT>males<TD>1.9<TD>0.003
+ <TR><TH ALIGN=LEFT ROWSPAN=2>females<TD>1.7<TD>0.002
+ </TABLE>
+
+ On a dumb terminal, this would be rendered something like:
+
+ A test table with merged cells
+ /--------------------------------------------------\
+ | | Average | other | Misc |
+ | |-------------------| category |--------|
+ | | height | weight | | |
+ |-----------------------------------------|--------|
+ | males | 1.9 | 0.003 | | |
+ |-----------------------------------------|--------|
+ | females | 1.7 | 0.002 | | |
+ \--------------------------------------------------/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raggett Experimental [Page 3]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ Next, a richer example with grouped rows and columns (adapted from
+ "Developing International Software" by Nadine Kano). First here is
+ what the table looks like on paper:
+
+ CODE-PAGE SUPPORT IN MICROSOFT WINDOWS
+========================================================================
+Code-Page| Name |ACP OEMCP| Windows Windows Windows
+ ID | | | NT 3.1 NT 3.51 95
+------------------------------------------------------------------------
+ 1200 |Unicode (BMP of ISO 10646) | | X X *
+ 1250 |Windows 3.1 East. Europe | X | X X X
+ 1251 |Windows 3.1 Cyrillic | X | X X X
+ 1252 |Windows 3.1 US (ANSI) | X | X X X
+ 1253 |Windows 3.1 Greek | X | X X X
+ 1254 |Windows 3.1 Turkish | X | X X X
+ 1255 |Hebrew | X | X
+ 1256 |Arabic | X | X
+ 1257 |Baltic | X | X
+ 1361 |Korean (Johab) | X | ** X
+------------------------------------------------------------------------
+ 437 |MS-DOS United States | X | X X X
+ 708 |Arabic (ASMO 708) | X | X
+ 709 |Arabic (ASMO 449+, BCON V4)| X | X
+ 710 |Arabic (Transparent Arabic)| X | X
+ 720 |Arabic (Transparent ASMO) | X | X
+========================================================================
+
+ The markup for this uses COLGROUP elements to group columns and to
+ set default column alignment. TBODY elements are used to group rows.
+ The FRAME and RULES attributes are used to select which borders to
+ render.
+
+ <table border=2 frame=hsides rules=groups>
+ <caption>CODE-PAGE SUPPORT IN MICROSOFT WINDOWS</caption>
+ <colgroup align=center>
+ <colgroup align=left>
+ <colgroup align=center span=2>
+ <colgroup align=center span=3>
+ <thead valign=top>
+ <tr>
+ <th>Code-Page<br>ID
+ <th>Name
+ <th>ACP
+ <th>OEMCP
+ <th>Windows<br>NT 3.1
+ <th>Windows<br>NT 3.51
+ <th>Windows<br>95
+ <tbody>
+
+
+
+Raggett Experimental [Page 4]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ <tr><td>1200<td>Unicode (BMP of ISO 10646)<td><td><td>X<td>X<TD>*
+ <tr><td>1250<td>Windows 3.1 Eastern European<td>X<td><td>X<td>X<TD>X
+ <tr><td>1251<td>Windows 3.1 Cyrillic<td>X<td><td>X<td>X<TD>X
+ <tr><td>1252<td>Windows 3.1 US (ANSI)<td>X<td><td>X<td>X<TD>X
+ <tr><td>1253<td>Windows 3.1 Greek<td>X<td><td>X<td>X<TD>X
+ <tr><td>1254<td>Windows 3.1 Turkish<td>X<td><td>X<td>X<TD>X
+ <tr><td>1255<td>Hebrew<td>X<td><td><td><td>X
+ <tr><td>1256<td>Arabic<td>X<td><td><td><td>X
+ <tr><td>1257<td>Baltic<td>X<td><td><td><td>X
+ <tr><td>1361<td>Korean (Johab)<td>X<td><td><td>**<td>X
+ <tbody>
+ <tr><td>437<td>MS-DOS United States<td><td>X<td>X<td>X<TD>X
+ <tr><td>708<td>Arabic (ASMO 708)<td><td>X<td><td><td>X
+ <tr><td>709<td>Arabic (ASMO 449+, BCON V4)<td><td>X<td><td><td>X
+ <tr><td>710<td>Arabic (Transparent Arabic)<td><td>X<td><td><td>X
+ <tr><td>720<td>Arabic (Transparent ASMO)<td><td>X<td><td><td>X
+ </table>
+
+Design Rationale
+
+ The HTML table model has evolved from studies of existing SGML tables
+ models, the treatment of tables in common word processing packages,
+ and looking at a wide range of tabular layout in magazines, books and
+ other paper-based documents. The model was chosen to allow simple
+ tables to be expressed simply with extra complexity only when needed.
+ This makes it practical to create the markup for HTML tables with
+ everyday text editors and reduces the learning curve for getting
+ started. This feature has been very important to the success of HTML
+ to date.
+
+ Increasingly people are using filters from other document formats or
+ direct wysiwyg editors for HTML. It is important that the HTML table
+ model fits well with these routes for authoring HTML. This affects
+ how the representation handles cells which span multiple rows or
+ columns, and how alignment and other presentation properties are
+ associated with groups of cells.
+
+ A major consideration for the HTML table model is that the fonts and
+ window sizes etc. in use with browsers are not under the author's
+ control. This makes it risky to rely on column widths specified in
+ terms of absolute units such as picas or pixels. Instead, tables can
+ be dynamically sized to match the current window size and fonts.
+ Authors can provide guidance as to the relative widths of columns,
+ but user agents should to ensure that columns are wide enough to
+ render the width of the largest single element of the cell's content.
+ If the author's specification must be overridden, it is preferred
+ that the relative widths of individual columns are not changed
+ drastically.
+
+
+
+Raggett Experimental [Page 5]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ For large tables or slow network connections, it is desirable to be
+ able to start displaying the table before all of the data has been
+ received. The default window width for most user agents shows about
+ 80 characters, and the graphics for many HTML pages are designed with
+ these defaults in mind. Authors can provide a hint to user agents to
+ activate incremental display of table contents. This feature requires
+ the author to specify the number of columns, and includes provision
+ for control of table width and the widths of different columns in
+ relative or absolute terms.
+
+ For incremental display, the browser needs the number of columns and
+ their widths. The default width of the table is the current window
+ size (width="100%"). This can be altered by including a WIDTH
+ attribute in the TABLE start tag. By default all columns have the
+ same width, but you can specify column widths with one or more COL
+ elements before the table data starts.
+
+ The remaining issue is the number of columns. Some people have
+ suggested waiting until the first row of the table has been received,
+ but this could take a long time if the cells have a lot of content.
+ On the whole it makes more sense, when incremental display is
+ desired, to get authors to explicitly specify the number of columns
+ in the TABLE start tag.
+
+ Authors still need a way of informing the browser whether to use
+ incremental display or to automatically size the table to match the
+ cell contents. For the two pass auto sizing mode, the number of
+ columns is determined by the first pass, while for the incremental
+ mode, the number of columns needs to be stated up front. So it seems
+ to that COLS=_nn_ would be better for this purpose than a LAYOUT
+ attribute such as LAYOUT=FIXED or LAYOUT=AUTO.
+
+ It is generally held useful to consider documents from two
+ perspectives: Structural idioms such as headers, paragraphs, lists,
+ tables, and figures; and rendering idioms such as margins, leading,
+ font names and sizes. The wisdom of past experience encourages us to
+ separate the structural information in documents from rendering
+ information. Mixing them together ends up causing increased cost of
+ ownership for maintaining documents, and reduced portability between
+ applications and media.
+
+ For tables, the alignment of text within table cells, and the borders
+ between cells are, from the purist's point of view, rendering
+ information. In practice, though, it is useful to group these with
+ the structural information, as these features are highly portable
+ from one application to the next. The HTML table model leaves most
+ rendering information to associated style sheets. The model is
+ designed to take advantage of such style sheets but not to require
+
+
+
+Raggett Experimental [Page 6]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ them.
+
+ This specification provides a superset of the simpler model presented
+ in earlier work on HTML+. Tables are considered as being formed from
+ an optional caption together with a sequence of rows, which in turn
+ consist of a sequence of table cells. The model further
+ differentiates header and data cells, and allows cells to span
+ multiple rows and columns.
+
+ Following the CALS table model, this specification allows table rows
+ to be grouped into head and body and foot sections. This simplifies
+ the representation of rendering information and can be used to repeat
+ table head and foot rows when breaking tables across page boundaries,
+ or to provide fixed headers above a scrollable body panel. In the
+ markup, the foot section is placed before the body sections. This is
+ an optimization shared with CALS for dealing with very long tables.
+ It allows the foot to be rendered without having to wait for the
+ entire table to be processed.
+
+ For the visually impaired, HTML offers the hope of setting to rights
+ the damage caused by the adoption of windows based graphical user
+ interfaces. The HTML table model includes attributes for labeling
+ each cell, to support high quality text to speech conversion. The
+ same attributes can also be used to support automated import and
+ export of table data to databases or spreadsheets.
+
+ Current desktop publishing packages provide very rich control over
+ the rendering of tables, and it would be impractical to reproduce
+ this in HTML, without making HTML into a bulky rich text format like
+ RTF or MIF. This specification does, however, offer authors the
+ ability to choose from a set of commonly used classes of border
+ styles. The FRAME attribute controls the appearence of the border
+ frame around the table while the RULES attribute determines the
+ choice of rulings within the table.
+
+ During the development of this specification, a number of avenues
+ were investigated for specifying the ruling patterns for tables. One
+ issue concerns the kinds of statements that can be made. Including
+ support for edge subtraction as well as edge addition leads to
+ relatively complex algorithms. For instance work on allowing the full
+ set of table elements to include the FRAME and RULES attributes led
+ to an algorithm involving some 24 steps to determine whether a
+ particular edge of a cell should be ruled or not. Even this
+ additional complexity doesn't provide enough rendering control to
+ meet the full range of needs for tables. The current specification
+ deliberately sticks to a simple intuitive model, sufficient for most
+ purposes. Further experimental work is needed before a more complex
+ approach is standardized.
+
+
+
+Raggett Experimental [Page 7]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+A walk through the table DTD
+
+ The table document type definition provides the formal definition of
+ the allowed syntax for html tables. The following is an annotated
+ listing of the DTD. The complete listing appears at the end of this
+ document.
+
+ Note that the TABLE element is a block-like element rather a
+ character-level element. As such it is a peer of other HTML block-
+ like elements such as paragraphs, lists and headers.
+
+Common Attributes
+
+ The following attributes occur in several of the elements and are
+ defined here for brevity. In general, all attribute names and values
+ in this specification are case insensitive, except where noted
+ otherwise. The ID, CLASS and attributes are required for use with
+ style sheets, while LANG and DIR are needed for internationalization.
+
+ <!ENTITY % attrs
+ "id ID #IMPLIED -- element identifier --
+ class NAMES #IMPLIED -- for subclassing elements --
+ lang NAME #IMPLIED -- as per RFC 1766 --
+ dir (ltr|rtl) #IMPLIED -- I18N text direction --">
+
+ ID
+ Used to define a document-wide identifier. This can be used for
+ naming positions within documents as the destination of a
+ hypertext link. It may also be used by style sheets for
+ rendering an element in a unique style. An ID attribute value is
+ an SGML NAME token. NAME tokens are formed by an initial letter
+ followed by letters, digits, "-" and "." characters. The letters
+ are restricted to A-Z and a-z.
+
+ CLASS
+ A space separated list of SGML NAME tokens. CLASS names specify
+ that the element belongs to the corresponding named classes. It
+ allows authors to distinguish different roles played by the same
+ tag. The classes may be used by style sheets to provide
+ different renderings as appropriate to these roles.
+
+ LANG
+ A LANG attribute identifies the natural language used by the
+ content of the associated element.The syntax and registry of
+ language values are defined by RFC 1766. In summary the language
+ is given as a primary tag followed by zero or more subtags,
+ separated by "-". White space is not allowed and all tags are
+ case insensitive. The name space of tags is administered by
+
+
+
+Raggett Experimental [Page 8]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ IANA. The two letter primary tag is an ISO 639 language
+ abbreviation, while the initial subtag is a two letter ISO 3166
+ country code. Example values for LANG include:
+
+ en, en-US, en-uk, i-cherokee, x-pig-latin.
+
+ DIR
+ Human writing systems are grouped into scripts, which determine
+ amongst other things, the direction the characters are written.
+ Elements of the Latin script are nominally left to right, while
+ those of the Arabic script are nominally right to left. These
+ characters have what is called strong directionality. Other
+ characters can be directionally neutral (spaces) or weak
+ (punctuation).
+
+ The DIR attribute specifies an encapsulation boundary which
+ governs the interpretation of neutral and weakly directional
+ characters. It does not override the directionality of strongly
+ directional characters. The DIR attribute value is one of LTR
+ for left to right, or RTL for right to left, e.g. DIR=RTL.
+
+ When applied to TABLE, it indicates the geometric layout of rows
+ (i.e. row 1 is on right if DIR=RTL, but on the left if DIR=LTR)
+ and it indicates a default base directionality for any text in
+ the table's content if no other DIR attribute applies to that
+ text.
+
+Horizontal and Vertical Alignment Attributes
+
+ The alignment of cell contents can be specified on a cell by cell
+ basis, or inherited from enclosing elements, such as the row, column
+ or the table element itself.
+
+ ALIGN
+ This specifies the horizontal alignment of cell contents.
+
+ <!-- horizontal alignment attributes for cell contents -->
+ <!ENTITY % cell.halign
+ "align (left|center|right|justify|char) #IMPLIED
+ char CDATA #IMPLIED -- alignment char, e.g. char=':' --
+ charoff CDATA #IMPLIED -- offset for alignment char --"
+ >
+
+ The attribute value should be one of LEFT, CENTER, RIGHT,
+ JUSTIFY and CHAR. User agents may treat JUSTIFY as left
+ alignment if they lack support for text justification.
+ ALIGN=CHAR is used for aligning cell contents on a particular
+ character.
+
+
+
+Raggett Experimental [Page 9]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ For cells spanning multiple rows or columns, where the alignment
+ property is inherited from the row or column, the initial row
+ and column for the cell determines the appropriate alignment
+ property to use.
+
+ Note that an alignment attribute on elements within the cell,
+ e.g. on a P element, overrides the normal alignment value for
+ the cell.
+
+ CHAR
+ This is used to specify an alignment character for use with
+ align=char, e.g. char=":". The default character is the decimal
+ point for the current language, as set by the LANG attribute.
+ The CHAR attribute value is case sensitive.
+
+ CHAROFF
+ Specifies the offset to the first occurrence of the alignment
+ character on each line. If a line doesn't include the alignment
+ character, it should be horizontally shifted to end at the
+ alignment position. The resolved direction of the cell, as
+ determined by the inheritance of the DIR attribute, is used to
+ set whether the offset is from the left or right margin of the
+ cell. For Latin scripts, the offset will be from the left
+ margin, while for Arabic scripts, it will be from the right
+ margin. In addition to standard units, the "%" sign may be used
+ to indicate that the value specifies the alignment position as a
+ percentage offset of the current cell, e.g. CHAROFF="30%"
+ indicates the alignment character should be positioned 30%
+ through the cell.
+
+ When using the two pass layout algorithm, the default alignment
+ position in the absence of an explicit or inherited CHAROFF
+ attribute can be determined by choosing the position that would
+ center lines for which the width before and after the alignment
+ character are at the maximum values for any of the lines in the
+ column for which ALIGN=CHAR. For incremental table layout the
+ suggested default is CHAROFF="50%". If several cells in
+ different rows for the same column use character alignment, then
+ by default, all such cells should line up, regardless of which
+ character is used for alignment. Rules for handling objects too
+ large for column apply when the explicit or implied alignment
+ results in a situation where the data exceeds the assigned width
+ of the column.
+
+ VALIGN
+ Defines whether the cell contents are aligned with the top,
+ middle or bottom of the cell.
+
+
+
+
+Raggett Experimental [Page 10]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ <!-- vertical alignment attributes for cell contents -->
+ <!ENTITY % cell.valign
+ "valign (top|middle|bottom|baseline) #IMPLIED"
+ >
+
+ If present, the value of the attribute should be one of: TOP,
+ MIDDLE, BOTTOM or BASELINE. All cells in the same row with
+ valign=baseline should be vertically positioned so that the
+ first text line in each such cell occur on a common baseline.
+ This constraint does not apply to subsequent text lines in these
+ cells.
+
+Inheritance Order
+
+ Alignment properties can be included with most of the table elements:
+ COL, THEAD, TBODY, TFOOT, TR, TH and TD. When rendering cells,
+ horizontal alignment is determined by columns in preference to rows,
+ while for vertical alignment, the rows are more important than the
+ columns. The following table gives the detailed precedence order for
+ each attribute, where X > Y denotes that X takes precedence over Y:
+
+ ALIGN, CHAR and CHAROFF:
+
+ cells > columns > column groups > rows > row groups > default
+
+ VALIGN, LANG, and DIR:
+
+ cells > rows > row groups > columns > column groups > table > default
+
+ Where cells are defined by TH and TD elements; rows by TR elements;
+ row groups by THEAD, TBODY and TFOOT elements, columns by COL
+ elements; and column groups by COLGROUP and COL elements. Note that
+ there is no inheritance mechanism for the CLASS attribute.
+
+ Properties defined on cells take precedence over inherited
+ properties, but are in turn over-ridden by alignment properties on
+ elements within cells. In the absence of an ALIGN attribute along the
+ inheritance path, the recommended default alignment for table cell
+ contents is ALIGN=LEFT for table data and ALIGN=CENTER for table
+ headers. The recommended default for vertical alignment is
+ VALIGN=MIDDLE. These defaults are chosen to match the behaviour of
+ the widely deployed Netscape implementation.
+
+Standard Units for Widths
+
+ Several attributes specify widths as a number followed by an optional
+ suffix. The units for widths are specified by the suffix: pt denotes
+ points, pi denotes picas, in denotes inches, cm denotes centimeters,
+
+
+
+Raggett Experimental [Page 11]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ mm denotes millimeters, em denotes em units (equal to the height of
+ the default font), and px denotes screen pixels. The default units
+ are screen pixels (chosen for backwards compatibility). The number is
+ an integer value or a real valued number such as "2.5". Exponents, as
+ in "1.2e2", are not allowed. White space is not allowed between the
+ number and the suffix.
+
+ The above set of suffices is augmented for certain elements: "%" is
+ used for the WIDTH attribute for the TABLE element. It indicates that
+ the attribute specifies the percentage width of the space between the
+ current left and right margins, e.g. width="50%". For the COL
+ element, "*" is used with the WIDTH attribute to specify relative
+ column widths, e.g. width="3*", using the same representation as the
+ CALS table model.
+
+The TABLE element
+
+<!ENTITY % Where "(left|center|right)">
+
+<!ELEMENT table - - (caption?, (col*|colgroup*), thead?, tfoot?, tbody+)>
+
+<!ATTLIST table -- table element --
+ %attrs; -- id, lang, dir and class --
+ align %Where; #IMPLIED -- table position relative to --
+ -- window --
+ width CDATA #IMPLIED -- table width relative to window --
+ cols NUMBER #IMPLIED -- used for immediate display mode --
+ border CDATA #IMPLIED -- controls frame width around --
+ -- table --
+ frame %Frame; #IMPLIED -- which parts of table frame to --
+ -- include --
+ rules %Rules; #IMPLIED -- controls rules between cells --
+ cellspacing CDATA #IMPLIED -- spacing between cells --
+ cellpadding CDATA #IMPLIED -- spacing within cells --
+ >
+
+ The TABLE element requires both start and end tags. Table elements
+ start with an optional CAPTION element, optionally followed by either
+ one or more COL elements, or one or more COLGROUP elements, then an
+ optional THEAD, an optional TFOOT, and finally one or more TBODY
+ elements.
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ ALIGN
+ Defines the horizontal position of the table relative to the
+ current left and right margins. ALIGN=CENTER centers the table
+
+
+
+Raggett Experimental [Page 12]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ midway between the left and right margins. ALIGN=LEFT positions
+ the table at the left margin, while ALIGN=RIGHT positions the
+ table at the right margin. User agents may flow text around the
+ right handside of the table for ALIGN=LEFT, or the left handside
+ for ALIGN=RIGHT.
+
+ Note you can use <BR CLEAR=LEFT> after the table element if you
+ want to avoid text flowing along side the table when you have
+ specified ALIGN=LEFT, or <BR CLEAR=RIGHT> for a right aligned
+ table. To prevent a right aligned table flowing around something
+ else, use <BR CLEAR=RIGHT> before the table etc. Greater control
+ over textflow is possible using style sheets.
+
+ WIDTH
+ Specifies the desired width of the table. In addition to the
+ standard units, the "%" sign may used to indicate that the width
+ specifies the percentage width of the space between the current
+ left and right margins, e.g. width="50%". In the absence of this
+ attribute, the table width can be determined by the layout
+ algorithm given later on.
+
+ It is recommended that the table width be increased beyond the
+ value indicated by the WIDTH attribute as needed to avoid any
+ overflow of cell contents. Such increases should try to avoid
+ drastic changes to relative column widths specified by the
+ author. To avoid the need for excessive horizontal scrolling, or
+ when such scrolling is impractical or undesired, it may be
+ appropriate to split words across lines.
+
+ COLS
+ Specifies the number of columns for the table. If present the
+ user agent may render the table dynamically as data is received
+ from the network without waiting for the complete table to be
+ received. If the WIDTH attribute is missing, a default of "100%"
+ may be assumed for this purpose. If the COLS attribute is
+ absent, a prepass through the table's contents is needed to
+ determine the number of columns together with suitable values
+ for the widths of each column.
+
+ BORDER
+ Specifies the width of the border framing the table, see
+ standard units.
+
+ FRAME
+ Specifies which sides of the frame to render.
+
+ <!ENTITY % Frame
+ "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
+
+
+
+Raggett Experimental [Page 13]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ VOID
+ Don't render any sides of the frame.
+
+ ABOVE
+ The top side of the frame
+
+ BELOW
+ The bottom side of the frame
+
+ HSIDES
+ The top and bottom sides of the frame
+
+ LHS
+ The left hand side of the frame
+
+ RHS
+ The right hand side of the frame
+
+ VSIDES
+ The left and right sides of the frame
+
+ BOX
+ All four sides of the frame
+
+ BORDER
+ All four sides of the frame
+
+ The value "Border" is included for backwards compatibility with
+ deployed browsers. If a document includes <TABLE BORDER> the
+ user agent will see FRAME=BORDER and BORDER=_implied_. If the
+ document includes <TABLE BORDER=_n_> then the user agent should
+ treat this as FRAME=BORDER except if _n=0_ for which FRAME=VOID
+ is appropriate.
+
+ Note: it would have been preferable to choose values for FRAME
+ consistent with the RULES attribute and the values used for
+ alignment. For instance: none, top, bottom, topbot, left, right,
+ leftright, all. Unfortunately, SGML requires enumerated
+ attribute values to be unique for each element, independent of
+ the attribute name. This causes immediate problems for "none",
+ "left", "right" and "all". The values for FRAME have been chosen
+ to avoid clashes with the RULES, ALIGN and VALIGN attributes.
+ This provides a measure of future proofing, as it is anticipated
+ that that the FRAME and RULES attributes will be added to other
+ table elements in future revisions to this specification. An
+ alternative would be to make FRAME a CDATA attribute. The
+ consensus of the HTML-WG was that the benefits of being able to
+ use SGML validation tools to check attributes based on
+
+
+
+Raggett Experimental [Page 14]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ enumerated values outweighs the need for consistent names.
+
+ RULES
+ Specifies where to draw rules within the table interior.
+
+ <!ENTITY % Rules "(none | groups | rows | cols | all)">
+
+ NONE
+ Suppresses internal rulings.
+
+ GROUPS
+ The THEAD, TFOOT and TBODY elements divide the table into
+ groups of rows, while COLGROUP elements divide the table
+ into groups of columns. This choice places a horizontal rule
+ between each row group and a vertical rule between each
+ column group. Note that every table has at least one row and
+ one column group.
+
+ ROWS
+ As RULES=GROUPS plus horizontal rules between all rows. User
+ agents may choose to use a heavier rule between groups of
+ rows and columns for emphasis.
+
+ COLS
+ As RULES=GROUPS plus vertical rules between all columns.
+ User agents may choose to use a heavier rule between groups
+ of rows and columns for emphasis.
+
+ ALL
+ Place rules between all rows and all columns. User agents
+ may choose to use a heavier rule between groups of rows and
+ columns for emphasis.
+
+ If a document includes <TABLE BORDER> or <TABLE BORDER=_n_> then
+ the default for the table element is RULES=ALL, except if _n=0_
+ for which RULES=NONE is appropriate.
+
+ CELLSPACING
+ This attribute is intended for backwards compatibility with
+ deployed user agents. It specifies the space between the table
+ frame and the first or last cell border for each row or column,
+ and between other cells in the table. See standard units.
+ Greater control will be possible using style sheet languages.
+
+ CELLPADDING
+ This attribute is intended for backwards compatibility with
+ deployed user agents. It specifies the amount of space between
+ the border of the cell and its contents both above/below, and
+
+
+
+Raggett Experimental [Page 15]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ left//right. See standard units. Greater control will be
+ possible using style sheet languages.
+
+ If a fixed width is set for the table or column, the CELLSPACING and
+ CELLPADDING may demand more space than assigned. Current practice is
+ for the latter to take precedence over WIDTH attributes when a
+ conflict occurs, although this isn't required by this specification.
+
+Table Captions
+
+ <!ELEMENT caption - - (%text;)+>
+
+ <!ENTITY % Caption "(top|bottom|left|right)">
+
+ <!ATTLIST caption -- table caption --
+ %attrs; -- id, lang, dir and class --
+ align %Caption; #IMPLIED -- relative to table --
+ >
+
+ The optional CAPTION element is used to provide a caption for the
+ table. Both start and end tags are required.
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ ALIGN
+ This may be used to control the placement of captions relative
+ to the table. When present, the ALIGN attribute should have one
+ of the values: TOP, BOTTOM, LEFT and RIGHT. It is recommended
+ that the caption is made to fit within the width or height of
+ the table as appropriate. The default position of the caption is
+ deliberately unspecified.
+
+ Note the ALIGN attribute is overused in HTML, but is retained
+ here for compatibility with currently deployed browsers.
+
+The COLGROUP Element
+
+ <!ELEMENT colgroup - O (col*)>
+
+ <!ATTLIST colgroup
+ %attrs; -- id, lang, dir and class --
+ span NUMBER 1 -- default number of columns in --
+ -- group --
+ width CDATA #IMPLIED -- default width for enclosed --
+ -- COLs --
+ %cell.halign; -- horizontal alignment in --
+ -- cells --
+
+
+
+Raggett Experimental [Page 16]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+
+ The COLGROUP element acts as a container for a group of columns, and
+ allows you to set default properties for these columns. In the
+ absence of a COLGROUP element, all columns in the table are assumed
+ to belong to a single column group. Each COLGROUP element can
+ contain zero or more COL elements. COLGROUP requires a start tag,
+ but the end tag may be omitted. This is useful when defining a
+ sequence of COLGROUP elements, e.g.
+
+ <TABLE FRAME=BOX RULES=COLS>
+ <COLGROUP>
+ <COL WIDTH="1*">
+ <COL WIDTH="2*">
+ <COLGROUP>
+ <COL WIDTH="1*">
+ <COL WIDTH="3*">
+ <THEAD>
+ <TR> ...
+ </TABLE>
+
+ COLGROUP elements can be used with the following attributes:
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ SPAN
+ A positive integer value that specifies a default for how many
+ columns are in this group. This attribute should be ignored if
+ the COLGROUP element contains one or more COL elements. It
+ provides a convenient way of grouping columns without the need
+ to supply COL elements.
+
+ WIDTH
+ Specifies a default width for each of the grouped columns, see
+ standard units. In addition, the "*" suffix denotes relative
+ widths, e.g.
+
+ width=64 width in screen pixels
+ width=0.5* a relative width of 0.5
+
+ Relative widths act as constraints on the relative widths of
+ different columns. If a COLGROUP element specifies a relative
+ width of zero, all of the columns in the group should be set to
+ their minimum widths, unless they are associated with a COL
+ element with an overriding WIDTH attribute. When widths are
+
+
+
+Raggett Experimental [Page 17]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ given in absolute units, the user agent can use these to
+ constrain the width of the table. The "*" suffix is used to
+ simplify importing tables from the CALS representation.
+
+ ALIGN, CHAR, CHAROFF and VALIGN
+ Specify values for horizontal and vertical alignment within
+ table cells. See inheritance order of alignment properties.
+
+The COL Element
+
+ <!ELEMENT col - O EMPTY>
+
+ <!ATTLIST col -- column groups and --
+ -- properties --
+ %attrs; -- id, lang, dir and class --
+ span NUMBER 1 -- number of columns spanned --
+ -- by group --
+ width CDATA #IMPLIED -- column width specification --
+ %cell.halign; -- horizontal alignment in --
+ -- cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+ This optional element is used to specify column based defaults for
+ table properties. It is an empty element, and as such has no
+ content, and shouldn't be given an end tag. Several COL elements may
+ be given in succession. COL attributes override those of the parent
+ COLGROUP element.
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ SPAN
+ A positive integer value that specifies how many columns this
+ element applies to, defaulting to one. In the absence of SPAN
+ attributes the first COL element applies to the first column,
+ the second COL element to the second column and so on. If the
+ second COL element had SPAN=2, it would apply to the second and
+ third column. The next COL element would then apply to the
+ fourth column and so on. SPAN=0 has a special significance and
+ implies that the COL element spans all columns from the current
+ column up to and including the last column. Note that a COL SPAN
+ does not define a group. It is merely a way to share attribute
+ definitions.
+
+
+
+
+
+
+
+Raggett Experimental [Page 18]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ WIDTH
+ Specifies the width of the columns, see standard units. If the
+ element spans several columns then the WIDTH attribute specifies
+ the width for each of the individual columns - not the width of
+ the span. In addition, the "*" suffix denotes relative widths,
+
+ e.g.
+
+ width=64 width in screen pixels
+ width=0.5* a relative width of 0.5
+
+ Relative widths act as constraints on the relative widths of
+ different columns. If a COL element specifies a relative width
+ of zero, the column should always be set to its minimum width.
+ When widths are given in absolute units, the user agent can use
+ these to constrain the width of the table. The "*" suffix is
+ used to simplify importing tables from the CALS representation.
+
+ ALIGN, CHAR, CHAROFF and VALIGN
+ Specify values for horizontal and vertical alignment within
+ table cells. See inheritance order of alignment properties.
+
+Table Head, Foot and Body Elements
+
+ <!ELEMENT thead - O tr+>
+ <!ELEMENT tfoot - O tr+>
+ <!ELEMENT tbody O O tr+>
+
+ <!ATTLIST (thead|tbody|tfoot) -- table section --
+ %attrs; -- id, lang, dir and class --
+ %cell.halign; -- horizontal alignment in --
+ -- cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+ Tables may be divided up into head and body sections. The THEAD and
+ TFOOT elements are optional, but one or more TBODY elements are
+ always required. If the table only consists of a TBODY section, the
+ TBODY start and end tags may be omitted, as the parser can infer
+ them. If a THEAD element is present, the THEAD start tag is
+ required, but the end tag can be omitted, provided a TFOOT or TBODY
+ start tag follows. The same applies to TFOOT.
+
+ Note: This definition provides compatibility with tables created
+ for the older model, as well as allowing the end tags for THEAD,
+ TFOOT and TBODY to be omitted.
+
+
+
+
+
+Raggett Experimental [Page 19]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ The THEAD, TFOOT and TBODY elements provide a convenient means for
+ controlling rendering. If the table has a large number of rows in
+ the body, user agents may choose to use a scrolling region for the
+ table body sections. When rendering to a paged device, tables will
+ often have to be broken across page boundaries. The THEAD, TFOOT and
+ TBODY elements allow the user agent to repeat the table foot at the
+ bottom of the current page, and then the table head at the top of
+ the new page before continuing on with the table body.
+
+ TFOOT is placed before the TBODY in the markup sequence, so that
+ browsers can render the foot before receiving all of the table data.
+ This is useful when very long tables are rendered with scrolling
+ body sections, or for paged output, involving breaking the table
+ over many pages.
+
+ Each THEAD, TFOOT and TBODY element must contain one or more TR
+ elements.
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ ALIGN, CHAR, CHAROFF and VALIGN
+ Specify values for horizontal and vertical alignment within
+ table cells. See inheritance order of alignment properties.
+
+Table Row (TR) elements
+
+ <!ELEMENT tr - O (th|td)+>
+
+ <!ATTLIST tr -- table row --
+ %attrs; -- id, lang, dir and class --
+ %cell.halign; -- horizontal alignment in --
+ -- cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+ The TR or table row element acts as a container for a row of table
+ cells. The end tag may be omitted.
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ ALIGN, CHAR, CHAROFF and VALIGN
+ Specify values for horizontal and vertical alignment within
+ table cells. See inheritance order of alignment properties.
+
+
+
+
+
+
+Raggett Experimental [Page 20]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+Table Cells: TH and TD
+
+ <!ELEMENT (th|td) - O %body.content>
+
+ <!ATTLIST (th|td) -- header or data cell --
+ %attrs; -- id, lang, dir and class --
+ axis CDATA #IMPLIED -- defaults to cell content --
+ axes CDATA #IMPLIED -- list of axis names --
+ nowrap (nowrap) #IMPLIED -- suppress word wrap --
+ rowspan NUMBER 1 -- number of rows spanned by --
+ -- cell --
+ colspan NUMBER 1 -- number of cols spanned by --
+ -- cell --
+ %cell.halign; -- horizontal alignment in --
+ -- cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+ TH elements are used to represent header cells, while TD elements
+ are used to represent data cells. This allows user agents to render
+ header and data cells distinctly, even in the absence of style
+ sheets.
+
+ Cells can span multiple rows and columns, and may be empty. Cells
+ spanning rows contribute to the column count on each of the spanned
+ rows, but only appear in the markup once (in the first row spanned).
+ The row count is determined by the number of TR elements. Any rows
+ implied by cells spanning rows beyond this should be ignored.
+
+ If the column count for the table is greater than the number of
+ cells for a given row (after including cells for spanned rows), the
+ missing cells are treated as occurring on the right hand side of the
+ table and rendered as empty cells. If the language context indicates
+ a right to left writing order, then the missing cells should be
+ placed on the left hand side.
+
+ It is possible to create tables with overlapping cells, for
+ instance:
+
+ <table border>
+ <tr><td rowspan=2>1<td>2<td>3
+ <tr><td rowspan=2>4
+ <tr><td colspan=2>5<td>6
+ </table>
+
+
+
+
+
+
+
+Raggett Experimental [Page 21]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ which might look something like:
+
+ /-----------\
+ | 1 | 2 | 3 |
+ | |-------|
+ | | 4 | |
+ |---|...|---|
+ | 5 : | 6 |
+ \-----------/
+
+ In this example, the cells labelled 4 and 5 overlap. In such cases,
+ the rendering is implementation dependent.
+
+ The AXIS and AXES attributes for cells provide a means for defining
+ concise labels for cells. When rendering to speech, these attributes
+ may be used to provide abbreviated names for the headers relevant to
+ each cell. Another application is when you want to be able to later
+ process table contents to enter them into a database. These
+ attributes are then used to give database field names. The table's
+ class attribute should be used to let the software recognize which
+ tables can be treated in this way.
+
+ ID, CLASS, LANG and DIR
+ See earlier description of common attributes.
+
+ AXIS
+ This defines an abbreviated name for a header cell, e.g. which
+ can be used when rendering to speech. It defaults to the cell's
+ content.
+
+ AXES
+ This is a comma separated list of axis names which together
+ identify the row and column headers that pertain to this cell.
+ It is used for example when rendering to speech to identify the
+ cell's position in the table. If missing the user agent can try
+ to follow up columns and left along rows (right for some
+ languages) to find the corresponding header cells.
+
+ NOWRAP, e.g. <TD NOWRAP>
+ The presence of this attribute disables automatic wrapping of
+ text lines for this cell. If used uncautiously, it may result in
+ excessively wide cells. This attribute is defined for backwards
+ compatibility with deployed user agents. Greater control is
+ possible with associated style sheet languages (for example for
+ control over overflow handling).
+
+
+
+
+
+
+Raggett Experimental [Page 22]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ ROWSPAN, e.g. <TD ROWSPAN=2>
+ A positive integer value that defines how may rows this cell
+ spans. The default ROWSPAN is 1. ROWSPAN=0 has a special
+ significance and implies that the cell spans all rows from the
+ current row up to the last row of the table.
+
+ COLSPAN, e.g. <TD COLSPAN=2>
+ A positive integer value that defines how may columns this cell
+ spans. The default COLSPAN is 1. COLSPAN=0 has a special
+ significance and implies that the cell spans all columns from
+ the current column up to the last column of the table.
+
+ ALIGN, CHAR, CHAROFF and VALIGN
+ Specify values for horizontal and vertical alignment within
+ table cells. See inheritance order of alignment properties.
+
+ Note: It is recommended that implementors provide support for the
+ Netscape 1.1 WIDTH attribute for TH and TD, although this isn't part
+ of the current specification. Document authors are advised to use
+ the width attribute for the COL element instead.
+
+Recommended Layout Algorithms
+
+ If the COLS attribute on the TABLE element specifies the number of
+ columns, then the table may be rendered using a fixed layout,
+ otherwise the autolayout algorithm described below should be used.
+
+Fixed Layout Algorithm
+
+ For this algorithm, it is assumed that the number of columns is
+ known. The column widths by default should be set to the same size.
+ Authors may override this by specifying relative or absolute column
+ widths, using the COLGROUP or COL elements. The default table width
+ is the space between the current left and right margins, but may be
+ overridden by the WIDTH attribute on the TABLE element, or determined
+ from absolute column widths. To deal with mixtures of absolute and
+ relative column widths, the first step is to allocate space from the
+ table width to columns with absolute widths. After this, the space
+ remaining is divided up between the columns with relative widths.
+
+ The table syntax alone is insufficient to guarantee the consistency
+ of attribute values. For instance, the number of columns specified by
+ the COLS attribute may be inconsistent with the number of columns
+ implied by the COL elements. This in turn, may be inconsistent with
+ the number of columns implied by the table cells. A further problem
+ occurs when the columns are too narrow to avoid overflow of cell
+ contents. The width of the table as specified by the TABLE element or
+ COL elements may result in overflow of cell contents. It is
+
+
+
+Raggett Experimental [Page 23]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ recommended that user agents attempt to recover gracefully from these
+ situations, e.g. by hyphenating words and resorting to splitting
+ words if hyphenation points are unknown.
+
+ In the event that an indivisible element causes cell overflow, the
+ user agent may consider adjusting column widths and re-rendering the
+ table. In the worst case clipping may be considered if column width
+ adjustments and/or scrollable cell content are not feasible. In any
+ case if cell content is split or clipped this should be indicated to
+ the user in an appropriate manner.
+
+Autolayout Algorithm
+
+ If the COLS attribute is missing from the table start tag, then the
+ user agent should use the following autolayout algorithm. It uses two
+ passes through the table data and scales linearly with the size of
+ the table.
+
+ In the first pass, line wrapping is disabled, and the user agent
+ keeps track of the minimum and maximum width of each cell. The
+ maximum width is given by the widest line. As line wrap has been
+ disabled, paragraphs are treated as long lines unless broken by <BR>
+ elements. The minimum width is given by the widest word or image etc.
+ taking into account leading indents and list bullets etc. In other
+ words, if you were to format the cell's content in a window of its
+ own, determine the minimum width you could make the window before the
+ cell begins to overflow. Allowing user agents to split words will
+ minimize the need for horizontal scrolling or in the worst case
+ clipping of cell contents.
+
+ This process also applies to any nested tables occuring in cell
+ content. The minimum and maximum widths for cells in nested tables
+ are used to determine the minimum and maximum widths for these tables
+ and hence for the parent table cell itself. The algorithm is linear
+ with aggregate cell content, and broadly speaking independent of the
+ depth of nesting.
+
+ To cope with character alignment of cell contents, the algorithm
+ keeps three running min/max totals for each column: Left of align
+ char, right of align char and un-aligned. The minimum width for a
+ column is then: max(min_left + min_right, min_non-aligned).
+
+ The minimum and maximum cell widths are then used to determine the
+ corresponding minimum and maximum widths for the columns. These in
+ turn, are used to find the minimum and maximum width for the table.
+ Note that cells can contain nested tables, but this doesn't
+ complicate the code significantly. The next step is to assign column
+ widths according to the available space (i.e. the space between the
+
+
+
+Raggett Experimental [Page 24]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ current left and right margins).
+
+ For cells which span multiple columns, a simple approach, as used by
+ Arena, is to evenly apportion the min/max widths to each of the
+ constituent columns. A slightly more complex approach is to use the
+ min/max widths of unspanned cells to weight how spanned widths are
+ apportioned. Experimental study suggests a blend of the two
+ approaches will give good results for a wide range of tables.
+
+ The table borders and intercell margins need to be included in
+ assigning column widths. There are three cases:
+
+ 1. The minimum table width is equal to or wider than the available
+ space. In this case, assign the minimum widths and allow the
+ user to scroll horizontally. For conversion to braille, it will
+ be necessary to replace the cells by references to notes
+ containing their full content. By convention these appear before
+ the table.
+
+ 2. The maximum table width fits within the available space. In this
+ case, set the columns to their maximum widths.
+
+ 3. The maximum width of the table is greater than the available
+ space, but the minimum table width is smaller. In this case,
+ find the difference between the available space and the minimum
+ table width, lets call it W. Lets also call D the difference
+ between maximum and minimum width of the table.
+
+ For each column, let d be the difference between maximum and
+ minimum width of that column. Now set the column's width to the
+ minimum width plus d times W over D. This makes columns with
+ large differences between minimum and maximum widths wider than
+ columns with smaller differences.
+
+ This assignment step is then repeated for nested tables using the
+ minimum and maximum widths derived for all such tables in the first
+ pass. In this case, the width of the parent (i.e. enclosing) table
+ cell plays the role of the current window size in the above
+ description. This process is repeated recursively for all nested
+ tables. The topmost table is then rendered using the assigned widths.
+ Nested tables are subsequently rendered as part of the parent table's
+ cell contents.
+
+ If the table width is specified with the WIDTH attribute, the user
+ agent attempts to set column widths to match. The WIDTH attribute is
+ not binding if this results in columns having less than their minimum
+ (i.e. indivisible) widths.
+
+
+
+
+Raggett Experimental [Page 25]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ If relative widths are specified with the COL element, the algorithm
+ is modified to increase column widths over the minimum width to meet
+ the relative width constraints. The COL elements should be taken as
+ hints only, so columns shouldn't be set to less than their minimum
+ width. Similarly, columns shouldn't be made so wide that the table
+ stretches well beyond the extent of the window. If a COL element
+ specifies a relative width of zero, the column should always be set
+ to its minimum width.
+
+HTML Table DTD
+
+ The DTD or document type definition provides the formal definition of
+ the allowed syntax for HTML tables.
+
+<!-- Content model entities imported from parent DTD:
+
+ %body.content; allows table cells to contain headers, paras,
+ lists, form elements and even arbitrarily nested tables.
+
+ %text; is text characters, including character entities and
+ character emphasis elements, IMG and anchors
+-->
+
+<!ENTITY % attrs
+ "id ID #IMPLIED -- element identifier --
+ class NAMES #IMPLIED -- for subclassing elements --
+ lang NAME #IMPLIED -- as per RFC 1766 --
+ dir (ltr|rtl) #IMPLIED -- I18N text direction --">
+
+<!--
+ The BORDER attribute sets the thickness of the frame around the
+ table. The default units are screen pixels.
+
+ The FRAME attribute specifies which parts of the frame around
+ the table should be rendered. The values are not the same as
+ CALS to avoid a name clash with the VALIGN attribute.
+
+ The value "border" is included for backwards compatibility with
+ <TABLE BORDER> which yields frame=border and border=implied
+ For <TABLE BORDER=1> you get border=1 and frame=implied. In this
+ case, its appropriate to treat this as frame=border for backwards
+ compatibility with deployed browsers.
+-->
+
+<!ENTITY % Frame "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
+
+
+
+
+
+
+Raggett Experimental [Page 26]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+<!--
+ The RULES attribute defines which rules to draw between cells:
+
+ If RULES is absent then assume:
+ "none" if BORDER is absent or BORDER=0 otherwise "all"
+-->
+
+<!ENTITY % Rules "(none | groups | rows | cols | all)">
+
+<!-- horizontal placement of table relative to window -->
+<!ENTITY % Where "(left|center|right)">
+
+<!-- horizontal alignment attributes for cell contents -->
+<!ENTITY % cell.halign
+ "align (left|center|right|justify|char) #IMPLIED
+ char CDATA #IMPLIED -- alignment char, e.g. char=':' --
+ charoff CDATA #IMPLIED -- offset for alignment char --"
+ >
+
+<!-- vertical alignment attributes for cell contents -->
+<!ENTITY % cell.valign
+ "valign (top|middle|bottom|baseline) #IMPLIED"
+ >
+
+<!ELEMENT table - - (caption?, (col*|colgroup*), thead?, tfoot?, t
+ body+)>
+<!ELEMENT caption - - (%text;)+>
+<!ELEMENT thead - O (tr+)>
+<!ELEMENT tfoot - O (tr+)>
+<!ELEMENT tbody O O (tr+)>
+<!ELEMENT colgroup - O (col*)>
+<!ELEMENT col - O EMPTY>
+<!ELEMENT tr - O (th|td)+>
+<!ELEMENT (th|td) - O %body.content>
+
+<!ATTLIST table -- table element --
+ %attrs; -- id, lang, dir and class --
+ align %Where; #IMPLIED -- table position relative to --
+ -- window --
+ width CDATA #IMPLIED -- table width relative to window --
+ cols NUMBER #IMPLIED -- used for immediate display mode --
+ border CDATA #IMPLIED -- controls frame width around --
+ -- table --
+ frame %Frame; #IMPLIED -- which parts of table frame to --
+ -- include --
+ rules %Rules; #IMPLIED -- rulings between rows and cols --
+ cellspacing CDATA #IMPLIED -- spacing between cells --
+ cellpadding CDATA #IMPLIED -- spacing within cells --
+
+
+
+Raggett Experimental [Page 27]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ >
+
+<!-- ALIGN is used here for compatibility with deployed browsers -->
+<!ENTITY % Caption "(top|bottom|left|right)">
+
+<!ATTLIST caption -- table caption --
+ %attrs; -- id, lang, dir and class --
+ align %Caption; #IMPLIED -- relative to table --
+ >
+
+<!--
+COLGROUP groups a set of COL elements. It allows you to group
+several columns together.
+-->
+<!ATTLIST colgroup
+ %attrs; -- id, lang, dir and class --
+ span NUMBER 1 -- default number of columns in --
+ -- group --
+ width CDATA #IMPLIED -- default width for enclosed COLs --
+ %cell.halign; -- horizontal alignment in cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+<!--
+ COL elements define the alignment properties for cells in a given
+ column or spanned columns. The WIDTH attribute specifies the
+ width of the columns, e.g.
+
+ width=64 width in screen pixels
+ width=0.5* relative width of 0.5
+-->
+
+<!ATTLIST col -- column groups and properties --
+ %attrs; -- id, lang, dir and class --
+ span NUMBER 1 -- number of columns spanned by --
+ -- group --
+ width CDATA #IMPLIED -- column width specification --
+ %cell.halign; -- horizontal alignment in cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+<!--
+ Use THEAD to duplicate headers when breaking table
+ across page boundaries, or for static headers when
+ body sections are rendered in scrolling panel.
+
+ Use TFOOT to duplicate footers when breaking table
+ across page boundaries, or for static footers when
+
+
+
+Raggett Experimental [Page 28]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ body sections are rendered in scrolling panel.
+
+ Use multiple TBODY sections when rules are needed
+ between groups of table rows.
+-->
+<!ATTLIST (thead|tbody|tfoot) -- table section --
+ %attrs; -- id, lang, dir and class --
+ %cell.halign; -- horizontal alignment in cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+<!ATTLIST tr -- table row --
+ %attrs; -- id, lang, dir and class --
+ %cell.halign; -- horizontal alignment in cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+<!ATTLIST (th|td) -- header or data cell --
+ %attrs; -- id, lang, dir and class --
+ axis CDATA #IMPLIED -- defaults to cell content --
+ axes CDATA #IMPLIED -- list of axis names --
+ nowrap (nowrap) #IMPLIED -- suppress word wrap --
+ rowspan NUMBER 1 -- number of rows spanned by cell --
+ colspan NUMBER 1 -- number of cols spanned by cell --
+ %cell.halign; -- horizontal alignment in cells --
+ %cell.valign; -- vertical alignment in cells --
+ >
+
+References
+
+ Arena
+ W3C's HTML3 browser, see http://www.w3.org/pub/WWW/Arena/.
+ Arena was originally created as a proof of concept demo for
+ ideas in the HTML+ specification that preceded HTML3. The
+ browser is now being re-implemented to provide a reference
+ implementation of HTML3 along with support for style sheets and
+ client-side scripting.
+
+ CALS
+ Continuous Acquisition and Life-Cycle Support (formerly
+ Computer-aided Acquisition and Logistics Support) (CALS) is a
+ Department of Defense (DoD) strategy for achieving effective
+ creation, exchange, and use of digital data for weapon systems
+ and equipment. More information can be found from the US Navy
+ CALS home page at http://navysgml.dt.navy.mil/cals.html
+
+
+
+
+
+
+Raggett Experimental [Page 29]
+\f
+RFC 1942 HTML Tables May 1996
+
+
+ HTML 2.0 (RFC1866)
+ Hypertext Markup Language Specification Version 2.0 by T.
+ Berners-Lee and D. Connolly, November 1995. Further information
+ can be found at http://www.w3.org/pub/WWW/MarkUp/ or at
+ ftp://ds.internic.net/rfc/rfc1866.txt
+
+ HTML 3.0
+ Hypertext Markup Language Specification Version 3.0. The initial
+ draft specification as published in March 1995. Work on refining
+ HTML3 is proceeding piecemeal with the new table specification
+ as one of the pieces. For W3C related work on HTML, see
+ http://www.w3.org/pub/WWW/MarkUp/.
+
+ RFC 1766
+ "Tags for the Identification of Languages", by H. Alvestrand,
+ UNINETT, March 1995. This document can be downloaded from
+ ftp://ds.internic.net/rfc/rfc1766.txt.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Dave Raggett W3C
+
+ EMail: dsr@w3.org
+
+ The World Wide Web Consortium: http://www.w3.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Raggett Experimental [Page 30]
+\f
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<!-- Changed by: Petter Reinholdtsen, 30-Aug-1996 -->
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+Tormod <tormods@stud.cs.uit.no> & Pans <pans@orgsek.sst.org.uit.no>
+<BR>1996-08-31
+<BR>Sak
+<BR>http://www.cs.uit.no/~petterr/ss/19960831-rekrutering.html
+<HR>
+<H1>Rekrutering til realfag</H1>
+
+Selvom det i Norge er underskudd på teknologer og naturvitere var det
+etter opptak fremdeles ledig kapasitet ved realfag både i Tromsø og i
+Bergen.
+
+<P>De siste årene har søkningen til realfag gått dramatisk ned, spesielt
+er andelen jenter gått til helvete. (tall og sånnt).
+
+<P> - realister er allsidige
+<BR> - teknologifrykt
+
+<P>Jentegruppa ved IMR har siden høsten 1993 kontaktet alle videregående
+skoler i Nordnorge, og bedt om å få besøke dem. De har der oppmuntret
+grunnkurselevene til å velge realfag. En har ment at flere studenter
+til realfag vil øke jenteandelen. Dette arbeidet er gjort ulønnet og
+på frivillig basis av en liten gruppe studenter. Ved infoavdelingen
+har man kun på oppfordring fra skoler/klasser informert om
+universitetet. I tillegg går denne informasjonen hovedsaklig til
+avgangselever ved skolene, og dette er for sent.
+
+
+
+<H2>Hva universitetet kan gjøre</H2>
+
+<UL>
+<LI>invitere rådgiverne på videregående til rådgiverkonferanse om
+ realfag. Gi dem et mer positivt inntrykk av realfagene og påpeke
+ konsekvensene av å velge dem bort. Dette bør samordnes med
+ fylkeskommunene.
+
+ <LI> klargjøre ansvarsfordeling internt
+ <LI> informasjon til elevene (overta/fortsette det JG/IMR har gjort)
+ Fristille JG/IMR til å bedre rekrutering av jenter til høyere nivå.
+ <LI> Landsdelspolitikerne må på banen
+</UL>
+
+<H2>Forslag til vedtak</H2>
+
+<BLOCKQUOTE><EM>
+
+Rekruteringen til realfagene er jævlig lav. Studentstyret ber derfor
+universitets-styret om å sette ned en gruppe som på bakgrunn av det
+ovenfor nevnte skal fremme konkrete tiltak for hva universitetet skal
+gjøre med rekrutering til realfag. Gruppen bør være ferdig med
+arbeidet innen utgangen av oktober, slik at rekruteringsarbeidet kan
+komme i gang så fort som mulig. Den bør bestå av 3 evt. 5 personer
+der både studenter og ansatte er representert.
+
+samarbeide med de andre realfagsmiljøene i Nordnorge
+
+Studentstyret foreslår:
+</EM></BLOCKQUOTE>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Net-tjenester til studentstyret arbeidsutvalg</TITLE>
+<!-- Changed by: Petter Reinholdtsen, 13-Oct-1996 -->
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+Petter Reinholdtsen
+<<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A>>
+<BR>1996-10-13
+<BR>Sak 84/96
+<BR>http://www.cs.uit.no/~petterr/ss/19960908.net-tjenester.html
+<HR>
+<H1>Net-tjenester til studentstyrets arbeidsutvalg</H1>
+
+Jeg skisserer her hvordan Studentstyrets arbeidsutvalg på en billig og
+enkel måte kan få tilgang til Internet-tjenester samt en sentral og
+stabil filtjeneste med bedre backup-rutiner enn i dag.
+
+<P>Systemet kan settes opp på meget kort varsel, og være i drift i
+løpet av høsten hvis det gis klarsignal.
+
+<H2>Resultat av installasjonen </H2>
+
+SS/AU vil med dette få en mailtjeneste uavhenging av EDB-senterets der
+de kan opprette og fjerne eventuelle brukere. Alle i arbeidsutvalget
+og eventuellt andre som SS/AU gir tilgang få egen og privat
+mailadresse. Det vil kunne opprettes mailing-lister etter behov med
+statisk eller dynamisk innmelding i listene.
+
+<P>Kontorlandskapet vil få en delt filserver der alle dokumenter og
+andre data kan lagres. Tilgang til filene kan reguleres fra bruker
+til bruker.
+
+<P>Det kan om ønskelig installeres en web-server der filene kan
+redigeres fra Mac. Jeg tror det er bedre å benytte EDB-senterets
+tilbud om plass på deres webserver, da web-teknologien fortsatt er
+under utvikling. EDB-senteret vil sørge for å holde sin web-server
+oppdatert.
+
+<H2>Nødvendig utstyr og kostnader</H2>
+
+Installasjonen krever en billig Intel-PC og operativsystemet Linux med
+ekstra progamvare for Appletalk over Ethernet (Ethertalk). Sistnevnte
+er gratis tilgjengelig. Hvis den skal fungere som filtjener bør det
+installeres backup-rutiner der hele disken jevnlig kopieres over på
+kassett eller annet egnet medium (f.eks. Zip-drive eller Iomega).
+
+<P>Operativsystem og støtteprogrogrammer krever under 300Mb av disken.
+Resten vil være tilgjengelig for brukerdata.
+
+<TABLE border>
+<CAPTION align=top> Budsjett </CAPTION>
+<TR><TH>Tiltak <TH>Kostnad
+<TR><TD>Innkjøp av maskinvare
+<UL>
+<LI> - minimum 486 m/16Mb ram
+<LI> - Ethernet-kort
+<LI> - 1-2 Gb SCSI HD
+<LI> - tape-streamer
+</UL>
+<TD align=right>10.000,-
+<TR><TD>Installasjon og en måneds innkjøring av server <TD align=right>5.000,-
+<TR><TH align=left>Totalt <TD align=right>15.000,-
+</TABLE>
+
+<P>Det burde være mulig å få donert en gammel PC fra universitetet.
+Denne kan så oppgraderes med harddisk og tape-streamer for å bli egnet
+til formålet. En slik oppgradering burde koste rundt 5.000,-.
+
+<P>Innstallasjon er satt til 5.000,-. Dette er det jeg vil ha for å
+gjøre jobben. Andre kan sansynligvis gjøre det billigere.
+
+<H2>Drift og vedlikehold</H2>
+
+Ut over ved maskinvare-feil skulle det være minimalt med vedlikehold
+som er nødvendig. Det kan om ønskelig lages web-grensesnitt for
+vedlikehold av bruker-listene, mailing-lister og tilgangskontroll.
+
+<P>Det kan om ønskelig leies inn en student for større endringer i
+installasjonen. Det burde være en enkel sak å få en
+informatikk-student til dette på deltid.
+
+<P>Av hensyn til installasjonens stabilitet og sikkerhet bør kun
+IT-personell med erfaring gjøre slike endringer av systemet.
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<!-- Changed by: Petter Reinholdtsen, 4-Dec-1996 -->
+<LINK REV="made" HREF="mailto:pere@td.org.uit.no">
+</HEAD>
+<BODY>
+Petter Reinholdtsen
+<<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A>>
+<BR>Cato Hauge Olsen
+<<A HREF="mailto:cato@stud.cs.uit.no">cato@stud.cs.uit.no</A>>
+<BR>1996-12-04
+<HR>
+<H1>Endringsforslag, fordeling av semesteravgift</H1>
+Saksframlegg til studentstyret 10/96, 4. desember 1996
+
+<H2>Innledning</H2>
+
+Da sakspapiret til fordeling av semesteravgiften var forholdsvis lite
+informativt, har vi laget et alternativt sakspapir. Saksframlegget er
+ført i pennen av Petter Reinholdtsen, men da jeg og Cato Olsen ikke
+ble enige om et forslag har vi to alternative forslag til fordeling.
+
+<H2>Presentasjon av forslag</H2>
+<H3>Forslag fra Petter</H3>
+
+Jeg foreslår å jamne ut semesteravgiften på 300,- per semester. Det
+er ikke så bra velferdstilbud i Tromsø at det er grunnlag for å øke
+semesteravgiften for noen studenter. Det er heller ikke nødvendig å
+øke semesteravgiften for å opprette et fond. En eventuell
+fondsavsetning bør skje etter en grundigere behandling i studentstyre
+enn noen gjettinger under semesteravgiftsfordelingen. Denne saken bør
+derfor tas opp på forsvarlig vis våren 1997.
+
+<P>Jeg foreslår å kutte "Tilskudd NSU" med like mye som støtten
+<B>fra</B> bruker å være, og overføre dette til "Tilskudd
+stydentstyret". Tilskudd studentstyret reduseres altså med 190.000.
+
+<P>Jeg ønsker å kutte TSI endel. TSI fikk en økning både fra 92-93
+(33%) og fra 93 til 94 (12%) med argumentasjon om å sette av penger
+til et fond for idrettshall. Da det har vært ønske i studentstyret om
+å styre et slikt fond selv, virker det unaturlig å opprettholde
+størrelsen. TSI har i tillegg hatt en nedgang i medlemstallet. Det
+er et annet argument mot opprettholdelsen av samme nivå som i dag.
+
+<P>Utropia foreslås kuttet med 10.000. Jeg ser ingen grunn til at de
+skal få alt de søker om. Jeg ønsker også en vurdering og redegjørelse
+fra Utropia på hvordan semesteravgiftspengene blir brukt der.
+
+<P>Jeg synes det er viktig å prioritere mangfoldet blant
+studentaktivitetene, og vil derfor øke posten til studentforeninger,
+der det erfaringsmessig søker rundt 30 foreninger.
+
+<P>Jeg synes ikke ISU har grunngitt sin særstillig i forhold til de
+andre studentforeningene på universitetet, og foreslår derfor at de
+flyttes tilbake under fellestposten "Studentforeninger".
+
+<P>Barnehagesubsidier foreslås opprettholdt på samme nivå som i dag,
+da jeg tror studentene er mer tjent med en totalgjennomgang av
+samskipnadens økonomiske vurderinger på barnehagesiden, og ønsker
+derfor ikke å øke subsidiene.
+
+<P>Jeg savner en presentasjon av hvorfor 1,073 million settes av til
+sosialtjenesten, helsefond, egenandeler og krisehjelp, ut over at
+"dette er faste summer". Spesiellt når jeg har funnet ut at det på
+egenandel og helsefond for '96 alene står 191.000 igjen nå i
+desember. Jeg har pga. mangel på informasjon ikke endret disse.
+
+<P>De to fondene finner jeg dårlig presentert og argumentert for, så
+jeg foreslår at begge fjernes, og at restposten blir satt av slik at
+de kan fordeles våren 1997, etter et konkret forslag til formål og
+organisering.
+
+<H3>Forslag fra Cato</H3>
+
+Forslaget mitt er at vi opprettholder dagens diffrensierte
+semesteravgiftsordning.
+Selv om dette ikke er i tråd med brev fra Kirke-, Utdannings-, og
+Forskningsdepartementets (KUF) brev av 20.12.91 der Departementet ber SiTø
+avvikle den differensierte semesteravgiftsordningen.
+
+<P>Den innbetalte semesteravgiften beløp seg i fjor til 4 108 000,-.
+Tar man i betraktning antall studenter som betalte semesteravgift høsten
+1996, som var på 6795 studenter, hvor 1708 av disse var nye. Og at vi hadde
+en økning av studenttallet fra våren 1996 til høsten 1996.
+Og går ut i fra at studenttallet ikke vil forandre seg i løpet av 1997.
+Vil en kunne regne med til fordeling av semesteravgifta på 4 418 600
+
+<P>Dette viser at uten å forandre på noe er vi i stand til å få
+inn en god del penger. For å være på den sikre siden setter vi
+fordelings beløpet til 4 000 000,-
+
+
+<H2>Tallene</H2>
+
+Tallene er stort sett i hele tusen.
+
+<TABLE border>
+<TR><TD><TD><TD align=right>B ´93<TD align=right>B ´94<TD align=right>R ´95<TD align=right>B ´96<TD align=right>B ´97<TD align=right>Petter<TD align=right>Cato
+<TR><TD>34601<TD>Semesteravgift<TD align=right>R: -3.813<TD align=right>R: -4.025<TD align=right>-4.063020<TD align=right>-3.965<BR>R: 4.108<TD align=right>-4.550<TD align=right>-3.900<TD align=right>-4.000
+<TR><TD><TD>Overføring fra UiTø til studentstyret<TD align=right>-<TD align=right>-357
+<TR><TD>79101<TD>Tilskudd studentstyret<TD align=right>410<TD align=right>238<TD align=right>190.000<TD align=right>190<TD align=right>190<TD align=right>200<TD align=right>160
+<TR><TD>79102<TD>Tilskudd studentforeninger<TD align=right>130<TD align=right>150<TD align=right>132.200<TD align=right>130<TD align=right>120<TD align=right>170<TD align=right>130
+<TR><TD>79103<TD>Tilskudd studentidrett<TD align=right>375<TD align=right>420<TD align=right>408.437<TD align=right>465<TD align=right>465<TD align=right>420<TD align=right>450
+<TR><TD>79104<TD>Tilskudd studentradio<TD align=right>224<TD align=right>270<TD align=right>270.000<TD align=right>270<TD align=right>Fjernes<TD align=right>-<TD align=right>-
+<TR><TD>79105<TD> Tilskudd studentavis<TD align=right>395<TD align=right>475<TD align=right>450.000<TD align=right>450<TD align=right>454<TD align=right>440<TD align=right>454
+<TR><TD><TD>Sivilarbeider TSI/Samfunnet<TD align=right>-<TD
+align=right>60<TD align=right>59.100
+<TR><TD>79106<TD>Tilskudd studentsamfunnet<TD align=right>52<TD align=right>30<TD align=right>83.828<TD align=right>70<TD align=right>241<TD align=right>241<TD align=right>241
+<TR><TD>79107<TD>Tilskudd svalbardstudentene<TD align=right>-<TD align=right>10<TD align=right>11.310<TD align=right>10<TD align=right>10<TD align=right>10<TD align=right>10
+<TR><TD>79108<TD>Tilskudd Jusshjelpa<TD align=right>-<TD align=right>-<TD align=right>-<TD align=right>-<TD align=right>25<TD align=right>25<TD align=right>25
+<TR><TD>79109<TD>Tilskudd ISU <TD align=right>-<TD align=right><TD align=right>-<TD align=right>NY<TD align=right>21<TD align=right>-<TD align=right>21
+<TR><TD>79201<BR>79202<TD>Annonser for INFO og<BR>Annonser som støtte<TD align=right>11<TD align=right>0<TD align=right>158.842<TD align=right>-<TD align=right>Fjernes<TD align=right>-<TD align=right>-
+<TR><TD>79301<TD>Tilskudd NSU (fast)<TD align=right>411<TD align=right>479<TD align=right>494.380<TD align=right>494<TD align=right>494<TD align=right>294<TD align=right>494
+<TR><TD>79302<TD>Tilskudd SAIH (fast)<TD align=right>108<TD align=right>126<TD align=right>130.100<TD align=right>130<TD align=right>130<TD align=right>130<TD align=right>130
+<TR><TD><TD>Spesiell konstnader utenlandske studenter<TD align=right>-<TD align=right>-<TD align=right>11.120<TD align=right><TD align=right>-<TD align=right>-
+<TR><TD>79402<TD>Bolighjelpa<TD align=right>-<TD align=right>-<TD align=right>31544<TD align=right><TD align=right>Fjernes<TD align=right>-<TD align=right>-
+<TR><TD>79501<TD>Tilskudd Studentenes Sosialtj. (fast)<TD align=right>370,5<TD align=right>460<TD align=right>437.632<TD align=right>588<TD align=right>605<TD align=right>605<TD align=right>605
+<TR><TD>79502<TD>Refusjon egenandeler (fast)<TD align=right>90<TD align=right>110<TD align=right>90.827<TD align=right>110<TD align=right>110<TD align=right>110<TD align=right>100
+<TR><TD>79503<TD>Tilskudd helsefondet (fast)<TD align=right>350<TD align=right>350<TD align=right>487.104<TD align=right>350<TD align=right>350<TD align=right>350<TD align=right>350
+<TR><TD>79504<TD>Krisehjelp (fast)<TD align=right>8<TD align=right>8<TD align=right>8.100<TD align=right>8<TD align=right>8<TD align=right>8<TD align=right>8
+<TR><TD>79600<TD>Barnehagesubsidier<TD align=right>150<TD align=right>250<TD align=right>-<TD align=right>250<TD align=right>350<TD align=right>250<TD align=right>350
+<TR><TD>79700<TD>Diverse sosiale og kult. kostnader<TD align=right>155,5<TD align=right>251<TD align=right>94.496<TD align=right>81<TD align=right>0<TD align=right>0<TD align=right>0
+<TR><TD>79750<TD>UKA-97<TD align=right>-<TD align=right>-<TD align=right><TD align=right>NY<TD align=right>100<TD align=right>100<TD align=right>100
+<TR><TD><TD>Fond barnehager<TD align=right>-<TD align=right>100
+<TR><TD>79800<TD>SSts Disposisjonsfond<TD align=right><TD align=right><TD align=right><TD align=right>-<TD align=right>127<TD align=right>0<TD align=right>100
+<TR><TD>79900<TD>Semesteravgiftsfondet <TD align=right><TD align=right><TD align=right><TD align=right>NY<TD align=right>750<TD align=right><TD align=right>272
+<TR><TD><TD>Til fordeling v97<TD align=right><TD align=right><TD align=right><TD align=right><TD align=right><TD align=right>547<TD align=right>
+<TR><TD><TD>Bo-miljøprosjektet<TD align=right><TD align=right><TD align=right>70.235
+<TR><TD><TD>Saldering hos samskipnaden<TD align=right><TD align=right><TD align=right>443765<TD align=right>
+<TR><TD><TD>SUM <TD align=right>3.240<TD align=right>3.906<TD align=right><TD align=right>3.965<TD align=right>4.550<TD align=right>3.900<TD align=right>4.000
+</TABLE>
+
+<H2>Notater til postene</H2>
+Felleskommentarer er skrevet med vanlig skrift. <B>Petters kommentarer er skrevet med fet skrift</B>, og <EM>Catos kommentarer er skrevet med hellende skrift.</EM>
+<DL>
+
+<DT>Semesteravgift
+<DD>Tallene for 93, 94 og 95 er regnskapstall oppgitt av samskipnaden
+pr. telefon 1996-12-04. (93: 3.813.640, 94: 4.054.025, 95: 4.063.020).
+
+<BR><B>Dette er 13.000 semesteravgifter til Kr. 300,-. Tallet vil bli høyere hvis det blir like mange semesteravgifter som i år.</B>
+
+<DT>Tilskudd studentidrett
+<DD>Disse pengene går til TSI. TSI har hatt en nedgang i
+medlemstallet på 20 fra 763 høsten 1995 til 743 høsten 1996. De har
+fått 1-2 flere undergrupper i samme periode og har høsten 1996 24
+undergrupper.
+
+<DT>Tilskudd studentavis.
+<DD>Dette er til Utropia. Utropia har søkt om
+454.000, som er mindre enn i fjor. I fjor hadde de mange
+nyinvesteringer i datautstyr.
+
+<DT>Tilskudd svaldbardstudentene
+
+<DD>Petter tok kontakt for å høre hva pengene ble brukt til. Morten
+Ingebrigtsen (økonomiansvarlig for UNIS-studentene) opplyste at i
+hovedsak ble pengene brukt til studentvelferd utover det beløpet de
+mottar fra UNIS' budsjett. Fra høsten 1996 har de begynt en
+refusjonsordning når det gjelder helseutgifter (legebesøk og rønken,
+men ikke medisiner). Ny kontaktperson over nyttår ble oppgitt til
+Lena Seternes (lenas@unis.no).
+
+<DT>Tilskudd NSU
+<DD>Dette er kr. 38,- per student pr semester. For 1995 var det 13.010
+semesteravgifter.
+
+<DT>Saldering hos samskipnaden
+<DD>Her er restpengene fra semesteravgiften blitt brukt opp av samskipnaden.
+
+</DL>
+
+<H2>Referanser</H2>
+93,94 Brev fra Studentstyret v/Kjetil Kvalsvig til
+Studentsamskipnaden etter møte 1993-12-08
+<BR>95 Regnskapstall fra samskipnaden uthentet 1996-12-04
+<BR>96,97 Sakspapir til SS 10/96 sak 99/96
+</BODY>
+</HTML>
--- /dev/null
+<html>
+<head>
+<title></title>
+<!-- Changed by: Petter Reinholdtsen, 16-Oct-1996 -->
+</head>
+<body>
+Petter Reinholdtsen
+<BR>1996-10-16
+<BR>Til Studentstyret
+<hr>
+
+<h1>Budsjett 1996 for Studentstyrets arbeidsutvalg</h1>
+
+Basert på sakspapirene til sak 79/95 og referat for samme sak fra
+Studentstyremøtet 16/95, 1995-11-29. Vedtaket er forskjellig fra
+saksframlegget på punktene om "Administrasjon", "Tilskudd institutt
+AU'er", "Organisasjonsfond" og "Urnevalg".
+
+<P>
+<TABLE border>
+<TR><TH colspan=2 align=right>1996
+<TR><TH colspan=2 align=left>Inntekter
+<TR><TD>Tilskudd fra semesteravgifta<TD align=right>100.000,-
+<TR><TD>Tilskudd fra UiTø <TD align=right>700.000,-
+<TR><TD>Tilskudd fra NSU <TD align=right>200.000,-
+<TR><TD>Tilskudd UiTø-gruppa<TD align=right>?
+<TR><TD>Tilskudd bolighjelpa<TD align=right>?
+<TR><TD>Tilskudd seminar<TD align=right>24.000,-
+<TR><TD>Tilskudd Barents<TD align=right>0,-
+<TR><TH align=right>Sum Inntekter <TD align=right>1.024.000,-
+<TR><TH colspan=2 align=left>Utgifter
+<TR><TD>Honorar leder<TD align=right>103.400,-
+<TR><TD>Honorar nestleder<TD align=right>87.890,-
+<TR><TD>Honorar politisk sekretær<TD align=right>87.890,-
+<TR><TD>Lønn organisasjonssekr.<TD align=right>204.000,-
+<TR><TD>Honorar AU-medlemmer<TD align=right>94.000,-
+<TR><TD>Feriepenger<TD align=right>57.718,-
+<TR><TD>Arbeidsgiveravgift<TD align=right>63.489,-
+<TR><TD>Administrasjon<TD align=right>47.500,-
+<TR><TD>Kopimaskin / trykking<TD align=right>50.000,-
+<TR><TD>Informasjon / aksjoner<TD align=right>32.813,-
+<TR><TD>Skolering / seminarer<TD align=right>35.000,-
+<TR><TD>Avsetning / invest.<TD align=right>15.000,-
+<TR><TD>Bolighjelpa<TD align=right>?
+<TR><TD>Universitetsstyregruppa<TD align=right>?
+<TR><TD>Reiser <TD align=right>30.000,-
+<TR><TD>Barents <TD align=right>40.000,-
+<TR><TD>Tilskudd institutt AU'er<TD align=right>60.000,-
+<TR><TD>Urnevalg <TD align=right>4.500,-
+<TR><TD>Barnepass <TD align=right>10.800,-
+<TR><TH align=right>Sum utgifter<TD>1.024.000,-
+</TABLE>
+
+
+</body>
+</html>
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<!-- Changed by: Petter Reinholdtsen, 12-Dec-1996 -->
+<LINK REV="made" HREF="mailto:pere@td.org.uit.no">
+</HEAD>
+<BODY>
+Petter Reinholdtsen -
+<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A>
+<BR>1996-12-12
+<HR>
+
+<H1>Prisanslag, nettserver</H1>
+
+<TABLE>
+
+<TR><TD>Kabinett m/strøm og plass
+<TD align=right>~ 500
+
+<TR><TD>Hovedkort med min 486 dx
+<TD align=right>?
+
+<TR><TD>RAM 16Mb
+<TD align=right>1.000
+
+<TR><TD>Nettkort tynnether
+<TD align=right>~ 500
+
+<TR><TD>SCSI-kort
+<TD align=right>~ 1.000
+
+<TR><TD>SCSI-disk 2GB
+<TD align=right>ny ~4.200
+
+<TR><TD>SCSI-tapestreamer (helst DAT)
+<TD align=right> ~3.000
+
+<TR><TD>Diskettstasjon 3.5"
+<TD align=right>ny ~300
+
+<TR><TD>Tastatur
+<TD align=right>ny ~200
+
+<TR><TD>Div. kabler og lokk
+<TD align=right>~200
+
+<TR><TH>Sum:
+<TD align=right>~ 9500
+
+</TABLE>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Forslag til referat fra konstituerende Studentstyremøte torsdag 5.12.96</TITLE>
+<!-- Changed by: Petter Reinholdtsen, 14-Dec-1996 -->
+<LINK REV="made" HREF="mailto:pere@td.org.uit.no">
+</HEAD>
+<BODY>
+
+
+<P align=center> - forslag til -</P>
+
+<H1 align=center>Referat fra Konstituerende Studentstyremøte for
+<BR>Studentstyret 1997 torsdag 5.12.96</H1>
+
+
+<B>Tilstede:</B>
+<TABLE>
+<TR><TD>Eidi Ann Hansen<TD>ISV
+<TR><TD>Roger Jørgensen<TD>SSF
+<TR><TD>Pål D. Ekran<TD>SEL
+<TR><TD>Liss M. Jenssen<TD>SEL<TD>gikk 21.05 for Gjertrud Pedersen
+<TR><TD>Tormod K.Sivertsen<TD>SEL
+<TR><TD>Therese Bakkevold<TD>ISV
+<TR><TD>Petter Reinholdtsen<TD>IMR
+<TR><TD>Ingulf Nordahl<TD>IRV
+<TR><TD>Ann Kristin Markussen<TD>IRV
+<TR><TD>Roy T. Magnussen<TD>IBG
+<TR><TD>Marie Barlindhaug<TD>FM
+<TR><TD>Sigrid Ovanger Stensland<TD>ROSSA
+<TR><TD>Stig-Erik Falk<TD>ISL
+<TR><TD>Solbjørg Marjala<TD>ROSSA
+<TR><TD>Hugo Rystrøm<TD>ISV<TD>gikk 21.05 for Ole Martin E.
+<TR><TD>Sissel Mikkelsen<TD>SSSR
+<TR><TD>Margaret Aarag<TD>FM
+<TR><TD>Trine Eskeland<TD>SSF
+<TR><TD>Aina Wikestad<TD>TSVL
+<TR><TD>Nils Kristian Bakke<TD>Moderat
+<TR><TD>Marianne Holst<TD>Moderat
+<TR><TD>Stian Jensen<TD>Moderat
+<TR><TD>Ingar Haukanes<TD>NFH
+<TR><TD>Ogbebo Fortune<TD>ISU<TD>fra 15.25 gikk 21.20
+</TABLE>
+
+<P><B>Meldt forfall:</B>
+<TABLE>
+<TR><TD>Ingrid Hedlund<TD>ISL
+</TABLE>
+
+<P>Tid: 16.15 ( - 21.35 ).
+<BR>Sted: Hiet, Hovedgården.
+
+<P><B>Til konstituering.</B>
+<BR>Winston Makhete leverte skriftlig melding om at han trakk seg fra
+Studentstyret 1997. Solbjørg Marjala overtar som fast medlem av
+Studentstyret.
+
+<P><B>Valg av møteledelse.</B>
+<BR>Jørn Fause og Pia Skøien ble foreslått og enstemmig valgt.
+
+<P><B>Godkjenning av innkaling og dagsorden.</B>
+<BR>Innkallingen enstemmig godkjent.
+
+<P>Merknader til dagsorden:
+<BR>Fra ordstyrerbordet: Forslag om å vedta forretningsorden før den
+videre saksbehandlingen.
+<BR>Enstemmig vedtatt.
+<BR>Fra Nils Kristian Bakke: To saker til Eventuellt.
+<BR>1) Intensjonsvedtak om helgemøter i Studentstyret
+<BR>Vedtatt (sak S 110/96 under Eventuellt). 16 stemmer for, 5 mot, 2
+avholdende.
+<BR>2) Uttalelse om tvangsflytting av studenter
+<BR>Falt. 12 stemmer for, 10 mot, 1 avholdende.
+<BR>Fra ordstyrerbordet: Forslag om at S 105/96 kun behandles som en
+orienteringssak.
+<BR>Falt. 10 stemmer for, 10 mot, 2 avholdende.
+<BR>Fra Margaret Aarag og Marie Barlindhaug: "Foreslår å utsette sak
+104/96 til neste SST-møte el. etter evt. diskusjonsmøte /
+overlappingsseminar."
+<BR>Vedtatt. 22 stemmer for, 1 avholdende.
+
+<P>Dagsorden enstemmig godkjent med disse endringene.
+
+<P><B>Forretningsorden.</B>
+<BR>Nytt forslag til forretningsorden delt ut på møtet.
+<BR>Fra Nils Kristian Bakke: Endringsforslag til § 2.15 "§ 2.15 blir §
+2.15 a). Ny § 2.15 b) blir "Studentstyret kan med simpelt flertall
+fravike § 2.15 a) og bruke flertallsvalg ved personvalg." Ellers samme
+som de siste tre setningene i § 2.15 a).
+<BR>Falt. 3 stemmer for, 16 mot, 3 avholdende.
+
+<H2>Sak SSt 105/96 Arbeidsprogram for Studentstyret 1997.</H2>
+Utsatt.
+
+<H2>Sak SSt 105/96 Honorering og strukturering av studentstyrets
+arbeidsutvalg.</H2>
+Fra Nils Kristian Bakke: Tilleggsforslg "Studentstyret gir AU
+fullmakt til å hente inn navn til innstillingskomité fra de tre
+største politiske listene. AU velger denne komitéen."
+<BR>Vedtatt. 10 stemmer for, 8 mot, 5 avholdende.
+
+<P>Fra Roy T. Magnussen: Tilleggsforslag "I denne komitéen sitter 1
+studentrepresentant som ikke er medlem av AU fra hver at de to største
+politisk valgte grupperingene, samt en instituttrepresentant valgt av
+instituttrepresentantene."
+<BR>Vedtatt. 10 stemmer for, 8 mot, 5 avholdende.
+
+<P>Det kom inn tre forslag om endringer i honoreringssatsene til de ulike
+vervene. Det ble enighet om å behandle leder og nestleder for seg, og
+så sekretær.
+
+<P>Forslag fra Sigrid Ovanger Stensland ble satt opp mot saksframlegget:
+"Jeg foreslår å senke honoreringen til leder og heve honoreringen til
+nestleder til kr 90.000."
+<BR>Falt. 8 stemmer for, 13 mot, 2 avholdende.
+
+<P>Forslag fra Roger Jørgensen ble satt opp mot saksframlegget: "Leders
+honorar senkes til 100.000,-. Nestleder heves til 70.000,-."
+<BR>Vedtatt. 14 stemmer for, 5 mot, 4 avholdende.
+
+<P>Forslag fra Tormod K. Sivertsen om endret honorarsats for sekretær
+(samme sum som i Sigrid Ovanger Stenslands forslag) satt opp mot
+saksframlegget: "Sekretærs honorar senkes til 140.000 kr."
+<BR>Falt. 9 stemmer for, 12 mot, 2 avholdende.
+
+<P>Da Tormod K. Sivertsen endringsforslag var å forstå som en helhetlig
+forslag til honorering ble det foretatt ny votering om nestleders
+honorar. T.K.S.s forslag om 60.000,- ble satt opp mot nettopp vedtatt
+70.000,- (Roger Jørgensens forslag):
+<BR>Falt. 9 stemmer for, 12 mot, 2 avholdende.
+
+<P><EM>Honorering av Studentstyrets Arbeidsutvalg blir som følger:
+<TABLE>
+<TR><TD>Leder:<TD>100.000,-/år
+<TR><TD>Nestleder:<TD>70.000,-/år
+<TR><TD>Sekretær:<TD>173.000,-/år
+<TR><TD>AU-medlemmer/komitéledere:<TD>4.000,-/mnd.
+</TABLE>
+</EM>
+
+<P>Før valgene ble det fra ordstyrerbordet foreslått et tellekorps
+bestående av Geir Jarle Voldmo, Jorunn Dahl og Anne Helene
+S. Tandberg. Dette ble enstemmig godkjent.
+
+<P>Etter anmodning ble det åpnet for en orienteringsrunde før valgene.
+De nyvalgte studentrepresentantene i universitetsstyret, Nale - leder
+i SASCO og Marianne Grimstad Hansen fra NSU fikk alle anledning til å
+gi sin orientering.
+
+<H2>Sak SSt 106/96 Valg av studentstyrets leder for 1997.</H2>
+Følgende kandidater stilte til valg:
+<UL>
+<LI>Petter Reinholdtsen
+<LI>Trine Eskeland
+<LI>Stian Jensen
+<LI>Eidi Ann Hansen
+</UL>
+
+Kandidatene fikk fem minutter til å presentere seg før det ble åpnet
+for en omfattende spørsmålsrundte.
+
+<P>Det ble i henhold til forretningsorden foretatt preferansevalg:
+<TABLE>
+<TR><TD>Petter Reinholdtsen<TD>33
+<TR><TD>Trine Eskeland<TD>42
+<TR><TD>Stian Jensen<TD>28
+<TR><TD>Eidi Ann Hansen<TD>41
+</TABLE>
+
+Denne stemmefordelingen resulterte i en ny valgomgang mellom Trine
+Eskeland og Eidi Ann Hansen. Det ble gjennomført flertallsvalg:
+<TABLE>
+<TR><TD>Eidi Ann Hansen<TD>13
+<TR><TD>Trine Eskeland<TD>11
+</TABLE>
+
+<P><EM>Studentstyret velger som sin leder for perioden 1/1 - 31/12
+1997: Eidi Ann Hansen.</EM>
+
+<H2>Sak SSt 107/96 Valg av Studentstyrets nestleder for 1997</H2>
+Følgende kandidater stilte til valg:
+<UL>
+<LI>Stian Jensen
+<LI>Roy T. Magnussen
+</UL>
+
+Kandidaten som ikke tidligere var presentert fikk anledning til dette,
+før det ble åpnet for en spørsmålsrunde.
+<BR>Det ble foretatt flertallsvalg:
+<TABLE>
+<TR><TD>Stian Jensen<TD>16
+<TR><TD>Roy T. Magnussen<TD>8
+</TABLE>
+
+<P><EM>Studentstyret velger som sin Nestleder for perioden 1/1 - 31/12
+1997: Stian Jensen.</EM>
+
+<H2>Sak SSt 108/96 Valg av AU-medlemmer for Studentstyret.</H2>
+Følgende kandidater stilte til valg:
+<UL>
+<LI>Roy T. Magnussen
+<LI>Solbjørg Marjala
+<LI>Sigrid Ovanger Stensland
+<LI>Ingulf Nordahl
+</UL>
+Kandidater som tidligere ikke var presentert fikk anledning til dette,
+før det ble åpnet for en spørsmålsrunde.
+<BR>Det ble foretatt preferansevalg:
+<TABLE>
+<TR><TD>Roy T. Magnussen<TD>36
+<TR><TD>Solbjørg Marjala<TD>36
+<TR><TD>Sigrid Ovanger Stensland<TD>28
+<TR><TD>Ingulf Nordahl<TD>44
+</TABLE>
+
+<P><EM>Studentstyret velger som sine AU-medlemmer i perioden 1/1 - 31/12
+1997:
+<UL>
+<LI>Ingulf Nordahl
+<LI>Roy T. Magnussen
+<LI>Solbjørg Marjala
+</UL>
+</EM>
+
+<H2>Sak SSt 109/96 Valg av kontrollkomité for studentstyret 1997.</H2>
+Følgende kandidater stillte til valg:
+<UL>
+<LI>Torbjørn Flaatten
+<LI>Tor-Ståle Hansen
+<LI>Torgeir Dølerud
+<LI>Arulnesan Marianayagam
+</UL>
+
+<P>Kandidatene fikk anledning til en kort presentasjon før en kort
+spørsmålsrunde.
+<BR>Det ble foretatt preferansevalg:
+
+<TABLE>
+<TR><TD>Torbjørn Flaatten<TD>41
+<TR><TD>Tor-Ståle Hansen<TD>35
+<TR><TD>Torgeir Dølerud<TD>43
+<TR><TD>Arulnesan Marianayagam<TD>25
+</TABLE>
+
+<P><EM>Studentstyret velger til kontrollkomité for perioden 1/1 - 31/12
+1997:
+<UL>
+<LI>Torbjørn Flaatten
+<LI>Tor-Ståle Hansen
+<LI>Torgeir Dølerud
+</UL>
+</EM>
+<H2>Sak SSt 110/96 Intensjonsvedtak om helgemøter i studentstyret.</H2>
+Saksfremlegg fra Nils Kristian Bakke ble delt ut på møtet.
+<BR>Tilleggsforslag fra Aina Wikestad "(som 5. avsnitt) Studentstyret vil
+derfor legge sitt første ordinære studentstyremøte i 1997 til en helg.
+På dette helgemøtet skal arbeidsprogrammet for 1997 gjennomgås i
+tillegg til at Studentstyrets arbeidsform tas opp til vurdering.
+Siste avsnitt går ut." ble innarbeidet i Nils Kristian Bakkes forslag.
+
+<P>Endringsforslag fra Eidi Ann Hansen: "(som 5. avsnitt)
+Studentstyret vil vurdere helgemøter i Studentstyret på
+overlappingsseminaret i begynnelsen av perioden.
+<BR>Falt. 7 stemmer for, 10 mot, 4 avholdende.
+
+<P>Nils Kristian Bakkes forslag vedtatt. 12 stemmer for, 3 mot, 6
+avholdende.
+
+<P>Møtet hevet 2135.
+
+<P>Referent
+
+<BR>Pia Skøien (sign.)
+
+</BODY>
+</HTML>
--- /dev/null
+<html>
+<head>
+<title></title>
+<!-- Changed by: Petter Reinholdtsen, 16-Oct-1996 -->
+</head>
+<body>
+Petter Reinholdtsen
+<BR>1996-10-16
+<BR>Til Studentstyret
+<hr>
+
+<h1>Foreløpig regnskap 1996 for Studentstyrets arbeidsutvalg</h1>
+
+<P>
+<TABLE border>
+<TR><TH align=right>1996<TH>Budsjett
+<TH>Regnskap
+<BR>pr. 9.okt.
+<TR><TH colspan=2 align=left>Inntekter
+<TR><TD>Tilskudd fra semesteravgifta
+<TD align=right>100.000,-
+<TR><TD>Tilskudd fra UiTø
+<TD align=right>700.000,-
+<TD align=right>450.000,-
+<TR><TD>Tilskudd fra NSU
+<TD align=right>200.000,-
+<TR><TD>Tilskudd UiTø-gruppa
+<TD align=right>?
+<TR><TD>Tilskudd bolighjelpa
+<TD align=right>?
+<TR><TD>Tilskudd seminar
+<TD align=right>24.000,-
+<TR><TD>Tilskudd Barents
+<TD align=right>0,-
+<TR><TD>Tilskudd arrangement
+<TD><TD align=right>16.118,-
+<TR><TH align=right>Sum Inntekter
+<TD align=right>1.024.000,-
+<TD align=right>466.118,00
+
+<TR><TH colspan=2 align=left>Utgifter
+<TR><TD>Honorar leder
+<TD align=right>103.400,-
+<TR><TD>Honorar nestleder
+<TD align=right>87.890,-
+<TR><TD>Honorar politisk sekretær
+<TD align=right>87.890,-
+<TR><TD>Honorar AU-medlemmer
+<TD align=right>94.000,-
+<TR><TD>Lønn organisasjonssekr.
+<TD align=right>204.000,-
+<TR><TH align=right>Totalt
+<TD align=right>577.180,-
+<TD align=right>397.534,76
+<TR><TD>Feriepenger
+<TD align=right>57.718,-
+<TD align=right>41.627.15
+<TR><TD>Arbeidsgiveravgift
+<TD align=right>63.489,-
+<TD align=right>26.556.32
+<TR><TD>Administrasjon
+<TD align=right>47.500,-
+<TD align=right>18.628,38
+<TR><TD>Kopimaskin / trykking
+<TD align=right>50.000,-
+<TD align=right>27.162,53
+<TR><TD>Informasjon / aksjoner
+<TD align=right>32.813,-
+<TD align=right>11.111.50
+<TR><TD>Skolering / seminarer
+<TD align=right>35.000,-
+<TD align=right>4.000,-
+<TR><TD>Avsetning / invest.
+<TD align=right>15.000,-
+<TD align=right>14.246,03
+<TR><TD>Bolighjelpa
+<TD align=right>?
+<TD align=right>?
+<TR><TD>Universitetsstyregruppa
+<TD align=right>?
+<TD align=right>18.304,-
+<TR><TD>Reiser
+<TD align=right>30.000,-
+<TD align=right>14.959,50
+<TR><TD>Barents
+<TD align=right>40.000,-
+<TD align=right>0,-
+<TR><TD>Tilskudd institutt AU'er
+<TD align=right>60.000,-
+<TD align=right>0,-
+<TR><TD>Urnevalg
+<TD align=right>4.500,-
+<TD align=right>254,-
+<TR><TD>Barnepass
+<TD align=right>10.800,-
+<TD align=right>1.500,-
+<TR><TD>Upostert
+<TD><TD align=right>26.926,58
+<TR><TD>Underskudd 1995
+<TD><TD align=right>52.765,02
+<TR><TH align=right>Sum utgifter
+<TD>1.024.000,-
+<TD>671.400.77
+</TABLE>
+
+
+</body>
+</html>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Tilrettelegging av emacs-konfig-filer </TITLE>
+<!-- Changed by: Espen Skoglund, 24-Apr-1996 -->
+</HEAD><BODY>
+
+<H1> Tilrettelegging av emacs-konfig-filer </H1>
+
+En del programmpakker er skrevet for å benyttes ifra Emacs eller
+XEmacs. For at disse pakkene skal fungere tilfredsstillende for alle
+brukerne, må oppstartfilene til emacs sansynligvis konfigureres noe.
+Dette kan f.eks. bestå i å sette noen få variabler.
+
+<P>Måten dette fungerer på, er at emcas laster inn og eksekverer en
+fil, <CODE>default.el</CODE>, før selve editoren starter opp. Denne
+filen finnes under <CODE>/store/lib/xemacs/site-lisp</CODE> og
+<CODE>/store/share/emacs/site-lisp</CODE> for henholdsvis XEmacs og Emacs.
+
+<P>Disse filene genereres hver natt av en <EM>nightly job</EM>. Det
+som skjer, er at alle filer på formen ``<CODE>default.el-*</CODE>''
+blir konkatinert isammen til en enkel ``<CODE>default.el</CODE>''.
+Sammen med Python-dsitribusjonen følger det f.eks. med en emacs-mode
+(<CODE>python-mode.el</CODE>) for editering av python-filer. Dette
+ønsker vi å benytte oss av, og lager derfor følgende to filer:
+
+<BLOCKQUOTE><CODE>
+ /store/lib/xemacs/site-lisp/default.el-python<BR>
+ /store/share/emacs/site-lisp/default.el-python
+</CODE></BLOCKQUOTE>
+
+Disse filene er identiske, og inneholder følgende elisp-kode:
+
+<LISTING>
+ (autoload 'python-mode "python-mode" "Python editing mode." t)
+ (setq auto-mode-alist
+ (cons '("\\.py$" . python-mode) auto-mode-alist))
+</LISTING>
+
+Koden fører til at emacs automatisk laster inn
+<CODE>python-mode.el</CODE> når funksjonen <CODE>python-mode</CODE>
+blir startet i emacs (f.eks. ved ``<CODE>M-x python-mode</CODE>''). I
+tillegg sier den at når en fil som ender på ``<CODE>.py</CODE>'' blir
+lastet inn, så skal <CODE>python-mode</CODE> automatisk startes opp.
+
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Tilrettelegging av emacs-info-sider </TITLE>
+<!-- Changed by: Espen Skoglund, 24-Apr-1996 -->
+</HEAD><BODY>
+
+<H1> Tilrettelegging av emacs-info-sider </H1>
+
+Enkelte applikasjoner (særlig GNU applikasjoner) har medfølgende
+dokumentasjon i emacs-info-format. Denne dokumentasjonen består av
+filer som ender på <CODE>.info</CODE>, <CODE>.info-1</CODE>,
+<CODE>.info-2</CODE>, etc, og ender som oftest opp i
+<CODE>/store/info</CODE>-katalogen når ``<CODE>make install</CODE>''
+har gjort seg ferdig.
+
+<P>For at disse filene skal dukke opp i info-menyene vi ser i
+f.eks. XEmacs og Emacs, må vi lage en liten fil som inneholder et
+meny-entry. Denne filen skal være navngitt på formen
+
+<BLOCKQUOTE>
+ <CODE><navn>.dir.<doktype></CODE>
+</BLOCKQUOTE>
+
+og befinne seg under <CODE>/store/info</CODE>. <EM>Navn</EM> er her
+navnet på dokumentasjonen (f.eks. <CODE>bash</CODE> eller
+<CODE>gcc</CODE>). <EM>Doktype</EM> forteller hvilket emne
+dokumentasjonen inneholder. Dette benyttes for å plassere
+meny-entryet på en fornuftig plass i menyen, og kan ha følgende
+verdier:
+
+<DL>
+<DT><CODE>emacs</CODE>
+<DD>Benyttes for dokumentasjon som omhandler bruken av Emacs/XEmacs.
+
+<DT><CODE>elisp</CODE>
+<DD>Benyttes for emacs-lisp-dokumenasjon.
+
+<DT><CODE>packages</CODE>
+<DD>Benyttes for dokumentasjon som omhandler bruken av en tillegspakke til
+ emacs (f.eks. AUC-TeX eller GNUS).
+
+<DT><CODE>compilers</CODE>
+<DD>Benyttes for dokumentasjon til kompilatorer eller utviklingsverktøy
+ (f.eks. GCC eller Make).
+
+<DT><CODE>library</CODE>
+<DD>Benyttes for dokumentasjon som omhandler diverse biblioteker
+ (f.eks. Libg++ eller Mmalloc).
+
+<DT><CODE>standard</CODE>
+<DD>Benyttes for dokumentasjon av diverse standarder og formater (f.eks.
+ GNU coding standards).
+
+<DT><CODE>program</CODE>
+<DD>Benyttes for dokumentasjon av andre programpakker (f.eks. Bash og Zsh).
+
+</DL>
+
+For å lage en meny-entry for Bash, lager vi f.eks. en fil
+``<CODE>info/bash.dir.program</CODE>'' i <CODE>bash</CODE>-filsettet
+som inneholder følgende tekst:
+
+<LISTING>
+ * Bash: (bash). Bourne Again Shell
+</LISTING>
+
+Dette fører til at linjen dukker opp under overskriften; ``<EM>Other
+programs and packages</EM>'' neste dag (etter at
+<EM>nightly</EM>-jobbene til Emacs eller XEmacs har kjørt).
+
+<H3> Mulig forslag til meny-entry </H3>
+
+Mange dokumentasjoner på info-format inneholder selv forslag til hva
+som burde stå i meny-entryen. Disse forslagene kan i så fall finnes
+mot toppen av den aktuelle info-filen. Flex har f.eks. følgende tekst
+i toppen av ``<CODE>flex.info</CODE>'':
+
+<LISTING>
+ START-INFO-DIR-ENTRY
+ * Flex: (flex). A fast scanner generator
+ END-INFO-DIR-ENTRY
+</LISTING>
+
+Den aktuelle linjen kan derfor bare klippes og limes rett inn i den
+aktuelle <CODE>dir</CODE>-filen. I dette tilfellet
+``<CODE>flex.dir.compilers</CODE>''. Man bør derimot passe på å
+starte forklaringen av dokumentasjonen (i vår tilfelle ``<EM>A
+fast...</EM>'') på kolonne 33. Dette fører til at alle forklaringene
+blir pent <EM>alignet</EM> ca. langs midten av emacs-vinduet, xtermen,
+eller hvor nå enn dokumentasjonen skal leses.
+
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Environment-konfigurering </TITLE>
+<!-- Changed by: Espen Skoglund, 23-Apr-1996 -->
+</HEAD><BODY>
+
+<H1> Environment-konfigurering </H1>
+
+For enkelte applikasjoner er det nødvendig at spesielle
+environment-variabler er satt for at applikasjonen i det hele tatt
+skal fungere. Det kan f.eks. hende at nye filstier må legges inn i
+<CODE>PATH</CODE> eller <CODE>MANPATH</CODE>-variablene, eller at
+andre applikasjonsspesifikke variabler må settes
+(eks. <CODE>FMHOME</CODE> i FrameMaker).
+
+<P>Det er derimot ønskelig at brukerne skal slippe å vite om disse
+variablene -- de skal automatisk konfigureres inn i brukerens oppsett.
+Et filsett, <CODE>env-config</CODE>, i <EM>store</EM> sørger for
+dette.
+
+<P>I katalogen <CODE>/store/etc/ENV</CODE> ligger det en rekke filer
+``<CODE>ENV-*</CODE>'' som forteller noe om hvlike
+environment-variabler som må settes. Disse filene hører til
+forskjellige filsett (<CODE>teTeX</CODE>, <CODE>postgres95</CODE>,
+osv.). Filsettet <CODE>env-config</CODE> inneholder dessuten noen
+default-variabler som det ikke passer å spesifisere i de andre
+filsettene (eks. <CODE>TZ</CODE> og <CODE>XFILESEARCHPATH</CODE>, samt
+standardverdier for <CODE>PATH</CODE> og <CODE>MANPATH</CODE>).
+
+<P>Alt hva vi behøver for å konfigurere brukernes environment-oppsett
+til vår applikasjon, er derfor å snekre i sammen en slik fil som
+spesifiserer hvilke variabler som må settes.
+
+<H3> Konfigurasjonsfilenes format </H3>
+
+La oss se på formatet som disse konfigusrasjons-filene har.
+
+<UL>
+<LI>Blanke linjer, samt kommentarer (linjer som begynner
+ med <CODE>#</CODE>) blir ignorert.
+
+<P><LI>Dersom tekststrengene <CODE>$TOP</CODE> eller
+ <CODE>$TOPDIR</CODE> forekommer, blir dette byttet ut med filstien
+ til linktre-roten (typisk <CODE>/store</CODE>).
+
+<P><LI>Formatet på de resterende linjene, er som følger:
+
+ <BLOCKQUOTE><CODE>
+ <I><uid></I>:<I><gid></I>:<I><pri></I>:<I><type></I>:<I><variabel></I>=<I><verdi></I>
+ </CODE></BLOCKQUOTE>
+
+ <DL>
+ <DT><CODE><uid></CODE>
+ <DD>Er en kommaseparert liste av brukere (dvs. bruker-id'er) som skal
+ ha variabelen satt (f.eks. ``<CODE>espensk,geiri</CODE>'').
+ Dersom feltet består av ``<CODE>*</CODE>'', vil alle brukere få
+ variabelen satt. Komplimentet av brukere kan også spesifiseres
+ ved å benytte ``<CODE>!</CODE>''. ``<CODE>!root</CODE>''
+ forteller f.eks. at alle brukerne utenom root-brukeren skal ha
+ variabelen satt. Man kan forøvrig benytte tall-uider i denne
+ listen også, disse vil da bli oversatt til navn-uider dersom det
+ lar seg gjøre.
+
+ <P><DT><CODE><gid></CODE>
+ <DD>Er en kommaseparert liste over grupper (dvs. gruppe-id'er) som
+ skal ha variabelen satt. ``<CODE>/usr/bin/groups</CODE>''
+ benyttes for å bestemme hvilke grupper den aktuelle brukeren er
+ medlem av. Formatet er forøvrig likt det som benyttes for
+ <CODE><uid></CODE>.
+
+ <P><DT><CODE><pri></CODE>
+ <DD>Forteller hvliken prioritet denne variabelsettingen har. I
+ filstier benyttes dette til å fortelle hvor tidlig i stien
+ verdien skal settes. I <CODE>PATH</CODE> har
+ f.eks. ``<CODE>/store/bin</CODE>'' prioritet 5 og
+ ``<CODE>/store/opt/krb5/bin</CODE>'' priotitet 4. Dette fører
+ til at ``<CODE>/store/opt/krb5/bin</CODE>'' havner før
+ ``<CODE>/store/bin</CODE>'' i den ferdige stien.
+
+ <P>Dersom vi har med vanlige verider å gjøre (dvs. alle verdier
+ som ikke er stier) vil dette fungere som en helt vanlig
+ priotitet. <CODE>TZ</CODE> med prioritet 4 benyttes f.eks. før
+ <CODE>TZ</CODE> med prioritet 5.
+
+ <P><DT><CODE><type></CODE>
+ <DD>Forteller hvilken type variabel vi har med å gjøre.
+ <DL COMPACT>
+ <DT><CODE>p</CODE> -
+ <DD>sier at vi har med stier å gjøre. Alle enhetene i denne
+ variablen blir sjekket for eksistens i filtreet før de blir
+ lagt til. Hvis vi f.eks. legger
+ ``<CODE>/usr/ingres/bin</CODE>'' inn i <CODE>PATH</CODE>,
+ vil dette bare gjelde på lglaben (og andre steder hvor
+ ingres er installert).
+ <DT><CODE>n</CODE> -
+ <DD>sier også at vi har med stier å gjøre. Forskjellen er at disse
+ stiene ikke blir sjekket for eksistens. Dette er nyttig når
+ vi f.eks. definerer <CODE>XFILESEARCHPATH</CODE> til å være
+ ``<CODE>/store/lib/X11/app-defaults/%N</CODE>''. I dette
+ tilfellet finnes jo ingen slik katalog.
+ <DT><CODE>s</CODE> -
+ <DD>sier at vi har med en enkel verdi å gjøre (f.eks.
+ <CODE>TZ</CODE>).
+ </DL>
+
+ <P><DT><CODE><variabel>=<verdi></CODE>
+ <DD>Dersom variabelen er en enkel verdi (type <CODE>s</CODE>), blir
+ variabelen (eventuelt) satt til den gitte verdien. Dersom
+ variabelen derimot er en sti (type <CODE>p</CODE> eller
+ <CODE>n</CODE>), blir den gitte verdien (eventuelt) lagt til i
+ stien.
+ </DL>
+
+ <P>Hvis en linje ender med ``<CODE>\</CODE>'' (backslash), blir
+ linjen konkatinert med neste linje, og et ``<CODE>:</CODE>'' (kolon)
+ blir satt som skille mellom dem. Dette er nyttig dersom du
+ spesifiserer en sti bestående av flere elementer, og ønsker å rydde
+ opp i konfigurasjonsfilen. Følgende to settinger er altså like:
+
+ <LISTING>
+ *:*:2:p:PATH=/opt/ansic/bin \
+ /opt/nettladm/bin \
+ /opt/graphics/common/bin
+
+ *:*:2:p:PATH=/opt/ansic/bin:/opt/nettladm/bin:/opt/graphics/common/bin
+ </LISTING>
+
+ Begge sier at alle brukere (og alle grupper) skal ha de 3 filstiene
+ lagt til i <CODE>PATH</CODE>. Siden prioriteten er høy (2), vil
+ disse elementene havne langt frem i stien. Siden variabel-settingen
+ er av type <CODE>p</CODE>, vil eksistensen til hver av katalogene
+ bli sjekket før de blir tatt med. Dvs. at dersom f.eks. katalogen
+ ``<CODE>/opt/graphics/common/bin</CODE>'' ikke eksisterer, vil den
+ ikke bli tatt med i den ferdige stien.
+
+ <P>Den typiske bruken av environment-settinger, er derimot meget
+ enkel. Som oftest ønsker vi bare å legge til et enkelt element i
+ <CODE>PATH</CODE> og/eller <CODE>MANPATH</CODE>. Dette gjelder
+ f.eks. for Kerberos-applikasjonen. Filsettet inneholder derfor en
+ fil ``<CODE>etc/ENV/ENV-kerberos</CODE>''. Innholdet i denne filen
+ er:
+
+ <LISTING>
+ #
+ # Kerberos settings
+ #
+ *:*:4:p:PATH=$TOPDIR/opt/krb5/bin
+ *:*:4:p:MANPATH=$TOPDIR/opt/krb5/man
+ </LISTING>
+
+ Vi ser også at filen inneholder en liten kommentar. Dette er smart
+ fordi det fører til at
+
+ <LISTING>
+ $ <I>cat /store/etc/ENV/ENV-*</I>
+ </LISTING>
+
+ gir nogenlunde fornuftig output.
+
+</UL>
+
+<H3> Hvordan benytte seg av det ferdiggenererte oppsettet </H3>
+
+
+Applikasjonen <CODE>env-config</CODE> genererer filene
+<CODE>/store/etc/src.sh</CODE> og <CODE>/store/etc/src.csh</CODE> hver
+natt ved hjelp av en <EM>nightly command</EM>. De genererte filene er
+i henholdsvis <EM>bourne-shell</EM> og <EM>c-shell</EM> format, og kan
+``<EM>sources</EM>'' av andre shell-oppstart-filer (eller interaktivt
+av brukerne) dersom det er ønskelig. <CODE>Zsh</CODE> genererer
+dessuten sin egen <CODE>/store/skel/zshenv</CODE> hver natt slik at
+den ikke behøver å <EM>source</EM> noen av disse filene.
+
+<P>Dersom applikasjoner ønsker å konfigurere dette selv, slik som
+f.eks. <CODE>zsh</CODE> gjør, er det ønskelig at koden i
+<CODE>env-config</CODE> benyttes. Eksempel på perl-kode følger:
+
+<LISTING>
+ require "$ENV{'TOPDIR'}/lib/environment/environ.pl";
+
+ %Env = &Env'read_env( "$ENV{'TOPDIR'}/etc/ENV" );
+ $Tekst_som_må_inkluderes_i_skript = &Env'build_env( %Env );
+</LISTING>
+
+Den aktuelle teksten kan dermed plasserers hvor det måtte være
+ønskelig (eks. <CODE>/store/skel/zshenv</CODE>).
+``<CODE>&Env'build_csh_env</CODE>'' kan også benyttes istedenfor
+``<CODE>&Env'build_env</CODE>'' dersom <EM>csh</EM>-syntaks er
+ønskelig.
+
+<P>Filsett som skal benytte seg av environment-konfigurasjonene bør
+settes til å ha <EM>dependency</EM> <CODE>env-config</CODE> (dette
+gjelder f.eks. <CODE>zsh</CODE>). Hvis ikke dette blir gjort vil ikke:
+
+<UL>
+ <LI>``<CODE>environ.pl</CODE>'' kunne inkluderes i perl-skript
+ (dersom det benyttes).
+ <LI>``<CODE>etc/src.sh</CODE>'' eller ``<CODE>etc/src.csh</CODE>''
+ vil ikke eksistere (dersom dette f.eks. skulle <EM>sources</EM> i
+ oppstartfilene).
+ <LI>Default-konfigurasjonene vil ikke eksitere. Dette vil føre til
+ at vi bl.a. ville få en meget slank <CODE>PATH</CODE> og
+ <CODE>MANPATH</CODE>.
+</UL>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Kompilering i store </TITLE>
+<!-- Changed by: Espen Skoglund, 23-Apr-1996 -->
+</HEAD><BODY>
+
+<H1>Kompilering i store</H1>
+
+Hvordan man kompilerer selve applikasjonen i <EM>store</EM> kan man
+ikke si noe særlig generelt om. Instruksjoner om hvordan dette skal
+foregå vil man finne forklart i distribusjoenen til den enkelte
+applikasjon (typisk i en fil med navn INSTALL eller README).
+
+<P>Det man derimot må passe på når man kompilerer programmer, er at
+filstier som blir hardkodet inn i programmene benytter prefiksen
+<CODE>/store</CODE> istedenfor den filstien som blir foreslått (typisk
+<CODE>/usr/local</CODE>).
+
+<H3> Kommandoene unshadow og fix </H3>
+
+Ved kompileringen vil det ofte være nødvendig å forandre på en eller
+flere filer for å tilpasse applikasjonen til de lokale omgivelsene.
+Dette kan være f.eks. makefiler eller konfigurasjonsfiler. Vi ønsker
+derimot ikke å forandre på de orginale filene som følger med
+distribusjonen (konfigurasjoner som gjelder for <EM>hpux</EM> vil
+sansynligvis ikke gjelde for <EM>solaris</EM>), og må derfor kopiere
+filen over til skyggetreet slik at vi forandrer på kopien av filen
+istedenfor orginalen. Til dette benytter vi kommandoen
+<CODE>unshadow</CODE>. Hvis vi f.eks. skal forandre på en fil
+<CODE>src/config.h</CODE>, kan vi skrive:
+
+<LISTING>
+ $ <I>unshadow src/config.h</I>
+</LISTING>
+
+Deretter kan vi editere filen etter behov. Som oftest ønsker vi å
+kjøre <CODE>unshadow</CODE> på en fil fordi vi vil forandre den. Av
+denne grunnen finnes også en kommando <CODE>fix</CODE> som kjører
+<CODE>unshadow</CODE> på den spesifiserte filen, og deretter starter
+opp <CODE>vi</CODE> på den. Følgende to kommandosekvenser er derfor
+like:
+
+<LISTING>
+ $ <I>unshadow Makefile</I>
+ $ <I>vi Makefile</I>
+
+ $ <I>fix Makefile</I>
+</LISTING>
+
+
+<H3> Configure-skript </H3>
+
+For alle GNU pakker, og en stor del av andre programpakker, så følger
+det et konfigurasjonsskript med i programpakke-distribusjonen. For
+slike pakker er kompileringen i <EM>store</EM> særdeles enkel. Alt
+man behøver å gjøre, er å spesifisere en prefiks, <CODE>/store</CODE>,
+til konfigurasjonsskriptet. Dette er også tilfelle for pakken
+<CODE>sharutils</CODE>. Vi skriver derfor:
+
+<LISTING>
+ $ <I>./configure --prefix=/store</I>
+</LISTING>
+
+I noen tilfeller kan det også være nødvendig å spesifisere hvilken
+c-kompilator man skal benytte. Dette skulle her på installasjonen
+pr. default bli satt til <CODE>cc</CODE>, men man vet jo aldri hva som
+kommer til å hende over natten. En enkel måte å spesifisere dette på,
+er å kjøre <CODE>configure</CODE> på følgende måte:
+
+<LISTING>
+ $ <I>CC=cc ./configure --prefix=/store</I>
+</LISTING>
+
+Etter at <CODE>configure</CODE> har kjørt ferdig behøver man
+forhåpentligvis bare å starte <CODE>make</CODE>. Programpakken burde
+da kompilere seg ferdig uten problemer.
+
+<LISTING>
+ $ <I>make</I>
+</LISTING>
+
+<H3> Spesifisering av bibliotek </H3>
+
+Dersom du spesifiserer søkestien for bibliotek som skal benyttes under
+kompileringen (opsjonen <CODE>-L</CODE> til cc eller ld), så bør stier
+som er mest mulig standard spesifiseres. Å spesifisere f.eks.
+``<CODE>-L/usr/local1/lib</CODE>'' er mao. en lite lur ting å gjøre --
+dette for at programmet da sansynligvis bare vil fungere på tklaben.
+Katalogen <CODE>/usr/local1</CODE> eksisterer nemlig ikke andre steder
+på installasjonen.
+
+<P>Å benytte <CODE>/usr/local</CODE> i <EM>store</EM> er generelt sett
+lite ønskelig. Grunnen til at vi vil konvertere til <EM>store</EM> er
+jo bl.a. fordi vi ønsker å gå bort ifra et uoversiktlig
+<CODE>/usr/local</CODE>-system. Å gjøre appliksjoner i <EM>store</EM>
+avhengig av <CODE>/usr/local</CODE> gjør ikke denne konverteringen
+enklere.
+
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Store </TITLE>
+<!-- Changed by: Espen Skoglund, 24-Apr-1996 -->
+</HEAD><BODY>
+
+<H1>Store</H1>
+
+<UL>
+ <LI><A HREF="install.html"><B>Installering i Store</B></A><BR>
+ Detaljert instruksjon om hvordan man installerer applikasjoner
+ under <EM>store</EM>. Dokumentasjonen er spesielt tilpasset
+ lokale preferanser.
+
+ <LI><A HREF="http://www.pvv.unit.no/~arnej/store/storedoc.html"><B>Store-dokumentasjon</B></A> fra PVV.<BR>
+ En nokså spinkel dokumentasjon, men inneholder en god introduksjon
+ til selve store-konseptet. Dette er samme dokumentasjon som
+ finnes under <CODE>/store/doc/store-doc/</CODE>, og som kan
+ aksesserer fra emacs-info-sidene.
+</UL>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
\ No newline at end of file
--- /dev/null
+<HTML><HEAD>
+<TITLE> Installerting i store </TITLE>
+<!-- Changed by: Espen Skoglund, 24-Apr-1996 -->
+</HEAD><BODY>
+
+<H1>Installering i store</H1>
+
+Den enkleste måten å forstå hvordan kompilering i store foregår, er
+ved å benytte et eksempel. I dette tilfellet benytter vi GNU Sharutils.
+
+<UL>
+ <LI><A HREF="pre-install.html"><B>Forberedelse til kompilering</B></A>
+ <LI><A HREF="in-install.html"><B>Kompilering</B></A>
+ <LI><A HREF="post-install.html"><B>Arbeid etter kompileringen</B></A>
+ <LI><A HREF="spec-config.html"><B>Spesielle konfigureringer</B></A>
+ <UL>
+ <LI><A HREF="environ.html">Environment-konfigurering</A>
+ <LI><A HREF="mailcap.html">Mailcap-konfigurering</A>
+ <LI><A HREF="emacs-dir.html">Tilrettelegging av emacs-info-sider</A>
+ <LI><A HREF="emacs-default.html">Tilrettelegging
+ av emacs-konfig-filer</A>
+ </UL>
+</UL>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Mailcap-konfigurering </TITLE>
+<!-- Changed by: Espen Skoglund, 24-Apr-1996 -->
+</HEAD><BODY>
+
+<H1> Mailcap-konfigurering </H1>
+
+Mange applikasjoner har muligheten til å håndtere spesielle
+media/fil-formater. XV kan f.eks. håndtere en rekke grafikkformater.
+XAnim kan håndtere en rekke video-formater, osv. Det er ønskelig at
+disse applikasjonene skal benyttes av f.eks. <CODE>metamail</CODE> og
+<CODE>netscape</CODE>.
+
+<P>For å få dette til, lager en del applikasjoner mailcap-filer som
+den benytter seg av. <CODE>Metamail</CODE> lager f.eks. en fil
+``<CODE>/store/etc/mailcap</CODE>'', og <CODE>netscape</CODE> lager en
+fil ``<CODE>/store/lib/netscape/mailcap</CODE>''. Disse filene
+genereres ut ifra innholder av filene som finnes under:
+
+<BLOCKQUOTE>
+ <CODE>/store/etc/mailcaps</CODE>
+</BLOCKQUOTE>
+
+I denne katalogen eksisterer en del filer med navn på formen:
+
+<BLOCKQUOTE>
+ <CODE>mailcap-<I><navn></I>-<I><prioritet></I></CODE>
+</BLOCKQUOTE>
+
+Hver av disse filene inneholder én eller flere mailcap-entryer
+som tilsammen bygger opp den fullstendige mailcap-filen.
+``<EM>Navn</EM>'' forteller hvilken applikasjon de aktuelle
+mailcap-entryene gjelder for (f.eks. <CODE>xv</CODE> eller
+<CODE>xanim</CODE>). ``<EM>Prioritet</EM>'' forteller hvilken
+prioritet disse mailcap-entryene har. Vi har f.eks. en fil,
+``<CODE>mailcap-arena-9</CODE>'', som inneholder:
+
+<LISTING>
+ text/html; /store/bin/arena %s
+</LISTING>
+
+og en fil, ``<CODE>mailcap-netscape-4</CODE>'', som inneholder
+
+<LISTING>
+ text/html; /store/bin/netscape -remote openFile\\(%s\\)
+</LISTING>
+
+Begge mailcap-entryene gjelder for <EM>content-typen</EM>;
+``<CODE>text/html</CODE>''. Netscape sitt mailcap-entry blir derimot
+foretrukket fordi den har bedre prioritet.
+
+<P>Flere felter kan også spesifiseres i mailcap-entryen. De
+applikasjonene som ikke forstår dette (f.eks. <CODE>netscape</CODE>),
+filtrerer ut ukjent informasjon før den genererer sin egen
+mailcap-fil. Feltene blir puttet sammen slik at de danner en mest
+mulig fullstendig mailcap-entry. La oss f.eks. tenke oss at
+<CODE>frame</CODE> hadde muligheten til å håndtere PDF-dokumenter.
+Dersom vi ga argumentet ``<CODE>-savepdf</CODE>'' til
+<CODE>imaker</CODE>, ville dokumentet bli lagret i PDF-format. Vi
+kunne da hatt følgende situasjon:
+
+<P>``<CODE>mailcap-acroread-5</CODE>'' inneholder:
+
+<LISTING>
+ application/pdf; /store/bin/acroread %s ; \
+ description = "Portable Document Format"
+</LISTING>
+
+``<CODE>mailcap-frame-9</CODE>'' inneholder:
+
+<LISTING>
+ application/pdf; /store/opt/frame5/bin/imaker -run_in_fg -f %s ; \
+ compose = /store/opt/frame5/bin/imaker -run_in_fg -savepdf -f %s
+</LISTING>
+
+Siden <CODE>acroread</CODE> har prioritet 5, og <CODE>imaker</CODE>
+prioritet 9, ville <CODE>acroread</CODE> bli benyttet fremfor
+<CODE>imaker</CODE> for å vise PDF-dokumenter. <CODE>Imaker</CODE> er
+derimot alene om å kunne lage PDF-dokumenter, og den resulterene
+mailcap-entryen ville derfor bli:
+
+<LISTING>
+ application/pdf; /store/bin/acroread %s ; \
+ description = "Portable Document Format" ; \
+ compose = /store/opt/frame5/bin/imaker -run_in_fg -savepdf -f %s
+</LISTING>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Arbeid etter kompileringen </TITLE>
+<!-- Changed by: Espen Skoglund, 23-Apr-1996 -->
+</HEAD><BODY>
+
+<H1>Arbeid etter kompileringen</H1>
+
+<OL>
+<LI><H3>Make install</H3>
+ Når du har kompilert ferdig programpakken i skyggetreet, gjenstår
+ det bare å installere pakken. Dette består som oftest i å skrive:
+
+ <LISTING>
+ $ <I>make install</I>
+ </LISTING>
+
+ Dersom du har konfigurert makefilene riktig, eller kjørt
+ <CODE>configure</CODE> med korrekte argumenter, vil binærfiler,
+ bibliotek, manualer, etc. bli installert under
+ <CODE>/store/bin</CODE>, <CODE>/store/lib</CODE>,
+ <CODE>/store/man</CODE>, osv.
+
+<P><LI><H3>Postinst</H3>
+ Disse filene må nå flyttes over til versjonstreet, og symbolske
+ lenker fra linktreet til versjonstreet må opprettes. Kommandoen
+ <CODE>postinst</CODE> gjør dette for deg.
+
+ <LISTING>
+ $ <I>postinst</I>
+ Architecture suffix [hp700ux9] ?
+ Server [tklab1] ?
+ Application [sharutils] ?
+ Version [4.2] ?
+ Linktree [tklab1] ?
+ </LISTING>
+
+ Som ved <CODE>shadow</CODE>-kommandoen, blir du også her konfrontert
+ med en del spørsmål. Og som ved <CODE>shadow</CODE>-kommandoen, vil
+ default-verdiene som regel være korrekte.
+
+ <P>Hva <CODE>postinst</CODE>-kommandoen egentlig gjør, er at den
+ søker gjennom hele linktreet og finner de filene som ikke er
+ sumbolske linker, og som er yngre en 10 minutter gammel. Når den
+ finner en slik fil,
+
+ <BLOCKQUOTE>
+ <CODE>/store/<filsti></CODE>,
+ </BLOCKQUOTE>
+
+ vil den flytte denne til sin respektive plass i versjonstreet,
+
+ <BLOCKQUOTE>
+ <CODE>/store/store/tklab1/<applikasjon>/ver-<versjon>/<filsti></CODE>.
+ </BLOCKQUOTE>
+
+ En symbolsk lenke blir så opprettet fra linktreet til denne filen.
+
+ <P><CODE>Postinst</CODE> sjekker også (ved å benytte kommandoen
+ <CODE>file</CODE>), hvilken type fil den holder på å flytte. Dersom
+ filen er arkitekturavhengig, vil en arkitetkursuffiks bli lagt til
+ ved installeringen. Dersom filen ikke er arkitekturavhengig, vil
+ ingen slik suffiks bli lagt til. Ved installeringen av
+ <CODE>sharutils</CODE> vil f.eks. følgende to symbolske lenker bli
+ opprettet.
+
+ <LISTING>
+ /store/bin/shar -> /store/store/tklab1/sharutils/ver-4.2/bin/shar@hp700ux9
+ /store/info/sharutils.info -> /store/store/tklab1/sharutils/ver-4.2/info/sharutils.info
+ </LISTING>
+
+ Ved enekelte anledninger ønsker du kanskje å installere filer som er
+ eldre enn 10 minutter fra linktreet. Dette kan du gjøre ved å gi
+ argumentet ``<CODE>-t <minutter></CODE>'' til
+ <CODE>postinst</CODE>. Du spesifiserer da en maksimalalder på
+ filene du ønsker å installere, gitt i minutter. Dette er særlig
+ nyttig for programpakker som benytter <CODE>tar</CODE> for å
+ installere filene sine i linktreet (f.eks. emacs).
+ Modifikasjonsdatoen til de installerte filene blir da uendret, og
+ filene kan bli flere år gamle.
+
+<P><LI><H3>Spesielle konfigureringer</H3>
+ Dersom programpakken inneholder emacs-info-sider, inneholder
+ konfigurasjonskode som skal tas med i emacs, har programmer som skal
+ legges inn i diverse mailcap-filer, eller behøver at spesielle
+ environment-variabler er satt, så må dette konfigureres på en
+ spesiell måte. Se på siden <EM>``<A
+ HREF="spec-config.html">Spesielle konfigureringer</A>''</EM> for
+ nærmere informasjon.
+
+<P><LI><H3>Register</H3>
+ Når du har gjort deg ferdig med installeringen, må du registrere
+ applikasjonen slik at de interne programmene i <EM>store</EM> vet
+ hva du har installert, og kan installere det på andre maskiner i
+ løpet av neste natt. Dette gjøres ved å kjøre kommandien
+ <CODE>register</CODE>:
+
+ <LISTING>
+ $ <I>register</I>
+ What store [tklab1] ?
+ What application [sharutils] ?
+ (Info) (register) <sharutils@tklab1> Updating registration.
+
+ (Warning) (register) <sharutils@tklab1> YOU MUST RUN chkapp MANUALLY.
+
+ Full name . ... ... [] ? <I>Shar utilities</I>
+
+ Available versions are: 4.2 - choose primary:
+ Primary Version ... [4.2] ?
+ Program Type .. ... (? for list) [] ? <I>arc</I>
+ License Type .. ... (? for list) [] ? <I>gpl</I>
+ Release level for version 4.2 [release] ?
+ Signature . ... ... [] ? <I>eSk</I>
+ Short Description . (max 30 chars) [] ?
+ ==><I>Shell archiving utilities</I> <==
+ XXX - fix sourcecode count (TODO)
+ Online Help ... ... [none] ?
+ Importance ... ... [5] ?
+ Source ... ... ... [] ? <I>ftp://prep.ai.mit.edu/pub/gnu/sharutils-${version}.tar.gz</I>
+ Nightly Command ... [] ?
+ Not Links . ... ... [] ?
+ Dependencies .. ... [] ?
+ Current description is:
+ :
+ Do you want to edit the description [N] ? <I>y</I>
+ Enter text to be appended (terminate with '.')
+ <I>Husk å fikse emacs-info-sidene.
+ .</I>
+ </LISTING>
+
+ Som vi ser, blir en del default-verdier presentert også her. Hva de
+ forskjellige feltene skal inneholde er forsåvidt ganske
+ selvinnlysende. Noen ord er allikevel på sin plass her:
+
+ <P><DL>
+ <DT><EM>Full name</EM>, <EM>Short Description</EM> og <EM>Description</EM>
+ <DD>Bør være skrevet på engelsk. Det er planer om å lage et
+ web-grensesnitt mot <EM>store</EM>, og teksten her vil
+ sansynligvis bli engelsk. Dersom noe tekst er skrevet på norsk,
+ og noe på engelsk vil ting se lite pent ut. Konsistens må man
+ kunne forlange.
+
+ <P><EM>Short description</EM> blir forresten brukt til
+ bl.a. generering av rapporter. <EM>Description</EM> blir benyttet
+ til bl.a. generering av news-meldinger. Et eksempel på en slik
+ <EM>description</EM> kan være:
+
+ <BLOCKQUOTE><CITE>
+ Shar makes so-called shell archives out of many files, preparing
+ them for transmission by electronic mail services. Unshar helps
+ unpacking shell archives after reception.
+ </CITE></BLOCKQUOTE>
+
+ <DT><EM>Release level</EM>
+ <DD>Forteller hvilken type utgivelse en gitt versjon av en applikasjon er
+ (eks. beta eller stable). Dette, sammen med profileringen til et
+ gitt linktre, bestemmer hvilken versjon av appliaksjonen som skal
+ installeres i linktreet. Følgende profileringer gjelder for
+ installasjonen (rekkefølgen av <EM>release levels</EM> forteller
+ hvordan hver profilering prioriterer utgivelsene):
+
+ <P><EM>Newer:</EM> override alpha beta gamma release stable
+ dated old obsolete prealpha
+ <BR><EM>Normal:</EM> override stable release gamma dated beta
+ old alpha obsolete prealpha
+
+ <P>For tklabben benyttes <EM>newer</EM>, og for resten av
+ installasjonen benyttes <EM>normal</EM>. Prioriteten av
+ <EM>release levels</EM> ovenfor bestemmer hvilken versjon som skal
+ installeres av en gitt applikasjon.
+
+ <P>Eks: Vi har versjon 1.4 av en applikasjon installert i
+ <EM>store</EM>, og denne versjonen er satt til relase level,
+ ``<EM>release</EM>''. Vi installerer nå versjon 2.001 av samme
+ applikasjon, og setter release level til ``<EM>beta</EM>''. Dette
+ vil føre til at versjon 2.001 vil bli installert på tklaben, mens
+ versjon 1.4 blir installert andre steder. <P>
+
+ <DT><EM>Importance</EM>
+ <DD>Forteller hvor viktig applikasjonen er. Jo høyere tall, jo viktigere
+ er applikasjonen. <CODE>Perl-internal</CODE> har
+ f.eks. <EM>importance</EM> 9 fordi hele <EM>store</EM> baserer seg
+ på dette filsettet.
+
+ <P>Foreløpig blir ikke dette feltet meget benyttet. Et unntak er
+ noen lokale patcher til <CODE>perl-internal</CODE> som gjør at
+ dersom det skjer en konflikt i navnerommet (eks. to filer som
+ heter <CODE>/store/etc/config</CODE>), så vil kun det viktigeste
+ filsettet få filen installert. <P>
+
+ <DT><EM>Source</EM>
+ <DD>Inneholder informasjon om hvor kildekoden kan bli funnet. Dette
+ feltet benyttes bl.a. for å kunne fortelle administratorene når en
+ ny versjon av programpakken kommer. <EM>Store</EM> kan også
+ konfigureres slik at denne nye pakken automatisk blir hentet.
+
+ <P>På grunn av at dette feltet skal benyttes internt av
+ <EM>store</EM>, må feltet ha en gitt syntaks. Adresser kan enten
+ spesifiseres på URL-form som vist ovenfor (ved å benytte en av
+ protokollene HTTP eller FTP), eller de kan spesifiseres på
+ følgende måte:
+
+ <BLOCKQUOTE>
+ <CODE>prep.ai.mit.edu:/pub/gnu/sharutils-${version}.tar.gz</CODE>
+ </BLOCKQUOTE>
+
+ som også spesifiserer at FTP skal benyttes. Der det er mulig bør
+ en FTP-adresse benyttes fremfor HTTP -- dette fordi FTP i
+ motsetning til HTTP alltid kan gi en liste over innholder i en
+ katalog. Det stedet i adressen som inneholder versjonsnummeret
+ til pakken, må også spesifiseres som vist i eksempelet.
+ <P>
+
+ <DT><EM>Nightly command</EM>
+ <DD>Spesifiserer en kommando som blir kjørt hver natt (fra skriptet
+ <CODE>cclient</CODE>), og hver gang en <CODE>linkup</CODE> blir
+ gjort på applikasjonen. Dette er nyttig for programmer som
+ f.eks. ønsker å generere konfig-filer, indekser, etc. på grunnlag
+ av hva som ellers er installert i linktreet.
+
+ <P>Envirnoment-variabelen <CODE>$TOPDIR</CODE> blir også satt slik
+ at man kan benytte den i eventuelle skripter som blir startet.
+ Denne variabelen forteller hva filstien til rota i linktreet er
+ (typisk <CODE>/store</CODE>). For å starte et perlskript i
+ linktreet hver natt, kan man derfor spesifisere f.eks.:
+
+ <BLOCKQUOTE>
+ <CODE>perl $TOPDIR/etc/make-emacs-dir.pl</CODE>
+ </BLOCKQUOTE>
+
+ Flere kommandoer kan dessuten spesifiseres ved å skille dem med
+ <CODE>;</CODE> (semikolon).
+ <P>
+
+ <DT><EM>Not Links</EM>
+ <DD>Forteller om filer som ikke er symbolske lenker, men som allikevel
+ hører med til applikasjonen. Dette kan f.eks. være indeks-filer
+ generert av en <EM>nightly command</EM>, og spesifiseres som et
+ <EM>perl regular expression</EM> med filnavn relativt til
+ linktre-rota. Applikasjonen <CODE>perl-internal</CODE> genererer
+ f.eks. news-meldinger under <CODE>/store/news</CODE>, og har
+ derfor følgende <EM>notlinks regexp</EM>:
+
+ <BLOCKQUOTE>
+ <CODE>news/.*</CODE>
+ </BLOCKQUOTE>
+
+ Dette forhindrer at filene under <CODE>/store/news</CODE> blir
+ slettet av <CODE>cclient</CODE>, eller kopiert opp i et eller
+ annet versjonstre av <CODE>postinst</CODE>. Flere <EM>notlinks
+ regexp</EM> kan gis ved å separere dem med mellomrom (space).
+ <P>
+
+ <DT><EM>Dependencies</EM>
+ <DD>Gir en liste (separert med mellomrom) av applikasjoner som den gitte
+ applikasjonen er avhengig av. <CODE>Exmh</CODE> er
+ f.eks. avhengig av MH, Tcl og Tk. Dette fordi <CODE>exmh</CODE>
+ består av kode skrevet i Tcl/Tk, og det benytter seg av
+ funksjonalitet som MH tilbyr. Dersom en eller flere av disse
+ applikasjonene mangler, vil ikke <CODE>exmh</CODE> bli installert.
+
+ <P>Det er selvfølgelig bare mulig å spesifisere applikasjoner som
+ faktisk ligger i <EM>store</EM> i <EM>dependency</EM>-listen. Det
+ vil ellers være vanskelig for <EM>store</EM>-programmene å vite om
+ den aktuelle applikasjonen faktisk eksisterer på systemet.
+
+ <P>Det er ikke mulig å spesifisere versjonsnummer for
+ appliksjonene, og applikasjonsnavnene må samsvare nøyaktig med
+ navnet som applikasjonen har i <EM>store</EM>. Navnene er også
+ case-sensitive, slik at ``Tcl'' ikke er det samme som ``tcl''.
+ <CODE>Exmh</CODE> har f.eks. følgende <EM>dependency</EM>-liste:
+
+ <BLOCKQUOTE>
+ <CODE>mh tcl tk</CODE>
+ </BLOCKQUOTE>
+
+ </DL>
+
+
+<P><LI><H3>Chkapp</H3>
+ Etter at <CODE>register</CODE> er kjørt, må <CODE>chkapp</CODE>
+ kjøres for å oppdatere listen over hvilke versjoner av applikasjonen
+ som eksisterer, samt hvilke arkitekturen hver versjon har støtte for.
+
+ <LISTING>
+ $ <I>chkapp</I>
+ Which master [tklab1] ?
+ Which application [sharutils] ?
+ </LISTING>
+
+ <CODE>Chkapp</CODE> må dessuten kjøres når der gjøres manuelle
+ forandringer i versjonstreet (f.eks. når filer blir lagt til eller
+ forandret). Kommandoen oppdaterer nemlig en fil
+ <EM>summary.<versjon></EM> som forteller om størrelse,
+ modifikasjonstid, etc. til hver fil i filsettet. Denne filen brukes
+ som en slags cache for de skriptene som kjøres hver natt, og som
+ skal bestemme om evt. nye filer må kopieres rundt om på systemet.
+
+</OL>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Forberedelse til kompilering i store </TITLE>
+<!-- Changed by: Espen Skoglund, 23-Apr-1996 -->
+</HEAD><BODY>
+
+<H1>Forberedelse til kompilering i store</H1>
+
+<OL>
+<LI>Velg maskin du ønsker å bruke for installasjonen. Dersom du ønsker
+ å kompilere applikasjonen for HP-UX 10 kan tklab3 være et godt
+ valg. Dersom du derimot ønsker å kompilere for HP-UX 9 vil nok
+ tklab1 være et bedre valg.
+
+ <P>Hvis du kompilerer for HP-UX 10, må du passe på at <EM>transition
+ linkene</EM> ikke er aktive. Prøv f.eks. å kjøre <CODE>`ll
+ /etc'</CODE>. Dersom du her ser en hel mengde lenker, så er lenkene
+ i bruk. Disse fjernes ved å kjøre kommandoen
+ <CODE>tlremove</CODE> (må kjøres av root-brukeren).
+
+ <P>Vi har her tenkt å kompilere applikasjonen for HP-UX 9, og velger
+ derfor å kompilere dette på tklab1.
+
+ <LISTING>
+ $ <I>rlogin tklab1</I>
+ </LISTING>
+
+<P><LI>Når man skal arbeide med installering i <EM>store</EM>, lønner det
+ seg å være logget inn som <EM>store</EM>-brukeren. Siden
+ <EM>store</EM>-brukeren ikke har passord, må vi først logge inn som
+ root.
+
+ <LISTING>
+ $ <I>su -</I>
+ Password:
+ $ <I>su - store</I>
+ </LISTING>
+
+<P><LI>Dersom en eller annen versjon av applikasjonen ikke eksisterer
+ i <EM>store</EM> fra før, må der lages en plass for den i
+ <EM>store</EM>-treet. Dette gjøres under ved å lage en katalog
+ under <CODE>/store/store/tklab1</CODE> med et fornuftig navn. I
+ vårt tilfelle velger vi å kalle applikasjonen
+ <CODE>sharutils</CODE>.
+
+ <LISTING>
+ $ mkdir /store/store/tklab1/sharutils
+ $ cd /store/store/tklab1/sharutils
+ </LISTING>
+
+<P><LI>Pakk ut applikasjonen. Før vi pakker ut appliksjonen kan det
+ derimot være lurt å sjekke om utpakkingen lager en hel underkatalog,
+ eller om den bare legger ut alle filene i katalogen hvor du befinner
+ deg (`<CODE>tar tf -</CODE>'). Dersom dette siste er tilfellet, vil
+ det være meget lurt å pakke opp applikasjonen i en underkatalog.
+
+ <LISTING>
+ $ <I>gzip -dc ~/tmp/sharutils-4.2.tar.gz | tar xf -</I>
+ </LISTING>
+
+<P><LI>Navngi underkatalogen slik at de interne programmene i <EM>store</EM>
+ forstår hva det er som foregår. Navnet på katalogen som inneholder
+ kildekoden skal være på formen ``<EM>src-<versjon></EM>''.
+
+ <LISTING>
+ $ <I>mv sharutils-4.2 src-4.2</I>
+ </LISTING>
+
+<P><LI>Kildekoden som ligger under katalogen vi nettopp har laget, skal
+ ikke under noen omstendighet røres. Vi lager derfor nye
+ underkatalog hvor vi kan kompilere applikasjonene. Disse katalogene
+ har navn på formen
+ ``<EM>src-<versjon>-<arkitektur></EM>''. Disse
+ katalogene inneholder symbolske lenker inn i katalogen hvor den
+ virkelige kildekoden befinner seg. Et slikt <EM>skyggetre</EM>
+ lages med kommandoen <CODE>shadow</CODE>.
+
+ <LISTING>
+ $ <I>shadow</I>
+ Which compile store [tklab1] ?
+ Which application [sharutils] ?
+ What version [4.2] ?
+ What architecture [hp700ux9] ?
+ </LISTING>
+
+ Som vi ser, får vi en del spørsmål når vi kjører
+ <CODE>shadow</CODE>. Disse spørsmålene har som oftest
+ default-verdier som viser seg å være korrekt. Et par små tastetrykk
+ på return er derfor (som oftest) alt som må til for å lage et lite
+ morsomt skyggetre.
+
+ <P>Et par ord om arkitekturnavnet er kanskje på sin plass her. Vi
+ ser av ekempelet over at HP-UX 9 presenteres ved navnet
+ ``<CODE>hp700ux9</CODE>''. I likhet presenteres HP-UX 10 med navnet
+ ``<CODE>hp700ux10</CODE>''. Dette betyr at arkitekturen en <EM>HP
+ Series 700</EM> maskin som kjører henholdsvis HP-UX 9 eller 10.
+ Dersom en applikasjon bare skal være gjeldene for en spesifikk
+ versjon av operativsystemet, kan dette også spesifiseres nærmere
+ (eks. ``<CODE>hp700ux905</CODE>'' og ``<CODE>hp700ux1001</CODE>'').
+
+ <P>Det er derimot ønskelig å benytte et arkitekturnavn som er mest
+ mulig generelt. Hvis vi f.eks. vil installere noe som skal gjelde
+ både for ``<CODE>hp700ux9</CODE>'' og ``<CODE>hp700ux10</CODE>''
+ (f.eks. en binærdistribusjon av Netscape), kan vi derfor benytte
+ arkitetkturnavnet ``<CODE>hp700</CODE>''. På samme måte kan vi
+ benytte arkitekturnavnet ``<CODE>allarchs</CODE>'' til å bety alle
+ mulige arkitekturerer. Dette er f.eks. nyttig for applikasjoner som
+ er skrevet i et abstrakt, arkitekturuavhengig språk
+ (eks. <CODE>exmh</CODE>).
+
+ <P>Arkitekturnavnet ``<CODE>local</CODE>'' har også en spesiell
+ betydning. Hvis vi lager et skyggetre med denne arkitekturen, så
+ kan vi gjøre store lokale patcher her. Når vi neste gang
+ skal lage et skyggetre til f.eks. ``<CODE>hp700ux9</CODE>'', så vi
+ dette <CODE>local</CODE>-treet bli skygget -- ikke det uberørte,
+ orginale kildekodetreet.
+
+<P><LI>Vi er nå klar til å ta fatt på selve kompileringen.
+
+ <LISTING>
+ $ <I>cd src-4.2-hp700ux9</I>
+ </LISTING>
+
+</OL>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HTML><HEAD>
+<TITLE> Spesielle kofigureringer </TITLE>
+<!-- Changed by: Espen Skoglund, 24-Apr-1996 -->
+</HEAD><BODY>
+
+<H1> Spesielle konfigureringer </H1>
+
+Dersom en programpakke inneholder emacs-info-sider, inneholder
+konfigurasjonskode som skal tas med i emacs, har programmer som skal
+legges inn i diverse mailcap-filer, eller behøver at spesielle
+environment-variabler er satt, må dette konfigureres på en spesiell
+måte.
+
+<UL>
+ <LI><A HREF="environ.html">Environment-konfigurering</A>
+ <LI><A HREF="mailcap.html">Mailcap-konfigurering</A>
+ <LI><A HREF="emacs-dir.html">Tilrettelegging av emacs-info-sider</A>
+ <LI><A HREF="emacs-default.html">Tilrettelegging av emacs-konfig-filer</A>
+</UL>
+
+<HR>
+<ADDRESS><A HREF="/~espensk/">eSk</A></ADDRESS>
+
+</BODY></HTML>
--- /dev/null
+<HR>
+Automatic software distribution via HTTP
+<p>
+
+STORE in WWW.
+<p>
+
+
+Automatisk oppgradering av web-browsere
+<p>
+
+.../storetar/info?app=sdf
+<p>
+
+.../storetar/list?arch=linux
+<p>
--- /dev/null
+%!PS-Adobe-2.0
+%%Creator: dvipsk 5.55a Copyright 1986, 1994 Radical Eye Software
+%%Title: paper.dvi
+%%Pages: 14
+%%PageOrder: Ascend
+%%BoundingBox: 0 0 596 842
+%%EndComments
+%DVIPSCommandLine: dvips -Pljfour -o paper.ps paper
+%DVIPSParameters: dpi=600, comments removed
+%DVIPSSource: TeX output 1995.06.19:0158
+%%BeginProcSet: tex.pro
+/TeXDict 250 dict def TeXDict begin /N{def}def /B{bind def}N /S{exch}N
+/X{S N}B /TR{translate}N /isls false N /vsize 11 72 mul N /hsize 8.5 72
+mul N /landplus90{false}def /@rigin{isls{[0 landplus90{1 -1}{-1 1}
+ifelse 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
+isls{landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div
+hsize mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul
+TR[matrix currentmatrix{dup dup round sub abs 0.00001 lt{round}if}
+forall round exch round exch]setmatrix}N /@landscape{/isls true N}B
+/@manualfeed{statusdict /manualfeed true put}B /@copies{/#copies X}B
+/FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{
+/nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N
+string /base X array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N
+end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{
+/sf 1 N /fntrx FMat N df-tail}B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]
+N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup
+length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{
+128 ch-data dup length 3 sub get sub}B /ch-yoff{ch-data dup length 2 sub
+get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data
+dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N
+/rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup
+/base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx
+0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff
+setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff
+.1 sub]{ch-image}imagemask restore}B /D{/cc X dup type /stringtype ne{]}
+if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup
+length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{
+cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin
+0 0 moveto /V matrix currentmatrix dup 1 get dup mul exch 0 get dup mul
+add .99 lt{/QV}{/RV}ifelse load def pop pop}N /eop{SI restore showpage
+userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook
+known{start-hook}if pop /VResolution X /Resolution X 1000 div /DVImag X
+/IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for
+65781.76 div /vsize X 65781.76 div /hsize X}N /p{show}N /RMat[1 0 0 -1 0
+0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V
+{}B /RV statusdict begin /product where{pop product dup length 7 ge{0 7
+getinterval dup(Display)eq exch 0 4 getinterval(NeXT)eq or}{pop false}
+ifelse}{false}ifelse end{{gsave TR -.1 .1 TR 1 1 scale rulex ruley false
+RMat{BDot}imagemask grestore}}{{gsave TR -.1 .1 TR rulex ruley scale 1 1
+false RMat{BDot}imagemask grestore}}ifelse B /QV{gsave newpath transform
+round exch round exch itransform moveto rulex 0 rlineto 0 ruley neg
+rlineto rulex neg 0 rlineto fill grestore}B /a{moveto}B /delta 0 N /tail
+{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{S p tail}B /c{-4 M}
+B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{3 M}B /k{
+4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w}B /q{
+p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p
+a}B /bos{/SS save N}B /eos{SS restore}B end
+%%EndProcSet
+%%BeginProcSet: special.pro
+TeXDict begin /SDict 200 dict N SDict begin /@SpecialDefaults{/hs 612 N
+/vs 792 N /ho 0 N /vo 0 N /hsc 1 N /vsc 1 N /ang 0 N /CLIP 0 N /rwiSeen
+false N /rhiSeen false N /letter{}N /note{}N /a4{}N /legal{}N}B
+/@scaleunit 100 N /@hscale{@scaleunit div /hsc X}B /@vscale{@scaleunit
+div /vsc X}B /@hsize{/hs X /CLIP 1 N}B /@vsize{/vs X /CLIP 1 N}B /@clip{
+/CLIP 2 N}B /@hoffset{/ho X}B /@voffset{/vo X}B /@angle{/ang X}B /@rwi{
+10 div /rwi X /rwiSeen true N}B /@rhi{10 div /rhi X /rhiSeen true N}B
+/@llx{/llx X}B /@lly{/lly X}B /@urx{/urx X}B /@ury{/ury X}B /magscale
+true def end /@MacSetUp{userdict /md known{userdict /md get type
+/dicttype eq{userdict begin md length 10 add md maxlength ge{/md md dup
+length 20 add dict copy def}if end md begin /letter{}N /note{}N /legal{}
+N /od{txpose 1 0 mtx defaultmatrix dtransform S atan/pa X newpath
+clippath mark{transform{itransform moveto}}{transform{itransform lineto}
+}{6 -2 roll transform 6 -2 roll transform 6 -2 roll transform{
+itransform 6 2 roll itransform 6 2 roll itransform 6 2 roll curveto}}{{
+closepath}}pathforall newpath counttomark array astore /gc xdf pop ct 39
+0 put 10 fz 0 fs 2 F/|______Courier fnt invertflag{PaintBlack}if}N
+/txpose{pxs pys scale ppr aload pop por{noflips{pop S neg S TR pop 1 -1
+scale}if xflip yflip and{pop S neg S TR 180 rotate 1 -1 scale ppr 3 get
+ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg TR}if xflip yflip
+not and{pop S neg S TR pop 180 rotate ppr 3 get ppr 1 get neg sub neg 0
+TR}if yflip xflip not and{ppr 1 get neg ppr 0 get neg TR}if}{noflips{TR
+pop pop 270 rotate 1 -1 scale}if xflip yflip and{TR pop pop 90 rotate 1
+-1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg
+TR}if xflip yflip not and{TR pop pop 90 rotate ppr 3 get ppr 1 get neg
+sub neg 0 TR}if yflip xflip not and{TR pop pop 270 rotate ppr 2 get ppr
+0 get neg sub neg 0 S TR}if}ifelse scaleby96{ppr aload pop 4 -1 roll add
+2 div 3 1 roll add 2 div 2 copy TR .96 dup scale neg S neg S TR}if}N /cp
+{pop pop showpage pm restore}N end}if}if}N /normalscale{Resolution 72
+div VResolution 72 div neg scale magscale{DVImag dup scale}if 0 setgray}
+N /psfts{S 65781.76 div N}N /startTexFig{/psf$SavedState save N userdict
+maxlength dict begin /magscale false def normalscale currentpoint TR
+/psf$ury psfts /psf$urx psfts /psf$lly psfts /psf$llx psfts /psf$y psfts
+/psf$x psfts currentpoint /psf$cy X /psf$cx X /psf$sx psf$x psf$urx
+psf$llx sub div N /psf$sy psf$y psf$ury psf$lly sub div N psf$sx psf$sy
+scale psf$cx psf$sx div psf$llx sub psf$cy psf$sy div psf$ury sub TR
+/showpage{}N /erasepage{}N /copypage{}N /p 3 def @MacSetUp}N /doclip{
+psf$llx psf$lly psf$urx psf$ury currentpoint 6 2 roll newpath 4 copy 4 2
+roll moveto 6 -1 roll S lineto S lineto S lineto closepath clip newpath
+moveto}N /endTexFig{end psf$SavedState restore}N /@beginspecial{SDict
+begin /SpecialSave save N gsave normalscale currentpoint TR
+@SpecialDefaults count /ocount X /dcount countdictstack N}N /@setspecial
+{CLIP 1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto
+closepath clip}if ho vo TR hsc vsc scale ang rotate rwiSeen{rwi urx llx
+sub div rhiSeen{rhi ury lly sub div}{dup}ifelse scale llx neg lly neg TR
+}{rhiSeen{rhi ury lly sub div dup scale llx neg lly neg TR}if}ifelse
+CLIP 2 eq{newpath llx lly moveto urx lly lineto urx ury lineto llx ury
+lineto closepath clip}if /showpage{}N /erasepage{}N /copypage{}N newpath
+}N /@endspecial{count ocount sub{pop}repeat countdictstack dcount sub{
+end}repeat grestore SpecialSave restore end}N /@defspecial{SDict begin}
+N /@fedspecial{end}B /li{lineto}B /rl{rlineto}B /rc{rcurveto}B /np{
+/SaveX currentpoint /SaveY X N 1 setlinecap newpath}N /st{stroke SaveX
+SaveY moveto}N /fil{fill SaveX SaveY moveto}N /ellipse{/endangle X
+/startangle X /yrad X /xrad X /savematrix matrix currentmatrix N TR xrad
+yrad scale 0 0 1 startangle endangle arc savematrix setmatrix}N end
+%%EndProcSet
+TeXDict begin 39158280 55380996 1000 600 600 (paper.dvi)
+@start /Fa 1 66 df<0000380000000038000000007C000000007C000000007C000000
+00FE00000000FE000000019F000000019F000000039F800000030F800000030F80000006
+07C000000607C000000C07E000000C03E000001C03F000001801F000001801F000003000
+F800003000F800007000FC00007FFFFC00007FFFFC0000C0003E0000C0003E000180003F
+000180001F000380001F800300000F800300000F8007000007C01F80000FE0FFE0007FFE
+FFE0007FFE27237DA22D>65 D E /Fb 1 3 df<6000000006F00000000FF80000001F7C
+0000003E3E0000007C1F000000F80F800001F007C00003E003E00007C001F0000F8000F8
+001F00007C003E00003E007C00001F00F800000F81F0000007C3E0000003E7C0000001FF
+80000000FF000000007E000000007E00000000FF00000001FF80000003E7C0000007C3E0
+00000F81F000001F00F800003E007C00007C003E0000F8001F0001F0000F8003E00007C0
+07C00003E00F800001F01F000000F83E0000007C7C0000003EF80000001FF00000000F60
+00000006282874A841>2 D E /Fc 2 63 df<7FFFFFF8FFFFFFFCFFFFFFFCFFFFFFFCFF
+FFFFFC7FFFFFF81E067C9927>45 D<3000000078000000FE000000FF000000FFC000007F
+E000003FF800000FFC000007FE000001FF800000FFC000003FF000001FF800000FFE0000
+03FF000001FFC000007FE000003FF800000FFC000007FC000007FC00000FFC00003FF800
+007FE00001FFC00003FF00000FFE00001FF800003FF00000FFC00001FF800007FE00000F
+FC00003FF800007FE00000FFC00000FF000000FE00000078000000300000001E287CAA27
+>62 D E /Fd 30 122 df<FFFFF0FFFFF0FFFFF0FFFFF0FFFFF014057F921A>45
+D<FCFCFCFCFCFC0606798515>I<000000300000007800000078000000F8000000F00000
+00F0000001F0000001E0000001E0000003E0000003C0000007C000000780000007800000
+0F8000000F0000000F0000001F0000001E0000001E0000003E0000003C0000003C000000
+7C0000007800000078000000F8000000F0000001F0000001E0000001E0000003E0000003
+C0000003C0000007C0000007800000078000000F8000000F0000000F0000001F0000001E
+0000001E0000003E0000003C0000003C0000007C00000078000000F8000000F0000000F0
+000001F0000001E0000001E0000003E0000003C0000003C0000007C00000078000000780
+00000F8000000F0000000F0000001F0000001E0000003E0000003C0000003C0000007C00
+00007800000078000000F8000000F0000000F0000000600000001D4B7CB726>I<000300
+0000070000001F0000007F000007FF0000FFFF0000FFFF0000FFFF0000FFBF0000F83F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00007FFFFF
+807FFFFF807FFFFF807FFFFF807FFFFF8019327AB126>49 D<003FE00000FFF80003FFFE
+0007FFFF000FFFFF801FC07FC03F001FE03E000FF07E0007F07C0003F8FC0001F8F80001
+F8780001FC380001FC300000FC100000FC000000FC000001FC000001FC000001F8000001
+F8000003F8000003F0000007F0000007E000000FC000001FC000001F8000003F0000007E
+000000FC000001F8000003F0000007E000000F8000001F0000003E0000007C000000F800
+0001F0000003E0000007C000000F8000001F0000003E0000007FFFFFFC7FFFFFFC7FFFFF
+FC7FFFFFFC7FFFFFFC1E327DB126>I<001FE00000FFFC0003FFFF0007FFFF800FFFFFC0
+1FF03FE03FC00FF07F0007F03E0003F81C0003F81C0001F8080001F8000001F8000003F8
+000003F8000003F0000007F000000FE000001FE000003FC00001FF80007FFF00007FFE00
+007FF800007FFE00007FFF0000003FC000000FE0000007F0000003F8000001F8000001FC
+000000FC000000FE000000FE000000FE000000FE000000FE000000FE400000FE600001FC
+700001FCF80003F8FC0007F87F000FF03FE03FE01FFFFFC00FFFFF8003FFFF0000FFFC00
+001FE0001F337DB126>I<00003FC00000003FC00000007FC00000006FC0000000EFC000
+0001EFC0000001EFC0000003CFC0000003CFC0000007CFC000000F8FC000000F8FC00000
+1F0FC000001F0FC000003F0FC000007E0FC000007E0FC00000FC0FC00000FC0FC00001F8
+0FC00003F00FC00003F00FC00007E00FC00007E00FC0000FC00FC0001FC00FC0001F800F
+C0003F000FC0003F000FC0007E000FC000FE000FC000FFFFFFFF80FFFFFFFF80FFFFFFFF
+80FFFFFFFF80FFFFFFFF8000000FC00000000FC00000000FC00000000FC00000000FC000
+00000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000
+000FC00021317EB026>I<000007FC000000007FFF00000001FFFFC0000007FFFFE00000
+1FFFFFF000003FF80FF800007FC001FC0000FF0000FE0001FE00007E0003F8007E7F0007
+F003FFFF000FE007FFFF000FC00FFFFF801FC01FFFFF801F803FC3FF803F807F00FF803F
+00FE007F807F00FC003FC07E01FC003FC07E01F8001FC07E01F8001FC0FC01F8001FC0FC
+03F0000FC0FC03F0000FC0FC03F0000FC0FC03F0000FC0FC03F0000FC0FC03F0000FC0FC
+03F0000FC0FC03F0000FC0FC01F8001F807E01F8001F807E01F8001F807E01FC003F807F
+00FC003F003F00FE007F003F807F00FE001F803FC3FC001FC01FFFF8000FC00FFFF0000F
+E007FFE00007F003FFC00003F8007E000001FE0000000000FF00000000007FC0001FC000
+3FF801FF80001FFFFFFF000007FFFFFC000001FFFFF00000007FFFC000000007FC00002A
+347CB333>64 D<003FC00003FFF8000FFFFC001FFFFE001FFFFF001FC03F801E001FC018
+000FC010000FE0000007E0000007E0000007E0000007E0000007E00003FFE0007FFFE003
+FFFFE00FFFFFE01FFF87E03FE007E07F0007E0FE0007E0FC0007E0FC0007E0FC0007E0FE
+000FE0FE001FE07F807FE07FFFFFE03FFFFFE01FFFF7E00FFFC7E003FC07E01B217DA025
+>97 D<FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC
+000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC
+000000FC000000FC03F800FC3FFE00FCFFFF00FDFFFF80FFFFFFC0FFE07FE0FF800FF0FE
+0007F0FC0003F8FC0003F8FC0001F8FC0001F8FC0000FCFC0000FCFC0000FCFC0000FCFC
+0000FCFC0000FCFC0000FCFC0000FCFC0001FCFC0001F8FC0001F8FC0003F8FE0003F0FF
+0007F0FF801FE0FFE07FC0FFFFFFC0FDFFFF80FCFFFE00FC3FFC00FC07F0001E347AB328
+>I<000FF800007FFF0001FFFFE003FFFFF007FFFFF00FF807F01FC001E01F8000603F00
+00003F0000007E0000007E000000FE000000FC000000FC000000FC000000FC000000FC00
+0000FC000000FC000000FE0000007E0000007E0000003F0000003F0000101F8000701FE0
+01F00FF80FF007FFFFF003FFFFF001FFFFE0007FFF00000FF8001C217DA022>I<000000
+FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000
+FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000
+FC003F80FC00FFF0FC03FFFCFC07FFFFFC0FFFFFFC1FF80FFC1FE003FC3F8001FC3F0000
+FC7F0000FC7E0000FC7E0000FCFE0000FCFC0000FCFC0000FCFC0000FCFC0000FCFC0000
+FCFC0000FCFC0000FCFC0000FC7E0000FC7E0000FC7F0001FC3F0001FC3F8003FC1FC007
+FC1FF81FFC0FFFFFFC07FFFEFC03FFF8FC01FFE0FC003F80FC1E347DB328>I<001FC000
+00FFF80001FFFC0003FFFF0007FFFF800FF03F801FC00FC03F8007C03F0003E07E0003E0
+7E0001E07C0001F0FFFFFFF0FFFFFFF0FFFFFFF0FFFFFFF0FFFFFFF0F8000000F8000000
+FC000000FC0000007C0000007E0000007E0000003F0000001F8000101FE000F00FF807F0
+07FFFFF003FFFFF001FFFFE0007FFF00000FF8001C217DA022>I<0003FF000FFF001FFF
+003FFF007FFF00FE0101F80001F80001F00003F00003F00003F00003F00003F00003F000
+03F00003F00003F00003F000FFFFF0FFFFF0FFFFF0FFFFF0FFFFF003F00003F00003F000
+03F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F000
+03F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F000
+03F00018347FB317>I<001FC01F80007FF1FF8000FFFFFFC001FFFFFFC003FFFFFFC007
+F07F00000FC01F80000F800F80000F800F80001F0007C0001F0007C0001F0007C0001F00
+07C0001F0007C0001F0007C0000F800F80000F800F80000FC01F800007F07F000007FFFE
+00000FFFFC00000FFFF800001F7FF000001F1FC000001F000000001F000000001F000000
+001F800000000FFFFE00000FFFFFE00007FFFFF8000FFFFFFC001FFFFFFE003FFFFFFF00
+7F0001FF007E00007F00FE00003F80FC00001F80FC00001F80FC00001F80FE00003F807E
+00003F007F8000FF003FF007FE001FFFFFFC000FFFFFF80003FFFFE00000FFFF8000001F
+FC000022317EA026>I<FC000000FC000000FC000000FC000000FC000000FC000000FC00
+0000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC00
+0000FC000000FC000000FC000000FC07F800FC3FFE00FC7FFF00FDFFFF80FFFFFFC0FFE0
+7FC0FF801FC0FF000FE0FF0007E0FE0007E0FE0007E0FC0007E0FC0007E0FC0007E0FC00
+07E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC00
+07E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC00
+07E01B347AB328>I<FEFEFEFEFEFEFE0000000000000000000000007E7E7E7E7E7E7E7E
+7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E7E07347BB313>I<FC000000
+FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000
+FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000
+FC000FF0FC001FE0FC003FC0FC007F80FC00FF00FC01FE00FC03FC00FC07F800FC0FF000
+FC1FE000FC3FC000FC7F8000FCFF0000FDFF0000FFFF8000FFFF8000FFFFC000FFE7E000
+FFC7E000FF83F000FF01F800FE01FC00FC00FC00FC007E00FC003F00FC003F80FC001F80
+FC000FC0FC0007E0FC0007E0FC0003F0FC0001F8FC0001FC1E347AB326>107
+D<FCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFC
+FCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFCFC06347AB313>I<FC07F8003FC0FC3FFE01FFF0
+FC7FFF03FFF8FDFFFF8FFFFCFFFFFFDFFFFEFFE07FFF03FEFF801FFC00FEFF000FF8007F
+FF0007F8003FFE0007F0003FFE0007F0003FFC0007E0003FFC0007E0003FFC0007E0003F
+FC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003F
+FC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003F
+FC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003FFC0007E0003F
+FC0007E0003F30217AA03D>I<FC07F800FC3FFE00FC7FFF00FDFFFF80FFFFFFC0FFE07F
+C0FF801FC0FF000FE0FF0007E0FE0007E0FE0007E0FC0007E0FC0007E0FC0007E0FC0007
+E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007
+E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007
+E01B217AA028>I<000FF80000003FFE000000FFFF800003FFFFE00007FFFFF0000FF80F
+F8001FE003FC001F8000FC003F00007E003F00007E007E00003F007E00003F007C00001F
+00FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80
+FE00003F807E00003F007E00003F007F00007F003F8000FE001FC001FC001FE003FC000F
+F80FF80007FFFFF00003FFFFE00000FFFF8000003FFE0000000FF8000021217EA026>I<
+FC03F800FC3FFE00FCFFFF00FDFFFF80FFFFFFC0FFE07FE0FF801FF0FE0007F0FC0007F8
+FC0003F8FC0001F8FC0001F8FC0001FCFC0000FCFC0000FCFC0000FCFC0000FCFC0000FC
+FC0000FCFC0000FCFC0001FCFC0001F8FC0001F8FC0003F8FE0007F0FF000FF0FF801FE0
+FFE07FC0FFFFFFC0FDFFFF80FCFFFE00FC3FFC00FC07F000FC000000FC000000FC000000
+FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000
+FC000000FC000000FC0000001E307AA028>I<F803C0F81FC0F83FC0F8FFC0F9FFC0FBFC
+00FFF000FFC000FF8000FF0000FF0000FE0000FE0000FE0000FC0000FC0000FC0000FC00
+00FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC00
+00FC0000FC0000FC000012217AA01A>114 D<00FFC00007FFF8001FFFFE003FFFFE003F
+FFFE007F007C00FE000C00FC000000FC000000FC000000FC000000FE0000007FC000007F
+FE00003FFFC0001FFFF0000FFFF80003FFFE00007FFE000003FF0000007F8000003F8000
+001F8000001F8040001F8060001F8078003F00FF00FF00FFFFFE00FFFFFC007FFFF8000F
+FFF00001FF800019217EA01D>I<03F00003F00003F00003F00003F00003F00003F00003
+F00003F00003F000FFFFFEFFFFFEFFFFFEFFFFFEFFFFFE03F00003F00003F00003F00003
+F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003
+F00003F00003F00003F00003F00003F80203FC1E01FFFF01FFFF00FFFF007FFC003FC018
+2B7FAA1C>I<FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC00
+07E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC00
+07E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC0007E0FC000FE0FC00
+0FE0FC003FE0FE00FFE0FFFFFFE07FFFFFE07FFFE7E03FFF87E00FF807E01B217AA028>
+I<FC00003F7E00003E7E00007E7F00007E3F0000FC3F0000FC3F8000FC1F8001F81F8001
+F80FC001F00FC003F00FC003F007E007E007E007E003F007C003F00FC003F00FC001F80F
+8001F81F8001F81F8000FC1F0000FC3F00007C3E00007C3E00007E7E00003E7C00003E7C
+00003E7C00001F7800001FF800000FF000000FF000000FF00020217FA023>I<7E00003F
+003F00007F001F8000FE001FC000FC000FE001F80007E003F00003F007E00001F80FE000
+00FC0FC000007E1F8000007F3F0000003F7E0000001FFC0000000FF800000007F8000000
+03F000000003F000000007F80000000FFC0000001FFC0000003F3E0000003E1F0000007C
+1F800000FC0FC00001F807E00003F003F00007E003F00007E001F8000FC000FC001F8000
+7E003F00007F007F00003F80FE00001FC0222180A023>120 D<FE00003F7E00007E7E00
+007E3F00007E3F0000FC3F8000FC1F8001F81F8001F80FC001F80FC003F007E003F007E0
+03E007E007E003F007E003F00FC001F80FC001F80F8000F81F8000FC1F8000FC1F00007C
+1F00007E3E00003E3E00003E3E00001E3C00001F7C00001F7800000F7800000F78000007
+F0000007F0000003E0000003E0000003E0000003C0000007C00000078000000F8000000F
+8000000F0000001F0000201E0000383E00003FFC00003FFC00003FF800003FF000000FC0
+000020307FA023>I E /Fe 18 123 df<0001F800000007FC0000001F0E1800003C033C
+00007803FC0000F001FC0001E001FC0003E001F80007C001F80007C001F8000F8001F800
+1F8001F0001F0001F0003F0001F0003F0001F0003E0003E0007E0003E0007E0003E0007E
+0003E000FC0007C000FC0007C000FC0007C000FC0007C000F8000F8000F8000F81C0F800
+0F81C0F8000F81C0F8001F0380F8001F0380F8003F0380F8007F038078007F07007800DF
+07003C01DF0E001C030F0E000E0E071C0007FC03F80001F001F000222677A42A>97
+D<00007F000003FFC00007C1E0001F0070003C00380078003800F000F801E001F803E003
+F807C003F80FC003F00F8001E01F8000001F0000003F0000003E0000007E0000007E0000
+007E000000FC000000FC000000FC000000FC000000FC000000F8000000F8000000F80000
+00F8000010F8000038780000707C0000F07C0001E03C0003C01E000F000E003E000781F8
+0003FFE00000FF00001D2677A426>99 D<00007E000003FF80000FC1C0001E00E0007C00
+7000F8007001F0007003E0007007C0007007C000700F8000E01F8000E01F0001C03F0007
+803F001F007E01FC007FFFF0007FFE00007E000000FC000000FC000000FC000000FC0000
+00FC000000FC000000FC000000FC0000007C0000107C0000387C0000707C0000F03C0001
+E01E0003C01E000F000F003E000781F80003FFE00000FF00001D2677A426>101
+D<00000007C00000000FF00000001C38000000383C00000078FC000000F0FC000000F1FC
+000001F1FC000001F0F8000001E070000003E000000003E000000003E000000003E00000
+0007C000000007C000000007C000000007C000000007C00000000F800000000F80000000
+0F800000000F80000007FFFF000007FFFF800007FFFF0000001F000000001F000000001F
+000000003E000000003E000000003E000000003E000000003E000000007C000000007C00
+0000007C000000007C000000007C00000000F800000000F800000000F800000000F80000
+0000F800000001F000000001F000000001F000000001F000000001F000000003E0000000
+03E000000003E000000003E000000003E000000007C000000007C000000007C000000007
+C00000000FC00000000F800000000F800000000F800000000F000000001F000000001F00
+0000001F0000001C1E0000003E3E0000007E3C000000FE3C000000FE38000000FC780000
+00787000000070E00000003FC00000000F00000000264C82BA19>I<00000FC00000003F
+E0000000F870C00001E019E00003C01FE00007800FE0000F000FE0001F000FC0003E000F
+C0003E0007C0007C0007C000FC000F8000F8000F8001F8000F8001F8000F8001F0001F00
+03F0001F0003F0001F0003F0001F0007E0003E0007E0003E0007E0003E0007E0003E0007
+E0007C0007C0007C0007C0007C0007C0007C0007C000F80007C001F80003C001F80003C0
+03F80003E007F00001E00FF00000E01DF000007079F000003FE3E000000F83E000000003
+E000000003E000000007C000000007C000000007C000000007C00000000F80001C000F80
+003E001F00007E001F0000FE003E0000FE003C0000FC007800007801F000003C07C00000
+1FFF80000007FC00000023367CA426>I<0007E0000000FFE0000001FFE0000000FFE000
+000007C000000007C000000007C000000007C00000000F800000000F800000000F800000
+000F800000001F000000001F000000001F000000001F000000003E000000003E00000000
+3E000000003E000000007C000000007C0FC000007C3FF000007CF0780000F9C03C0000FB
+801E0000FF001E0000FE001E0001FC001F0001FC001F0001F8001F0001F8001E0003F000
+3E0003F0003E0003E0003E0003E0003E0007C0007C0007C0007C0007C0007C0007C000F8
+000F8000F8000F8000F8000F8000F8000F8001F0001F0001F0001F0003E0381F0003E038
+1F0003E0383E0007C0703E0007C0703E0007C0703E000780E07C000780E07C000781C07C
+000781807C00078380F800038700F80001FE00700000F800253B7AB92A>I<0001C00003
+E00007F00007F00007E00007C00003800000000000000000000000000000000000000000
+0000000000000000000000000000F00003FC00071E000E0E001C0F00181F00381F00381F
+00701F00703E00703E00E03E00E07C00E07C00007C0000F80000F80000F80001F00001F0
+0003E00003E00003E00007C00007C0E007C0E00F80E00F81C00F81C01F01C01F03801F03
+801F03001E07000E0E000F1C0007F80001E000143879B619>I<001F8003FF8007FF8003
+FF80001F00001F00001F00001F00003E00003E00003E00003E00007C00007C00007C0000
+7C0000F80000F80000F80000F80001F00001F00001F00001F00003E00003E00003E00003
+E00007C00007C00007C00007C0000F80000F80000F80000F80001F00001F00001F00001F
+00003E00003E00003E00003E00007C00007C0E007C0E007C0E00F81C00F81C00F81C00F8
+3800F83800F83800F8700078700038E0001FC0000F8000113B79B915>108
+D<03E000FC0007E00007F007FF003FF8000E380F0780783C001C3C3C03C1E01E001C3E70
+03E3801F00383EE001E7000F00383FC001EE000F00703F8001EC000F00703F8001FC000F
+80703F0001F8000F80703F0001F8000F00E07E0003F0001F00E07E0003F0001F00E07C00
+03E0001F00007C0003E0001F0000F80007C0003E0000F80007C0003E0000F80007C0003E
+0000F80007C0007C0001F0000F80007C0001F0000F80007C0001F0000F80007C0001F000
+0F8000F80003E0001F0000F80003E0001F0001F01C03E0001F0001F01C03E0001F0001F0
+1C07C0003E0003E03807C0003E0003E03807C0003E0003E03807C0003E0003C0700F8000
+7C0003C0700F80007C0003C0E00F80007C0003C0C00F80007C0003C1C01F0000F80001C3
+801F0000F80000FF000E00007000007C003E2679A444>I<03E000FC000007F007FF0000
+0E380F0780001C3C3C03C0001C3E7003E000383EE001E000383FC001E000703F8001E000
+703F8001F000703F0001F000703F0001E000E07E0003E000E07E0003E000E07C0003E000
+007C0003E00000F80007C00000F80007C00000F80007C00000F8000F800001F0000F8000
+01F0000F800001F0000F800001F0001F000003E0001F000003E0003E038003E0003E0380
+03E0003E038007C0007C070007C0007C070007C0007C070007C000780E000F8000780E00
+0F8000781C000F80007818000F80007838001F00003870001F00001FE0000E00000F8000
+292679A42F>I<00007F000003FFC00007C1E0001F0070003C00780078003C00F0003E01
+E0003E03E0001E07C0001F0FC0001F0F80001F1F80001F1F00001F3F00003F3E00003F7E
+00003F7E00003F7E00003FFC00007EFC00007EFC00007EFC00007CFC0000FCF80000F8F8
+0001F8F80001F0F80003F0F80003E0780007C07C0007807C000F003C001E001E003C000E
+00F8000783E00003FFC00000FE0000202677A42A>I<000F800F80001FC03FE00038E070
+700070F0C0380070FB803C00E0FB001E00E0FE001E01C0FE001F01C0FC001F01C0F8001F
+01C0F8001F0381F0001F0381F0001F0381F0001F0001F0001F0003E0003F0003E0003F00
+03E0003F0003E0003F0007C0007E0007C0007E0007C0007E0007C0007C000F8000FC000F
+8000FC000F8000F8000F8001F8001F8001F0001F8003E0001F8003E0001F8007C0003F80
+0780003F800F00003FC01E00003EC03C00007C70F800007C3FE000007C1F8000007C0000
+0000F800000000F800000000F800000000F800000001F000000001F000000001F0000000
+01F000000003E000000003E000000003E00000007FFF800000FFFF8000007FFF00000028
+357FA42A>I<03E003F00007F00FFC000E383C0E001C3C700F001C3EE01F80383EC03F80
+383FC03F80703F803F00703F003E00703F001C00703E000000E07E000000E07C000000E0
+7C000000007C00000000F800000000F800000000F800000000F800000001F000000001F0
+00000001F000000001F000000003E000000003E000000003E000000003E000000007C000
+000007C000000007C000000007C00000000F800000000F800000000F800000000F800000
+001F000000001F000000000E00000000212679A423>114 D<0000FE000007FF80000F03
+C0001C00E0003800700070007000F000F000E001F001E003F001E003F001E003E003E001
+C003F0000001F8000001FF000001FFF00000FFFC00007FFE00003FFF00001FFF800001FF
+8000001FC000000FC0000007C0000007C03C0007C07E0007C0FE000780FE000780FC0007
+80F8000F00E0000E0060001E0070003C00380078001E03E0000FFFC00001FE00001C267A
+A422>I<000300000780000F80000F80000F80000F80001F00001F00001F00001F00003E
+00003E00003E00003E00007C00007C00FFFFFCFFFFFEFFFFFC00F80000F80000F80001F0
+0001F00001F00001F00003E00003E00003E00003E00007C00007C00007C00007C0000F80
+000F80000F80000F80001F00001F00381F00381F00703E00703E00703E00E03E00C03E01
+C03E01803E03001E06000E1C0007F80003E000173578B31C>I<00F800000003FC0000C0
+070E0001E00E0F0003E00C0F0003E01C0F0003E0380F0003E0380F0007C0701F0007C070
+1F0007C0701F0007C0E03E000F80E03E000F80E03E000F80007C000F80007C001F0000F8
+001F0000F8001F0000F8001F0001F0003E0001F0003E0001F0003E0001F0003E0003E000
+7C0003E0007C0E03E0007C0E03E0007C0E03E000F81C03E000F81C03E000F81C03E001F8
+1C03E001F83803E003F83801E006F87000F00C787000783838E0003FF01FC0000FC00F80
+272679A42D>I<00F8000E0003FC001F00070E001F800E0F003F800C0F001F801C0F001F
+80380F000F80380F000F80701F000780701F000780701F000780E03E000700E03E000700
+E03E000700007C000700007C000E0000F8000E0000F8000E0000F8000E0001F0001C0001
+F0001C0001F0001C0001F000380003E000380003E000380003E000700003E000700003E0
+00600003E000E00003E000C00003E001C00003E001800001E003000001E007000000F00E
+000000783C0000003FF00000000FC00000212679A426>I<0003C00380000FE00380001F
+F00700003FF80700007FFC0E0000783E1C0000F00FF80000E003F80001C000700001C000
+E000018001C0000000038000000007000000000E000000001C000000001C000000003800
+0000007000000001E000000003C000000007000000000E000000001C000000001C000000
+0038001C000070001C0000E0001C0001C0003800038000380007000070000FF000F0000F
+FC01E0001C1F07C000380FFFC0007807FF80007003FF0000E001FC0000E000F000002126
+7BA422>122 D E /Ff 16 118 df<1C3E7FFFFFFE7C380808778718>46
+D<0000007FC000000003FFF80000000F803E0000003C0007000000F00003800001C00000
+C0000780000060000E00000070001C00000038003800000038007000FC001C00E007FF00
+1C01C01F83800C01803E00C00E03807800E00E0700F000700E0601E0007E0E0E03C0003F
+0E1C07C0003E0E1C0F80003E0E380F80003E0E381F00003E0E381F00007C0E703E00007C
+0E703E00007C0E703E00007C0EE07C0000F81CE07C0000F81CE07C0000F81CE07C0000F8
+1CE07C0001F038E07C0001F038E07C0001F038E07C0003F070E03C0007E070E03C0007E0
+60E01E000FE0E0E01E003BE0C0E00F0073E180600781E1E3807003FF80FE0070007E007C
+003800000000003800000000001C00000000000C0000000780060000001F8003800000FE
+0001C00007F80000F800FFC000003FFFFC00000007FF0000002F3474B33B>64
+D<0003E000000FF860003E1CF000780FF000F007F001E007F003E007E007C003E00F8003
+E00F8003E01F8007C01F0007C03F0007C03F0007C07E000F807E000F807E000F807E000F
+807C001F00FC001F00FC001F06FC001F07FC003E0E7C003E0E7C007E0E7C007E0E3C00FE
+1C3C01FE1C1E039E380F0F1E3807FC0FF001F003C02020789F27>97
+D<0001FC000007FF00001F0780007C01C000F803C001F007C003E00FC007C00FC007C007
+800F8003001F8000001F0000003F0000003F0000007E0000007E0000007E0000007E0000
+007C000000FC000000FC0000007C0000007C0000007C0000407C0000E03C0001C03C0003
+801E000F000E003E000781F80003FFE00000FF00001B20789F23>99
+D<0000000F80000001FFC0000001FF800000000F800000000F800000000F800000001F00
+0000001F000000001F000000001F000000003E000000003E000000003E000000003E0000
+00007C000000007C000000007C000000007C00000000F800000000F8000003E0F800000F
+F8F800003E1DF00000780FF00000F007F00001E007F00003E007E00007C003E0000F8003
+E0000F8003E0001F8007C0001F0007C0003F0007C0003F0007C0007E000F80007E000F80
+007E000F80007E000F80007C001F0000FC001F0000FC001F0600FC001F0700FC003E0E00
+7C003E0E007C007E0E007C007E0E003C00FE1C003C01FE1C001E039E38000F0F1E380007
+FC0FF00001F003C000223478B327>I<0003F800001FFE00007E0F0000F8030001E00380
+03C0038007C003800F8003801F0003803F0007003F000F007E003E007E03F8007FFFE000
+FFFF0000FC000000FC000000FC000000FC000000F8000000F8000000F8000000F8000000
+F8000080780001C07C0003803C0007003C001E001E007C000F03F00007FFC00001FE0000
+1A20779F23>I<0000001F800000007FC0000000F0E0000001E1F0000003E3F0000003C3
+F0000007C3E0000007C1C0000007C00000000F800000000F800000000F800000000F8000
+00001F000000001F000000001F000000001F000000001F000000001F000000003E000000
+0FFFFC00000FFFFC0000003E000000003E000000007C000000007C000000007C00000000
+7C000000007C00000000F800000000F800000000F800000000F800000000F800000001F0
+00000001F000000001F000000001F000000001F000000003E000000003E000000003E000
+000003E000000003E000000007C000000007C000000007C000000007C000000007C00000
+000F800000000F800000000F800000000F800000000F000000001F000000001F00000000
+1F000000001E000000003E000000383E0000007C3C0000007E3C000000FC78000000FC70
+00000078E00000003FC00000000F80000000244382B318>I<00003E000000FF860003E1
+CF000780FF000F007F001E007F003E007E007C003E00F8003E00F8003E01F8007C01F000
+7C03F0007C03F0007C07E000F807E000F807E000F807E000F807C001F00FC001F00FC001
+F00FC001F00FC003E007C003E007C007E007C007E003C00FC003C01FC001E03FC000F0F7
+C0007FCF80001F0F8000000F8000000F8000001F0000001F0000001F0000001F0000003E
+0038003E007C007C007E007800FC00F000FC03E000780FC0003FFF00000FF80000202F7C
+9F23>I<001F00000003FF80000003FF000000001F000000001F000000001F000000003E
+000000003E000000003E000000003E000000007C000000007C000000007C000000007C00
+000000F800000000F800000000F800000000F800000001F000000001F000000001F07F00
+0001F1FFC00003E781E00003EE01F00003FC00F00003F800F00007F000F80007E000F800
+07E000F80007C000F8000FC001F0000F8001F0000F8001F0000F8001F0001F0003E0001F
+0003E0001F0003E0001F0007C0003E0007C0003E0007C0003E000F81803E000F81C07C00
+0F83807C001F03807C001F03807C001F0700F8001E0700F8001E0E00F8001E0C00F8000E
+1800F00007F000600003E00022347AB327>I<0001800003C00007E0000FC00007C00003
+000000000000000000000000000000000000000000000000000000000000000000000000
+0001F00003F800061C000C1E001C1E00381E00383E00703E00703E00707C00E07C00607C
+0000F80000F80000F80001F00001F00003E00003E00003E00007C0C007C0E007C1C00F81
+C00F81C00F83800F03800F07000F0600070C0003F80001F00013327AB118>I<03C007F0
+000FF01FFC001C78781E001C78E01F00387DC00F00387F800F00707F000F80707E000F80
+707E000F80707C000F80E0FC001F0060F8001F0000F8001F0000F8001F0001F0003E0001
+F0003E0001F0003E0001F0007C0003E0007C0003E0007C0003E000F81803E000F81C07C0
+00F83807C001F03807C001F03807C001F0700F8001E0700F8001E0E00F8001E0C00F8000
+E1800F00007F000600003E0026207A9F2B>110 D<0001FC000007FF00001F0780003C01
+C000F801E001F000F003E000F007C000F807C000F80F8000F81F8000F81F0000FC3F0000
+FC3F0000F87E0001F87E0001F87E0001F87E0001F87C0003F0FC0003F0FC0003E07C0007
+E07C0007C07C000F807C000F803C001F003C003E001E007C000E00F0000783E00003FF80
+0000FE00001E20789F27>I<03C00FC007F03FE00C78F0701C79C078387F80FC387F00FC
+707F01F8707E00F8707C0070707C0000E0F8000060F8000000F8000000F8000001F00000
+01F0000001F0000001F0000003E0000003E0000003E0000003E0000007C0000007C00000
+07C0000007C000000F8000000F8000000F8000000F8000000F000000060000001E207A9F
+20>114 D<0007F0001FFC003C1E00700700E00701E00F01C01F03C01F03C00E03C00403
+E00003F00003FF0003FFE001FFF000FFF8007FFC000FFC0000FE00007E00003E38003E7C
+003CFC003CFC003CF80078F00070E000F07001E03C07801FFF0003F80018207A9F1F>I<
+000E00001F00001F00001F00003E00003E00003E00003E00007C00007C00007C00007C00
+00F80000F800FFFFE0FFFFE001F00001F00001F00001F00003E00003E00003E00003E000
+07C00007C00007C00007C0000F80000F80000F80000F80001F00001F00001F00C01F00E0
+3E01C03E01C03E03803E03803E07003E06001E0C001E38000FF00003E000132E79AD19>
+I<01F000060003F8000F00061C001F000C1E001F001C1E001F00381E001F00383E003E00
+703E003E00703E003E00707C003E00E07C007C00607C007C0000F8007C0000F8007C0000
+F800F80001F000F80001F000F80001F000F80003E001F00003E001F00003E001F06003E0
+01F07003E003E0E003C003E0E003C003E0E003C007E0E003E007E1C003E00FE1C001E019
+E38000F071E380007FE0FF00001F803C0024207A9F29>I E /Fg
+1 64 df<00080000000800000008000000080000001C0000001C0000001C0000001C0000
+001C0000C01C01807FBEFF001FFFFC0007FFF00001FFC000007F0000007F000000FF8000
+00F7800001E3C00001C1C0000380E0000300600006003000040010000800080019197D98
+20>63 D E /Fh 29 123 df<1E007F807F80FFC0FFC0FFC0FFC07F807F801E000A0A6F89
+2C>46 D<00000007000000000F800000001F800000001F800000003F800000003F000000
+007F000000007E00000000FE00000000FC00000001FC00000001F800000003F800000003
+F000000003F000000007F000000007E00000000FE00000000FC00000001FC00000001F80
+0000003F800000003F000000007F000000007E00000000FE00000000FC00000000FC0000
+0001FC00000001F800000003F800000003F000000007F000000007E00000000FE0000000
+0FC00000001FC00000001F800000001F800000003F800000003F000000007F000000007E
+00000000FE00000000FC00000001FC00000001F800000003F800000003F000000007F000
+000007E000000007E00000000FE00000000FC00000001FC00000001F800000003F800000
+003F000000007F000000007E00000000FE00000000FC00000000FC00000000F800000000
+780000000021417BB92C>I<0003F80000000FFE0000003FFF8000007FFFC00000FFFFE0
+0001FE0FF00003F803F80007F001FC0007E000FC000FC0007E000FC0007E001F80003F00
+1F80003F003F00001F803F00001F803E00000F807E00000FC07E00000FC07E00000FC07C
+000007C0FC000007E0FC000007E0FC000007E0FC000007E0FC000007E0FC000007E0FC00
+0007E0FC000007E0FC000007E0FC000007E0FC000007E0FC000007E0FE00000FE07E0000
+0FC07E00000FC07E00000FC07E00000FC03F00001F803F00001F803F00001F801F80003F
+001F80003F000FC0007E000FE000FE0007E000FC0007F001FC0003F803F80001FE0FF000
+00FFFFE000007FFFC000003FFF8000000FFE00000003F8000023357CB32C>I<00070000
+000F8000000F8000001F8000001F8000003F8000007F800000FF800001FF800003FF8000
+7FFF8000FFFF8000FFDF8000FF9F80007C1F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F80007FFFFFE07FFFFFE0FFFFFFF07FFFFFE07FFFFFE01C3477B32C>I<000007F000
+00000FF80000001FF80000003FF80000003FF80000007EF8000000FCF8000000FCF80000
+01F8F8000003F0F8000003F0F8000007E0F800000FC0F800000FC0F800001F80F800003F
+00F800003F00F800007E00F80000FC00F80000FC00F80001F800F80003F000F80003F000
+F80007E000F8000FC000F8000FC000F8001F8000F8003F0000F8003F0000F8007E0000F8
+00FC0000F800FFFFFFFFFCFFFFFFFFFEFFFFFFFFFEFFFFFFFFFE7FFFFFFFFC000000F800
+000000F800000000F800000000F800000000F800000000F800000000F800000000F80000
+0000F800000000F80000007FFFF00000FFFFF80000FFFFF80000FFFFF800007FFFF02733
+7EB22C>52 D<7800000000FFFFFFFFC0FFFFFFFFE0FFFFFFFFE0FFFFFFFFE0FFFFFFFFC0
+FC00003F80FC00007F00FC0000FE00780000FC00000001FC00000003F800000003F00000
+0007E00000000FE00000000FC00000001F800000003F800000003F000000007F00000000
+7E00000000FE00000000FC00000001FC00000001F800000001F800000003F000000003F0
+00000007F000000007E000000007E000000007E00000000FC00000000FC00000000FC000
+00000FC00000001F800000001F800000001F800000001F800000001F800000003F800000
+003F000000003F000000003F000000003F000000003F000000003F000000003F00000000
+3F000000003F000000001E000000001E00000023357CB32C>55 D<0003F80000003FFF00
+0000FFFFC00001FFFFE00003FFFFF00007FC07F8000FF001FC001FE000FE003F80007E00
+3F80003F007F00003F007E00001F80FE00001F80FC00001F80FC00000FC0FC00000FC0FC
+00000FC0FC00000FC0FC00000FE0FC00000FE0FC00000FE0FE00000FE07E00000FE07F00
+001FE03F00001FE03F80003FE01FC0007FE00FF001FFE007F807FFE003FFFFFFE001FFFF
+F7E000FFFFC7E0003FFF0FE00007F80FC00000000FC00000000FC00000001FC00000001F
+800000003F800000003F000000007F001F00007E003F8000FE003F8001FC003F8003F800
+3F8007F8003F801FF0001FC07FE0001FFFFFC0000FFFFF000007FFFE000001FFF8000000
+3FC0000023357CB32C>57 D<00007F00000003FFE000000FFFF000003FFFF800007FFFFC
+0000FF80FE0001FE007F0003F8003F0007F0001F8007E00FCF800FC03FFF800F807FFFC0
+1F80FFFFC03F01FFFFC03E03F87FC03E03F03FE07E07E01FE07C0FC00FE07C0F8007E07C
+0F8007E0FC1F8007E0F81F0003E0F81F0003E0F81F0003E0F81F0003E0F81F0003E0F81F
+0003E0F81F0003E0F81F0003E0F81F0003E0FC1F8007E07C0F8007C07C0F8007C07C0FC0
+0FC07E07E01F803E03F03F003E03F87F003F01FFFE001F80FFFC000F807FF8000FC03FF0
+0007E00FC00007F00003C003F80007E001FE001FE000FF807FE0007FFFFFC0003FFFFF80
+000FFFFE000003FFF80000007F800023337CB22C>64 D<00FFF0000007FFFE00000FFFFF
+80001FFFFFE0001FFFFFF0001FC01FF8001FC007F8000F8001FC00070000FC00000000FE
+000000007E000000007E000000007E000000FFFE00000FFFFE00007FFFFE0003FFFFFE00
+0FFFFFFE001FFF807E003FF0007E003FC0007E007F00007E00FE00007E00FC00007E00FC
+00007E00FC00007E00FC00007E00FE00007E007F0000FE007F8003FE003FE00FFE001FFF
+FFFFFC0FFFFFFFFE07FFFFBFFE01FFFE1FFE003FF003FC27247CA32C>97
+D<7FF0000000FFF8000000FFF8000000FFF80000007FF800000001F800000001F8000000
+01F800000001F800000001F800000001F800000001F800000001F800000001F800000001
+F800000001F81FC00001F8FFF80001FBFFFE0001FFFFFF0001FFFFFF8001FFE03FC001FF
+801FE001FF0007F001FE0003F001FC0001F801FC0001FC01F80000FC01F80000FC01F800
+00FE01F800007E01F800007E01F800007E01F800007E01F800007E01F800007E01F80000
+7E01F800007E01F80000FE01FC0000FC01FC0000FC01FC0001F801FE0003F801FE0007F0
+01FF000FF001FF801FE001FFE07FC001FFFFFF8001FFFFFF0001FBFFFE0001F8FFF00000
+F01F800027337FB22C>I<0003FFC000001FFFFC00007FFFFE0001FFFFFE0003FFFFFF00
+07FC007F000FF0007F000FE0003E001FC0001C003F800000003F000000007F000000007E
+000000007E00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00
+000000FC00000000FC000000007E000000007E000000007F000000003F00000F003F8000
+1F801FC0001F800FE0003F800FF0007F0007FC01FF0003FFFFFE0001FFFFFC00007FFFF8
+00001FFFE0000003FE000021247AA32C>I<00000FFE0000001FFF0000001FFF0000001F
+FF0000000FFF000000003F000000003F000000003F000000003F000000003F000000003F
+000000003F000000003F000000003F000000003F000003F03F00001FFE3F0000FFFFBF00
+01FFFFFF0003FFFFFF0007FC0FFF000FF003FF001FE001FF001FC000FF003F80007F003F
+00007F007E00003F007E00003F00FE00003F00FC00003F00FC00003F00FC00003F00FC00
+003F00FC00003F00FC00003F00FC00003F00FC00003F00FE00003F007E00007F007E0000
+7F007F0000FF003F0000FF001F8001FF001FC003FF000FF007FF0007F81FFF0003FFFFFF
+FC01FFFFBFFE00FFFF3FFE003FFC3FFE0007F01FFC27337DB22C>I<0003FE0000001FFF
+C000007FFFF00001FFFFF80003FFFFFC0007FE03FE000FF800FF000FE0003F801FC0001F
+803F80001FC03F00000FC07F00000FC07E00000FE07E000007E0FC000007E0FFFFFFFFE0
+FFFFFFFFE0FFFFFFFFE0FFFFFFFFE0FFFFFFFFC0FC00000000FE000000007E000000007E
+000000007F000000003F000003C03F800007E01FC00007E00FF0000FE007F8003FC007FE
+00FFC001FFFFFF8000FFFFFF00003FFFFC00000FFFF0000001FF800023247CA32C>I<00
+000001F00007F80FFC001FFE3FFE007FFFFFFF01FFFFFFFF03FFFFFE7F03FC0FF83F07F0
+03F81E0FE001FC000FC000FC001FC000FE001F80007E001F80007E001F80007E001F8000
+7E001F80007E001F80007E001FC000FE000FC000FC000FE001FC0007F003F80003FC0FF0
+0007FFFFF00007FFFFE0000FFFFF80000F9FFE00000F87F800000F800000000F80000000
+0F800000000FC000000007E000000007FFFFE00003FFFFFE0007FFFFFF800FFFFFFFE01F
+FFFFFFF03FC0001FF83F000003F87E000000FC7C0000007CFC0000007EF80000003EF800
+00003EF80000003EF80000003EFC0000007E7E000000FC3F800003F83FE0000FF81FFC00
+7FF00FFFFFFFE003FFFFFF8000FFFFFE00003FFFF8000003FF800028387EA42C>103
+D<7FF000000000FFF800000000FFF800000000FFF8000000007FF80000000001F8000000
+0001F80000000001F80000000001F80000000001F80000000001F80000000001F8000000
+0001F80000000001F80000000001F80000000001F80FE0000001F87FFC000001F9FFFE00
+0001FBFFFF000001FFFFFF000001FFF03F800001FFC01F800001FF801FC00001FF000FC0
+0001FE000FC00001FC000FC00001FC000FC00001F8000FC00001F8000FC00001F8000FC0
+0001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC0
+0001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC0
+0001F8000FC00001F8000FC00001F8000FC00001F8000FC0007FFFE0FFFF00FFFFF1FFFF
+80FFFFF1FFFF80FFFFF1FFFF807FFFE0FFFF0029337FB22C>I<00078000000FC000001F
+E000001FE000001FE000001FE000000FC000000780000000000000000000000000000000
+0000000000000000000000000000000000007FFFC0007FFFE000FFFFE0007FFFE0007FFF
+E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007
+E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007
+E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0000007E0007FFF
+FFFCFFFFFFFEFFFFFFFEFFFFFFFE7FFFFFFC1F3479B32C>I<7FE0000000FFF0000000FF
+F0000000FFF00000007FF000000001F000000001F000000001F000000001F000000001F0
+00000001F000000001F000000001F000000001F000000001F000000001F01FFFF001F03F
+FFF801F03FFFF801F03FFFF801F01FFFF001F000FE0001F001FC0001F003F80001F007F0
+0001F00FE00001F01FC00001F03F800001F07F000001F0FE000001F1FC000001F3FC0000
+01F7FE000001FFFF000001FFFF000001FF9F800001FF0FC00001FE07E00001FC07E00001
+F803F00001F001F80001F000FC0001F000FC0001F0007E0001F0003F0001F0001F8001F0
+001F807FFFC0FFFCFFFFE1FFFEFFFFE1FFFEFFFFE1FFFE7FFFC0FFFC27337EB22C>107
+D<7FFFE00000FFFFF00000FFFFF00000FFFFF000007FFFF000000003F000000003F00000
+0003F000000003F000000003F000000003F000000003F000000003F000000003F0000000
+03F000000003F000000003F000000003F000000003F000000003F000000003F000000003
+F000000003F000000003F000000003F000000003F000000003F000000003F000000003F0
+00000003F000000003F000000003F000000003F000000003F000000003F000000003F000
+000003F000000003F000000003F000000003F000000003F000000003F000000003F00000
+0003F000000003F000000003F000007FFFFFFF80FFFFFFFFC0FFFFFFFFC0FFFFFFFFC07F
+FFFFFF8022337BB22C>I<7F81F003E0007FCFFC1FF800FFDFFE3FFC007FFFFEFFFC007F
+FFFFFFFE0007FE1FFC3E0007FC1FF83F0007F00FE01F0007F00FE01F0007E00FC01F0007
+E00FC01F0007E00FC01F0007C00F801F0007C00F801F0007C00F801F0007C00F801F0007
+C00F801F0007C00F801F0007C00F801F0007C00F801F0007C00F801F0007C00F801F0007
+C00F801F0007C00F801F0007C00F801F0007C00F801F0007C00F801F0007C00F801F0007
+C00F801F0007C00F801F0007C00F801F007FFC3FF87FF07FFC7FF8FFF0FFFE7FFCFFF87F
+FC7FF8FFF07FFC3FF87FF02D2481A32C>I<7FF00FE00000FFF87FFC0000FFF9FFFE0000
+FFFBFFFF00007FFFFFFF000001FFF03F800001FFC01F800001FF801FC00001FF000FC000
+01FE000FC00001FC000FC00001FC000FC00001F8000FC00001F8000FC00001F8000FC000
+01F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC000
+01F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC000
+01F8000FC00001F8000FC00001F8000FC00001F8000FC0007FFFE0FFFF00FFFFF1FFFF80
+FFFFF1FFFF80FFFFF1FFFF807FFFE0FFFF0029247FA32C>I<0007FC0000001FFF000000
+7FFFC00001FFFFF00003FFFFF80007FC07FC000FF001FE001FE000FF001F80003F003F80
+003F803F00001F807E00000FC07E00000FC07E00000FC0FC000007E0FC000007E0FC0000
+07E0FC000007E0FC000007E0FC000007E0FC000007E0FE00000FE07E00000FC07E00000F
+C07F00001FC03F00001F803F80003F801FC0007F001FE000FF000FF001FE0007FC07FC00
+03FFFFF80001FFFFF000007FFFC000001FFF00000007FC000023247CA32C>I<7FF01FC0
+00FFF8FFF800FFFBFFFE00FFFFFFFF007FFFFFFF8001FFE03FC001FF801FE001FF0007F0
+01FE0003F001FC0001F801FC0001FC01F80000FC01F80000FC01F80000FE01F800007E01
+F800007E01F800007E01F800007E01F800007E01F800007E01F800007E01F800007E01F8
+0000FE01FC0000FC01FC0000FC01FC0001F801FE0003F801FE0007F001FF000FF001FF80
+1FE001FFE07FC001FFFFFF8001FFFFFF0001FBFFFE0001F8FFF00001F81F800001F80000
+0001F800000001F800000001F800000001F800000001F800000001F800000001F8000000
+01F800000001F800000001F800000001F800000001F80000007FFFE00000FFFFF00000FF
+FFF00000FFFFF000007FFFE0000027367FA32C>I<7FFE003FC0FFFF01FFF0FFFF07FFF8
+FFFF1FFFFC7FFF3FFFFC003F7FC1FC003FFF01FC003FFC00F8003FF80070003FF0000000
+3FE00000003FC00000003FC00000003F800000003F800000003F800000003F000000003F
+000000003F000000003F000000003F000000003F000000003F000000003F000000003F00
+0000003F000000003F000000003F000000003F000000003F000000003F0000007FFFFFE0
+00FFFFFFF000FFFFFFF000FFFFFFF0007FFFFFE00026247EA32C>114
+D<003FF87001FFFFF80FFFFFF81FFFFFF83FFFFFF87FC00FF87E0003F8FC0001F8F80001
+F8F80001F8F80001F8FC0000F07F0000007FE000003FFF80001FFFFC000FFFFF8001FFFF
+E0003FFFF80001FFFC000007FC000000FE7800007FFC00003FFC00001FFE00001FFE0000
+1FFF00003FFF80003EFFC000FEFFF003FCFFFFFFFCFFFFFFF8FFFFFFE0F8FFFF80701FFC
+0020247AA32C>I<001E000000003F000000003F000000003F000000003F000000003F00
+0000003F000000003F000000003F000000003F0000007FFFFFFF00FFFFFFFF80FFFFFFFF
+80FFFFFFFF807FFFFFFF00003F000000003F000000003F000000003F000000003F000000
+003F000000003F000000003F000000003F000000003F000000003F000000003F00000000
+3F000000003F000000003F000000003F000000003F000000003F0003C0003F0007E0003F
+0007E0003F0007E0003F0007E0003F0007E0003F800FE0001F801FC0001FE03FC0000FFF
+FF800007FFFF000003FFFE000001FFF80000003FC000232E7EAD2C>I<7FF003FF8000FF
+F807FFC000FFF807FFC000FFF807FFC0007FF803FFC00001F8000FC00001F8000FC00001
+F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001
+F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001
+F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001F8000FC00001
+F8000FC00001F8001FC00001F8001FC00001F8003FC00001FC007FC00000FE01FFC00000
+FFFFFFFF00007FFFFFFF80003FFFFFFF80001FFFCFFF800003FE07FF0029247FA32C>I<
+3FFF03FFF07FFF87FFF87FFF87FFF87FFF87FFF83FFF03FFF000FC007E0000FC00FC0000
+7E01F800003F01F000001F83F000001F87E000000FCFC0000007EF80000003FF80000001
+FF00000001FE00000000FC000000007C00000000FE00000001FE00000001FF00000003EF
+80000007CFC000000FC7C000000F83E000001F01F000003F01F800007E00F800007C007C
+0000F8007E0001F8003F007FFF01FFFC7FFF83FFFCFFFF83FFFE7FFF83FFFC7FFF01FFFC
+27247EA32C>120 D<7FFF01FFFCFFFF01FFFEFFFF83FFFEFFFF01FFFE7FFF01FFFC03E0
+000F8001F0000F8001F0001F8001F8001F0000F8001F0000F8003F0000FC003E00007C00
+3E00007E007E00003E007C00003E007C00003F00FC00001F00F800001F00F800000F81F8
+00000F81F000000F81F0000007C1F0000007C3E0000007C3E0000003E3E0000003E3C000
+0001E7C0000001F7C0000001F780000000FF80000000FF80000000FF000000007F000000
+007F000000003E000000003E000000007E000000007C000000007C00000000FC00000000
+F800000000F800000001F800001C01F000003E03F000007F07E000007F0FE000007F1FC0
+00007FFF8000003FFF0000003FFE0000001FFC00000007E000000027367EA32C>I<3FFF
+FFFFE07FFFFFFFF07FFFFFFFF07FFFFFFFF07FFFFFFFF07E00001FE07E00003FC07E0000
+7F807E0000FF007E0001FE003C0003FC00000007F80000000FF00000001FE00000003FC0
+0000007F80000000FF00000001FC00000003F80000000FF00000001FE00000003FC00000
+007F80000000FF00000001FE0001E003FC0003F007F80003F00FF00003F01FE00003F03F
+C00003F07F800003F0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF07FFFFFFFE02424
+7DA32C>I E /Fi 55 123 df<000003FF800000003FFFE0000001FFFFF8000007FF00FC
+00000FF8007E00003FE000FE00007FC001FF00007F8003FF0000FF8003FF0001FF0003FF
+0001FF0003FF0001FF0003FF0001FF0003FF0001FF0001FE0001FF0000FC0001FF000000
+0001FF0000000001FF0000000001FF0000000001FF0000000001FF003FFF80FFFFFFFFFF
+80FFFFFFFFFF80FFFFFFFFFF80FFFFFFFFFF8001FF0000FF8001FF0000FF8001FF0000FF
+8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF
+8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF
+8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF
+8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF
+8001FF0000FF8001FF0000FF807FFFFC3FFFFE7FFFFC3FFFFE7FFFFC3FFFFE7FFFFC3FFF
+FE2F3A7EB935>12 D<000003FF8F8000007FFFFF800001FFFFFF800007FE00FF80001FF8
+01FF80003FE003FF80007FC003FF80007F8003FF8000FF8003FF8001FF0001FF8001FF00
+00FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF00
+00FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF80FFFFFFFFFF80FFFFFF
+FFFF80FFFFFFFFFF80FFFFFFFFFF8001FF0000FF8001FF0000FF8001FF0000FF8001FF00
+00FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF00
+00FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF00
+00FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF00
+00FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF0000FF8001FF00
+00FF8001FF0000FF807FFFFC3FFFFE7FFFFC3FFFFE7FFFFC3FFFFE7FFFFC3FFFFE2F3A7E
+B935>I<000003FF8000FFF0000000003FFFF00FFFFC00000001FFFFF87FFFFE00000007
+FF00FDFFC03F8000000FF8003FFE000FC000003FE000FFF8001FC000007FC001FFF0003F
+E000007F8001FFE0007FE00000FF8003FFE0007FE00001FF0003FFC0007FE00001FF0003
+FFC0007FE00001FF0003FFC0007FE00001FF0001FFC0007FE00001FF0000FFC0003FC000
+01FF00007FC0001F800001FF00007FC00000000001FF00007FC00000000001FF00007FC0
+0000000001FF00007FC00000000001FF00007FC00000000001FF00007FC007FFF000FFFF
+FFFFFFFFFFFFF000FFFFFFFFFFFFFFFFF000FFFFFFFFFFFFFFFFF000FFFFFFFFFFFFFFFF
+F00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF0000
+7FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF000
+01FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0
+001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF
+00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001F
+F00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF0000
+7FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF000
+01FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0001FF00001FF00007FC0
+001FF0007FFFFC1FFFFF07FFFFC07FFFFC1FFFFF07FFFFC07FFFFC1FFFFF07FFFFC07FFF
+FC1FFFFF07FFFFC04A3A7EB950>I<FFFFFF80FFFFFF80FFFFFF80FFFFFF80FFFFFF80FF
+FFFF80FFFFFF80FFFFFF8019087F9520>45 D<0F801FC03FE07FF0FFF8FFF8FFF8FFF8FF
+F87FF03FE01FC00F800D0D798C1B>I<00003C000000007C00000001FC00000007FC0000
+007FFC0000FFFFFC0000FFFFFC0000FFFFFC0000FF8FFC0000000FFC0000000FFC000000
+0FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000F
+FC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC
+0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC00
+00000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000
+000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC000000
+0FFC0000000FFC0000000FFC0000000FFC00007FFFFFFF807FFFFFFF807FFFFFFF807FFF
+FFFF80213779B630>49 D<000FFC0000007FFFC00001FFFFF00003FFFFFC000FE03FFE00
+1F8007FF003E0003FF803F0001FFC07FC001FFE07FE000FFE0FFE000FFF0FFF0007FF0FF
+F0007FF8FFF0007FF8FFF0007FF87FE0007FF87FE0007FF83FC0007FF80F00007FF80000
+007FF80000007FF0000000FFF0000000FFE0000000FFE0000001FFC0000001FF80000003
+FF00000003FE00000007FC0000000FF80000001FF00000001FC00000003F800000007F00
+000000FC00000001F800000003F000000007E00078000FC00078000F000078001E000078
+003C0000F000780000F000F00000F001C00001F003FFFFFFF007FFFFFFF00FFFFFFFF01F
+FFFFFFF03FFFFFFFF07FFFFFFFE0FFFFFFFFE0FFFFFFFFE0FFFFFFFFE0FFFFFFFFE02537
+7BB630>I<0003FF0000001FFFF000007FFFFC0000FC07FE0001F001FF8003C001FFC007
+C000FFC00FF000FFE00FF800FFE01FFC00FFF01FFC00FFF01FFC00FFF01FFC00FFF01FFC
+00FFF00FFC00FFF00FF800FFE007F000FFE001E001FFC0000001FFC0000001FF80000003
+FF00000003FE00000007F80000003FF000000FFFC000000FFF0000000FFFF000000007FE
+00000001FF00000000FFC00000007FE00000007FF00000007FF80000003FF80000003FFC
+0000003FFC0000003FFE1FC0003FFE3FE0003FFE7FF0003FFE7FF0003FFEFFF8003FFEFF
+F8003FFEFFF8003FFCFFF8003FFCFFF8003FFC7FF0007FF87FE0007FF83FC0007FF03F00
+00FFE01FC001FFC00FF807FF8003FFFFFF0001FFFFFC00007FFFF0000007FF000027387C
+B630>I<0000000F80000000001F80000000001F80000000003F80000000007F80000000
+00FF8000000001FF8000000001FF8000000003FF8000000007FF800000000FFF80000000
+0FFF800000001EFF800000003CFF8000000078FF80000000F8FF80000000F0FF80000001
+E0FF80000003C0FF8000000780FF8000000F80FF8000000F00FF8000001E00FF8000003C
+00FF8000007800FF800000F800FF800000F000FF800001E000FF800003C000FF800007C0
+00FF80000F8000FF80000F0000FF80001E0000FF80003C0000FF80007C0000FF8000F800
+00FF8000FFFFFFFFFF80FFFFFFFFFF80FFFFFFFFFF80FFFFFFFFFF80000001FF80000000
+01FF8000000001FF8000000001FF8000000001FF8000000001FF8000000001FF80000000
+01FF8000000001FF8000000001FF80000003FFFFFF800003FFFFFF800003FFFFFF800003
+FFFFFF8029367DB530>I<0C000000C00F800007C00FF8007FC00FFFFFFF800FFFFFFF00
+0FFFFFFE000FFFFFFC000FFFFFF8000FFFFFF0000FFFFFE0000FFFFF80000FFFFE00000F
+FFF800000F000000000F000000000F000000000F000000000F000000000F000000000F00
+0000000F000000000F03FE00000F1FFFE0000F7FFFF8000FFC07FC000FE001FE000F8000
+FF000F0000FF800E0000FFC00000007FE00000007FE00000007FF00000007FF00000007F
+F00000007FF80000007FF81F00007FF83F80007FF87FC0007FF8FFE0007FF8FFE0007FF8
+FFE0007FF8FFE0007FF0FFC0007FF0FFC0007FF07F80007FE07E0000FFE03C0000FFC03E
+0001FF801F0001FF000F8003FE0007F01FFC0003FFFFF80001FFFFE000007FFF8000000F
+F8000025387BB630>I<00000FF8000000FFFF000003FFFF80000FF80FC0001FE001E000
+7F8003F000FF0007F001FE000FF803FE001FF807FC001FF807FC001FF80FF8001FF80FF8
+000FF01FF80007E01FF80003C03FF80000003FF00000007FF00000007FF00000007FF008
+00007FF07FF000FFF1FFFC00FFF3FFFE00FFF300FF80FFF6007FC0FFFE003FE0FFFC003F
+F0FFFC001FF0FFF8001FF8FFF8001FF8FFF8001FFCFFF0001FFCFFF0001FFEFFF0001FFE
+FFF0001FFEFFF0001FFE7FF0001FFE7FF0001FFE7FF0001FFE7FF0001FFE7FF0001FFE3F
+F0001FFE3FF0001FFE3FF0001FFC1FF0001FFC1FF0001FF80FF8001FF80FF8001FF007F8
+003FF003FC003FE001FE007FC000FF81FF80007FFFFE00003FFFFC00000FFFF0000001FF
+800027387CB630>I<3C00000000003E00000000003FE0000000003FFFFFFFFF803FFFFF
+FFFF803FFFFFFFFF803FFFFFFFFF803FFFFFFFFF007FFFFFFFFE007FFFFFFFFC007FFFFF
+FFF8007FFFFFFFF0007FFFFFFFE0007C000003E00078000007C0007800000F8000780000
+1F0000F000001E0000F000003C0000F000007C0000F00000F80000000001F00000000003
+E00000000003C00000000007C0000000000F80000000000F00000000001F00000000003F
+00000000003E00000000007E00000000007E0000000000FE0000000000FC0000000001FC
+0000000001FC0000000003FC0000000003FC0000000003FC0000000007F80000000007F8
+0000000007F8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF8
+000000001FF8000000001FF8000000001FF8000000001FF8000000001FF8000000001FF8
+000000001FF8000000001FF8000000000FF0000000000FF00000000003C0000000293A7B
+B830>I<0001FF8000000FFFF000003FFFFC00007E01FF0001F0003F8001C0001FC003C0
+000FC007800007E00F800007E00F800003F00F800003F01F800003F01FC00003F01FC000
+03F01FF00003F01FF80003F01FFE0007E01FFF8007E01FFFE00FC00FFFF00F800FFFFC1F
+0007FFFF7E0007FFFFFC0003FFFFF00001FFFFF80000FFFFFE00007FFFFF00001FFFFF80
+007FFFFFC001FFFFFFE003F8FFFFF007E03FFFF80FC01FFFF81F8007FFFC3F8001FFFC7F
+00007FFC7F00003FFE7F00000FFEFE000003FEFE000001FEFE000001FEFE000000FEFE00
+0000FEFE000000FCFE000000FC7F000000FC7F000000F87F800001F83F800001F01FC000
+03E00FF0000FC007FE007F8003FFFFFF0000FFFFFC00003FFFF0000003FF800027387CB6
+30>I<0003FF0000001FFFE000007FFFF80000FF01FC0003FE00FF0007FC007F800FF800
+3FC01FF8003FC01FF0003FE03FF0001FF07FF0001FF07FF0001FF87FF0001FF8FFF0001F
+F8FFF0001FFCFFF0001FFCFFF0001FFCFFF0001FFCFFF0001FFCFFF0001FFEFFF0001FFE
+FFF0001FFEFFF0001FFE7FF0001FFE7FF0001FFE7FF0003FFE3FF0003FFE3FF0003FFE1F
+F0007FFE0FF8007FFE0FF800FFFE07FC00DFFE01FE019FFE00FFFF9FFE007FFF1FFC001F
+FC1FFC0000201FFC0000001FFC0000001FFC0000001FF80000003FF80780003FF80FC000
+3FF01FE0003FF03FF0003FE03FF0007FC03FF0007FC03FF000FF803FE000FF001FC001FE
+001F8007FC000FE01FF80007FFFFF00003FFFFC00000FFFF0000001FF0000027387CB630
+>I<00000003E00000000000000003E00000000000000007F00000000000000007F00000
+00000000000FF8000000000000000FF8000000000000000FF8000000000000001FFC0000
+00000000001FFC000000000000003FFE000000000000003FFE000000000000003FFE0000
+00000000007FFF000000000000007FFF00000000000000FFFF80000000000000F7FF8000
+0000000001F7FFC0000000000001E7FFC0000000000001E3FFC0000000000003E3FFE000
+0000000003C1FFE0000000000007C1FFF000000000000780FFF000000000000780FFF000
+000000000F00FFF800000000000F007FF800000000001F007FFC00000000001E003FFC00
+000000003E003FFE00000000003C003FFE00000000003C001FFE00000000007C001FFF00
+0000000078000FFF0000000000F8000FFF8000000000F00007FF8000000000F00007FF80
+00000001E00007FFC000000001FFFFFFFFC000000003FFFFFFFFE000000003FFFFFFFFE0
+00000007FFFFFFFFF000000007800001FFF000000007800000FFF00000000F800000FFF8
+0000000F0000007FF80000001F0000007FFC0000001E0000003FFC0000001E0000003FFC
+0000003C0000003FFE0000003C0000001FFE0000007C0000001FFF000000780000000FFF
+000000FC0000000FFF8000FFFFF00007FFFFFF80FFFFF00007FFFFFF80FFFFF00007FFFF
+FF80FFFFF00007FFFFFF8041397DB848>65 D<FFFFFFFFFFC00000FFFFFFFFFFFC0000FF
+FFFFFFFFFF0000FFFFFFFFFFFFC000007FF00003FFE000007FF00000FFF000007FF00000
+7FF800007FF000003FFC00007FF000001FFC00007FF000001FFE00007FF000001FFE0000
+7FF000000FFF00007FF000000FFF00007FF000000FFF00007FF000000FFF00007FF00000
+0FFF00007FF000000FFF00007FF000000FFF00007FF000001FFE00007FF000001FFE0000
+7FF000001FFC00007FF000003FFC00007FF000007FF800007FF00000FFF000007FF00001
+FFC000007FF0000FFF8000007FFFFFFFFC0000007FFFFFFFFC0000007FFFFFFFFF800000
+7FF00000FFF000007FF000003FF800007FF000001FFC00007FF000000FFE00007FF00000
+07FF00007FF0000007FF80007FF0000003FFC0007FF0000003FFC0007FF0000003FFC000
+7FF0000003FFE0007FF0000003FFE0007FF0000003FFE0007FF0000003FFE0007FF00000
+03FFE0007FF0000003FFE0007FF0000003FFE0007FF0000003FFC0007FF0000003FFC000
+7FF0000007FFC0007FF000000FFF80007FF000000FFF00007FF000001FFF00007FF00000
+7FFE00007FF00001FFFC00FFFFFFFFFFFFF000FFFFFFFFFFFFC000FFFFFFFFFFFF0000FF
+FFFFFFFFF000003B397DB844>I<0000001FFE0000C0000003FFFFC001C000001FFFFFF0
+07C000007FFFFFFC0FC00001FFFC00FF1FC00007FFC0001FBFC0001FFF000007FFC0003F
+FC000001FFC0007FF0000000FFC000FFE00000007FC001FFC00000003FC003FF80000000
+3FC007FF800000001FC007FF000000000FC00FFF000000000FC00FFE0000000007C01FFE
+0000000007C01FFC0000000007C03FFC0000000003C03FFC0000000003C07FFC00000000
+03C07FFC0000000003C07FF80000000000007FF8000000000000FFF8000000000000FFF8
+000000000000FFF8000000000000FFF8000000000000FFF8000000000000FFF800000000
+0000FFF8000000000000FFF8000000000000FFF8000000000000FFF8000000000000FFF8
+0000000000007FF80000000000007FF80000000000007FFC0000000000007FFC00000000
+03C03FFC0000000003C03FFC0000000003C01FFC0000000003C01FFE0000000003C00FFE
+0000000007800FFF00000000078007FF00000000078007FF800000000F0003FF80000000
+1F0001FFC00000001E0000FFE00000003C00007FF00000007800003FFC000000F000001F
+FF000003E0000007FFC0000FC0000001FFFC007F800000007FFFFFFE000000001FFFFFF8
+0000000003FFFFE000000000001FFE0000003A3B7BB945>I<FFFFFFFFFF800000FFFFFF
+FFFFF80000FFFFFFFFFFFF0000FFFFFFFFFFFFC000007FF80007FFF000007FF800007FF8
+00007FF800001FFE00007FF800000FFF00007FF8000003FF80007FF8000001FFC0007FF8
+000001FFC0007FF8000000FFE0007FF80000007FF0007FF80000007FF0007FF80000003F
+F8007FF80000003FF8007FF80000003FFC007FF80000001FFC007FF80000001FFC007FF8
+0000001FFE007FF80000001FFE007FF80000001FFE007FF80000001FFE007FF80000001F
+FF007FF80000001FFF007FF80000001FFF007FF80000001FFF007FF80000001FFF007FF8
+0000001FFF007FF80000001FFF007FF80000001FFF007FF80000001FFF007FF80000001F
+FF007FF80000001FFF007FF80000001FFF007FF80000001FFE007FF80000001FFE007FF8
+0000001FFE007FF80000001FFE007FF80000001FFC007FF80000003FFC007FF80000003F
+FC007FF80000003FF8007FF80000007FF8007FF80000007FF0007FF8000000FFE0007FF8
+000000FFE0007FF8000001FFC0007FF8000003FF80007FF8000007FF00007FF800001FFE
+00007FF800007FFC00007FF80007FFF000FFFFFFFFFFFFC000FFFFFFFFFFFF0000FFFFFF
+FFFFFC0000FFFFFFFFFF80000040397DB849>I<FFFFFFFFFFFFC0FFFFFFFFFFFFC0FFFF
+FFFFFFFFC0FFFFFFFFFFFFC0007FF80003FFC0007FF800007FE0007FF800001FE0007FF8
+00000FE0007FF8000007E0007FF8000007E0007FF8000003E0007FF8000003E0007FF800
+0001E0007FF8000001E0007FF8000001E0007FF8000001F0007FF8007800F0007FF80078
+00F0007FF8007800F0007FF8007800F0007FF800780000007FF800780000007FF800F800
+00007FF800F80000007FF801F80000007FF807F80000007FFFFFF80000007FFFFFF80000
+007FFFFFF80000007FFFFFF80000007FF807F80000007FF801F80000007FF800F8000000
+7FF800F80000007FF800780000007FF800780000007FF800780000007FF800780000007F
+F800780000007FF800780000007FF800000000007FF800000000007FF800000000007FF8
+00000000007FF800000000007FF800000000007FF800000000007FF800000000007FF800
+000000007FF800000000007FF800000000007FF800000000007FF800000000FFFFFFFF00
+0000FFFFFFFF000000FFFFFFFF000000FFFFFFFF00000034397DB83C>70
+D<FFFFFFFC03FFFFFFF0FFFFFFFC03FFFFFFF0FFFFFFFC03FFFFFFF0FFFFFFFC03FFFFFF
+F0007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FFFFFFFFFFFE000007FFFFFFFFFFFE000007FFFFFFFFFFFE0
+00007FFFFFFFFFFFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000007FF8000001FFE000007FF8000001FFE000007FF8000001FFE0
+00007FF8000001FFE000FFFFFFFC03FFFFFFF0FFFFFFFC03FFFFFFF0FFFFFFFC03FFFFFF
+F0FFFFFFFC03FFFFFFF044397DB84B>72 D<FFFFFFFCFFFFFFFCFFFFFFFCFFFFFFFC007F
+F800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007F
+F800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007F
+F800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007F
+F800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007F
+F800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007FF800007F
+F800007FF800007FF800007FF800FFFFFFFCFFFFFFFCFFFFFFFCFFFFFFFC1E397DB824>
+I<FFFFFFFF000000FFFFFFFF000000FFFFFFFF000000FFFFFFFF000000007FF800000000
+007FF800000000007FF800000000007FF800000000007FF800000000007FF80000000000
+7FF800000000007FF800000000007FF800000000007FF800000000007FF800000000007F
+F800000000007FF800000000007FF800000000007FF800000000007FF800000000007FF8
+00000000007FF800000000007FF800000000007FF800000000007FF800000000007FF800
+000000007FF800000000007FF800000000007FF800000000007FF800000000007FF80000
+0000007FF800000000007FF800000000007FF800000000007FF800000780007FF8000007
+80007FF800000780007FF800000780007FF800000780007FF800000F80007FF800000F00
+007FF800000F00007FF800000F00007FF800001F00007FF800001F00007FF800003F0000
+7FF800003F00007FF800007F00007FF80000FF00007FF80001FF00007FF80003FF00007F
+F8000FFE00007FF8007FFE00FFFFFFFFFFFE00FFFFFFFFFFFE00FFFFFFFFFFFE00FFFFFF
+FFFFFE0031397DB839>76 D<FFFFF80000000003FFFFF0FFFFFC0000000007FFFFF0FFFF
+FC0000000007FFFFF0FFFFFE000000000FFFFFF0007FFE000000000FFFE000007FFE0000
+00000FFFE000007BFF000000001EFFE000007BFF000000001EFFE0000079FF800000003C
+FFE0000079FF800000003CFFE0000078FFC000000078FFE0000078FFC000000078FFE000
+00787FE0000000F0FFE00000787FE0000000F0FFE00000787FE0000000F0FFE00000783F
+F0000001E0FFE00000783FF0000001E0FFE00000781FF8000003C0FFE00000781FF80000
+03C0FFE00000780FFC00000780FFE00000780FFC00000780FFE000007807FE00000F00FF
+E000007807FE00000F00FFE000007803FF00001E00FFE000007803FF00001E00FFE00000
+7803FF00001E00FFE000007801FF80003C00FFE000007801FF80003C00FFE000007800FF
+C0007800FFE000007800FFC0007800FFE0000078007FE000F000FFE0000078007FE000F0
+00FFE0000078003FF001E000FFE0000078003FF001E000FFE0000078003FF001E000FFE0
+000078001FF803C000FFE0000078001FF803C000FFE0000078000FFC078000FFE0000078
+000FFC078000FFE00000780007FE0F0000FFE00000780007FE0F0000FFE00000780003FF
+1E0000FFE00000780003FF1E0000FFE00000780003FF1E0000FFE00000780001FFBC0000
+FFE00000780001FFBC0000FFE00000780000FFF80000FFE00000780000FFF80000FFE000
+007800007FF00000FFE000007800007FF00000FFE000007800003FE00000FFE000007800
+003FE00000FFE00000FC00003FE00000FFE000FFFFFC001FC001FFFFFFF0FFFFFC001FC0
+01FFFFFFF0FFFFFC000F8001FFFFFFF0FFFFFC00070001FFFFFFF054397DB85B>I<FFFF
+FC000003FFFFF0FFFFFC000003FFFFF0FFFFFE000003FFFFF0FFFFFF000003FFFFF0007F
+FF80000003F000007FFFC0000001E000007FFFE0000001E000007BFFE0000001E0000079
+FFF0000001E0000079FFF8000001E0000078FFFC000001E00000787FFE000001E0000078
+3FFF000001E00000781FFF800001E00000780FFF800001E000007807FFC00001E0000078
+07FFE00001E000007803FFF00001E000007801FFF80001E000007800FFFC0001E0000078
+007FFE0001E0000078003FFE0001E0000078001FFF0001E0000078001FFF8001E0000078
+000FFFC001E00000780007FFE001E00000780003FFF001E00000780001FFF801E0000078
+0000FFF801E00000780000FFFC01E000007800007FFE01E000007800003FFF01E0000078
+00001FFF81E000007800000FFFC1E0000078000007FFC1E0000078000003FFE1E0000078
+000003FFF1E0000078000001FFF9E0000078000000FFFDE00000780000007FFFE0000078
+0000003FFFE00000780000001FFFE00000780000000FFFE00000780000000FFFE0000078
+00000007FFE000007800000003FFE000007800000001FFE000007800000000FFE0000078
+000000007FE0000078000000003FE0000078000000003FE0000078000000001FE00000FC
+000000000FE000FFFFFC00000007E000FFFFFC00000003E000FFFFFC00000001E000FFFF
+FC00000001E00044397DB84B>I<000000FFF800000000000FFFFF80000000007FFFFFF0
+00000001FFC01FFC00000007FF0007FF0000001FFC0001FFC000003FF000007FE000007F
+E000003FF00000FFC000001FF80001FF8000000FFC0003FF8000000FFE0007FF00000007
+FF0007FF00000007FF000FFE00000003FF800FFE00000003FF801FFC00000001FFC01FFC
+00000001FFC03FFC00000001FFE03FFC00000001FFE03FFC00000001FFE07FF800000000
+FFF07FF800000000FFF07FF800000000FFF07FF800000000FFF0FFF800000000FFF8FFF8
+00000000FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000
+FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000FFF8FFF8
+00000000FFF8FFF800000000FFF87FF800000000FFF07FFC00000001FFF07FFC00000001
+FFF07FFC00000001FFF03FFC00000001FFE03FFC00000001FFE03FFE00000003FFE01FFE
+00000003FFC01FFE00000003FFC00FFF00000007FF8007FF00000007FF0007FF8000000F
+FF0003FFC000001FFE0001FFC000001FFC0000FFE000003FF800007FF000007FF000003F
+FC0001FFE000001FFF0007FFC0000007FFC01FFF00000001FFFFFFFC000000007FFFFFF0
+000000000FFFFF800000000000FFF80000003D3B7BB948>I<FFFFFFFFFF0000FFFFFFFF
+FFF000FFFFFFFFFFFE00FFFFFFFFFFFF80007FF8000FFFC0007FF80001FFE0007FF80000
+FFF0007FF800007FF8007FF800003FFC007FF800003FFC007FF800001FFE007FF800001F
+FE007FF800001FFF007FF800001FFF007FF800001FFF007FF800001FFF007FF800001FFF
+007FF800001FFF007FF800001FFF007FF800001FFF007FF800001FFE007FF800001FFE00
+7FF800003FFC007FF800003FFC007FF800007FF8007FF80000FFF0007FF80001FFE0007F
+F8000FFFC0007FFFFFFFFF00007FFFFFFFFC00007FFFFFFFE000007FF800000000007FF8
+00000000007FF800000000007FF800000000007FF800000000007FF800000000007FF800
+000000007FF800000000007FF800000000007FF800000000007FF800000000007FF80000
+0000007FF800000000007FF800000000007FF800000000007FF800000000007FF8000000
+00007FF800000000007FF800000000007FF800000000007FF800000000007FF800000000
+FFFFFFFC000000FFFFFFFC000000FFFFFFFC000000FFFFFFFC00000038397DB841>I<FF
+FFFFFFFC00000000FFFFFFFFFFE0000000FFFFFFFFFFFC000000FFFFFFFFFFFF00000000
+7FF8000FFFC00000007FF80001FFE00000007FF80000FFF00000007FF800007FF8000000
+7FF800003FFC0000007FF800003FFC0000007FF800001FFE0000007FF800001FFE000000
+7FF800001FFF0000007FF800001FFF0000007FF800001FFF0000007FF800001FFF000000
+7FF800001FFF0000007FF800001FFF0000007FF800001FFF0000007FF800001FFE000000
+7FF800001FFE0000007FF800003FFC0000007FF800003FF80000007FF800007FF0000000
+7FF80000FFE00000007FF80003FFC00000007FF8001FFF000000007FFFFFFFFC00000000
+7FFFFFFFE0000000007FFFFFFFF0000000007FF8003FFC000000007FF8000FFE00000000
+7FF80007FF800000007FF80003FF800000007FF80001FFC00000007FF80001FFE0000000
+7FF80000FFE00000007FF80000FFF00000007FF80000FFF00000007FF80000FFF0000000
+7FF80000FFF00000007FF80000FFF00000007FF80000FFF00000007FF80000FFF8000000
+7FF80000FFF80000007FF80000FFF80000007FF80000FFF80000007FF80000FFF8006000
+7FF80000FFF800F0007FF80000FFFC00F0007FF800007FFC00F0007FF800007FFC00F000
+7FF800003FFE01E0FFFFFFFC001FFE03E0FFFFFFFC000FFF07C0FFFFFFFC0003FFFF80FF
+FFFFFC0000FFFF000000000000000FFC00443A7DB848>82 D<0007FF000600003FFFE00E
+0000FFFFF81E0001FFFFFE3E0003FC01FF7E0007F0001FFE000FC00007FE001F800003FE
+003F800001FE003F000000FE007F0000007E007F0000007E007F0000003E00FF0000003E
+00FF0000003E00FF8000001E00FF8000001E00FFC000001E00FFE000001E00FFF0000000
+00FFFC000000007FFFE00000007FFFFE0000003FFFFFF000003FFFFFFE00001FFFFFFF80
+000FFFFFFFC00007FFFFFFE00003FFFFFFF00001FFFFFFF80000FFFFFFFC00003FFFFFFE
+00000FFFFFFF000001FFFFFF0000000FFFFF800000007FFF800000000FFF8000000003FF
+C000000001FFC000000000FFC0700000007FC0F00000007FC0F00000003FC0F00000003F
+C0F00000003FC0F80000003FC0F80000003F80F80000003F80FC0000003F80FE0000007F
+00FF0000007F00FF800000FE00FFE00001FC00FFF80003F800FDFF801FF000F8FFFFFFE0
+00F03FFFFF8000E007FFFE0000C0007FF000002A3B7BB935>I<3FFFFFFFFFFFFF803FFF
+FFFFFFFFFF803FFFFFFFFFFFFF803FFFFFFFFFFFFF803FF800FFF003FF807FC000FFF000
+7FC07F8000FFF0001FC07E0000FFF0000FC07E0000FFF0000FC07C0000FFF00007C07C00
+00FFF00007C0780000FFF00003C0780000FFF00003C0780000FFF00003C0780000FFF000
+03C0F80000FFF00003E0F00000FFF00001E0F00000FFF00001E0F00000FFF00001E0F000
+00FFF00001E0000000FFF0000000000000FFF0000000000000FFF0000000000000FFF000
+0000000000FFF0000000000000FFF0000000000000FFF0000000000000FFF00000000000
+00FFF0000000000000FFF0000000000000FFF0000000000000FFF0000000000000FFF000
+0000000000FFF0000000000000FFF0000000000000FFF0000000000000FFF00000000000
+00FFF0000000000000FFF0000000000000FFF0000000000000FFF0000000000000FFF000
+0000000000FFF0000000000000FFF0000000000000FFF0000000000000FFF00000000000
+00FFF0000000000000FFF0000000000000FFF0000000000000FFF0000000000000FFF000
+0000000000FFF0000000000FFFFFFFFF0000000FFFFFFFFF0000000FFFFFFFFF0000000F
+FFFFFFFF00003B387DB742>I<FFFFFFFC000FFFFFC0FFFFFFFC000FFFFFC0FFFFFFFC00
+0FFFFFC0FFFFFFFC000FFFFFC0007FF80000000FC000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000007FF80000
+00078000007FF8000000078000007FF8000000078000007FF8000000078000003FF80000
+00078000003FF80000000F0000003FF80000000F0000001FFC0000000F0000001FFC0000
+001E0000000FFC0000003E0000000FFE0000003C00000007FF0000007800000003FF8000
+01F800000001FFC00003F000000000FFE0000FE0000000003FFC00FFC0000000001FFFFF
+FF000000000003FFFFFC000000000000FFFFF00000000000000FFF00000000423A7DB849
+>I<FFFFFFF00000FFFFE0FFFFFFF00000FFFFE0FFFFFFF00000FFFFE0FFFFFFF00000FF
+FFE000FFF000000003F00000FFF800000003E000007FF800000003C000007FFC00000007
+C000003FFC000000078000003FFE000000078000001FFE0000000F0000001FFF0000000F
+0000001FFF0000001F0000000FFF8000001E0000000FFF8000003E00000007FF8000003C
+00000007FFC000007C00000003FFC000007800000003FFE000007800000001FFE00000F0
+00000001FFF00000F000000001FFF00001F000000000FFF80001E000000000FFF80003E0
+000000007FF80003C0000000007FFC0007C0000000003FFC000780000000003FFE000F80
+000000001FFE000F00000000001FFF000F00000000001FFF001F00000000000FFF801E00
+000000000FFF803E000000000007FF803C000000000007FFC07C000000000003FFC07800
+0000000003FFE0F8000000000001FFE0F0000000000001FFF0F0000000000001FFF1F000
+0000000000FFF9E0000000000000FFFBE00000000000007FFBC00000000000007FFFC000
+00000000003FFF800000000000003FFF800000000000001FFF000000000000001FFF0000
+00000000000FFE000000000000000FFE000000000000000FFE0000000000000007FC0000
+000000000007FC0000000000000003F80000000000000003F80000000000000001F00000
+000000000001F00000000043397EB848>I<003FFE00000001FFFFE0000007FFFFF80000
+0FF007FC00000FF001FE00001FF800FF00001FF8007F80001FF8007FC0001FF8003FC000
+0FF0003FE00007E0003FE0000180003FE0000000003FE0000000003FE0000000003FE000
+000007FFE0000003FFFFE000003FFFFFE00000FFF03FE00003FF003FE0000FFC003FE000
+1FF8003FE0003FF0003FE0007FE0003FE0007FE0003FE000FFC0003FE000FFC0003FE000
+FFC0003FE000FFC0003FE000FFC0007FE0007FE0007FE0007FE000DFE0003FF0039FF000
+1FFC0F1FFFC00FFFFE0FFFC003FFF807FFC0003FE001FFC02A257DA42E>97
+D<00FE00000000FFFE00000000FFFE00000000FFFE00000000FFFE0000000007FE000000
+0003FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE000000
+0003FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE000000
+0003FE0000000003FE0000000003FE0000000003FE03FF000003FE1FFFE00003FE7FFFF8
+0003FFFC07FC0003FFE001FF0003FF8000FF8003FF00007FC003FE00003FE003FE00003F
+E003FE00003FF003FE00001FF003FE00001FF803FE00001FF803FE00001FF803FE00001F
+FC03FE00001FFC03FE00001FFC03FE00001FFC03FE00001FFC03FE00001FFC03FE00001F
+FC03FE00001FFC03FE00001FFC03FE00001FF803FE00001FF803FE00001FF803FE00003F
+F003FE00003FF003FE00003FE003FF00007FC003FF00007F8003FF8000FF0003FBE001FE
+0003F8F80FFC0003F07FFFF00003E01FFFC00003C007FE00002E3A7DB935>I<0001FFE0
+00000FFFFC00007FFFFF0000FF807F8001FE007F8007FC00FFC00FF800FFC00FF800FFC0
+1FF000FFC03FF0007F803FF0003F007FE0000C007FE00000007FE0000000FFE0000000FF
+E0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0
+0000007FE00000007FE00000007FF00000003FF00000003FF00001E01FF80001E00FF800
+03C00FFC0003C007FE00078001FF000F0000FFC07E00007FFFFC00000FFFF0000001FF80
+0023257DA42A>I<000000007F000000007FFF000000007FFF000000007FFF000000007F
+FF0000000003FF0000000001FF0000000001FF0000000001FF0000000001FF0000000001
+FF0000000001FF0000000001FF0000000001FF0000000001FF0000000001FF0000000001
+FF0000000001FF0000000001FF0000000001FF0000000001FF000001FF81FF00000FFFF1
+FF00003FFFF9FF0000FFC07FFF0001FE001FFF0003FC0007FF0007F80003FF000FF80001
+FF001FF00001FF003FF00001FF003FF00001FF007FE00001FF007FE00001FF007FE00001
+FF00FFE00001FF00FFE00001FF00FFE00001FF00FFE00001FF00FFE00001FF00FFE00001
+FF00FFE00001FF00FFE00001FF00FFE00001FF007FE00001FF007FE00001FF007FE00001
+FF003FE00001FF003FF00001FF001FF00001FF001FF00003FF000FF80007FF0007FC000F
+FF0003FE001FFF8000FF80FDFFFC007FFFF9FFFC001FFFE1FFFC0001FF01FFFC2E3A7DB9
+35>I<0001FF8000001FFFF000007FFFFC0000FF81FE0003FE007F8007FC003F800FF800
+1FC01FF0001FE01FF0000FE03FF0000FF03FE0000FF07FE0000FF07FE00007F87FE00007
+F8FFE00007F8FFE00007F8FFFFFFFFF8FFFFFFFFF8FFFFFFFFF8FFE0000000FFE0000000
+FFE0000000FFE00000007FE00000007FE00000007FE00000003FF00000003FF00000781F
+F00000780FF80000F80FF80000F007FC0003E001FF0007E000FFC03F80003FFFFF00000F
+FFFC000000FFC00025257DA42C>I<00003FE0000001FFF8000007FFFE00001FF07F0000
+3FC0FF00007F81FF8000FF01FF8001FF01FF8001FE01FF8003FE00FF0003FE007E0003FE
+003C0003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00
+000003FE00000003FE000000FFFFFF0000FFFFFF0000FFFFFF0000FFFFFF000003FE0000
+0003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE000000
+03FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003
+FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE
+00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE000000FFFFFC
+0000FFFFFC0000FFFFFC0000FFFFFC0000213A7DB91D>I<000000001F000007FE007F80
+007FFFE1FFC001FFFFFBE7E003FE07FF0FE007F801FE0FE00FF000FF0FE01FF000FF87C0
+3FE0007FC3803FE0007FC0007FE0007FE0007FE0007FE0007FE0007FE0007FE0007FE000
+7FE0007FE0007FE0007FE0003FE0007FC0003FE0007FC0001FF000FF80000FF000FF0000
+07F801FE000003FE07FC000007FFFFF80000067FFFE000000E07FE0000001E0000000000
+1E00000000001E00000000001E00000000001F00000000001FC0000000001FFFFFF80000
+1FFFFFFF80000FFFFFFFE0000FFFFFFFF00007FFFFFFF80003FFFFFFFC0003FFFFFFFE00
+0FFFFFFFFF001F80000FFF003F000000FF807F0000007F80FE0000003F80FE0000003F80
+FE0000003F80FE0000003F80FE0000003F807F0000007F003F800000FE001FC00001FC00
+0FF00007F80007FE003FF00001FFFFFFC000007FFFFF00000007FFF000002B377DA530>
+I<00FE00000000FFFE00000000FFFE00000000FFFE00000000FFFE0000000007FE000000
+0003FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE000000
+0003FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE000000
+0003FE0000000003FE0000000003FE0000000003FE00FF800003FE07FFE00003FE0FFFF0
+0003FE1E07F80003FE3803FC0003FE6003FE0003FEC001FE0003FF8001FF0003FF8001FF
+0003FF0001FF0003FF0001FF0003FF0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+00FFFFF87FFFFCFFFFF87FFFFCFFFFF87FFFFCFFFFF87FFFFC2E3A7CB935>I<01F00007
+FC000FFE000FFE001FFF001FFF001FFF001FFF001FFF000FFE000FFE0007FC0001F00000
+000000000000000000000000000000000000000000000000000000FE007FFE007FFE007F
+FE007FFE0007FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003
+FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003
+FE0003FE0003FE0003FE0003FE0003FE00FFFFF0FFFFF0FFFFF0FFFFF0143B7DBA1A>I<
+00FE00000000FFFE00000000FFFE00000000FFFE00000000FFFE0000000007FE00000000
+03FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE00000000
+03FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE00000000
+03FE0000000003FE0000000003FE0000000003FE000FFFE003FE000FFFE003FE000FFFE0
+03FE000FFFE003FE0003F80003FE0003F00003FE000FE00003FE001F800003FE003F0000
+03FE007E000003FE01FC000003FE03F0000003FE07E0000003FE0FC0000003FE3FC00000
+03FE7FE0000003FEFFE0000003FFFFF0000003FFFFF8000003FFCFFC000003FF87FC0000
+03FF07FE000003FE03FF000003FC01FF800003FC00FFC00003FC00FFC00003FC007FE000
+03FC003FF00003FC001FF80003FC000FFC0003FC000FFC0003FC0007FE0003FC0003FF00
+FFFFF01FFFF8FFFFF01FFFF8FFFFF01FFFF8FFFFF01FFFF82D3A7EB932>107
+D<00FE00FFFE00FFFE00FFFE00FFFE0007FE0003FE0003FE0003FE0003FE0003FE0003FE
+0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE
+0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE
+0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE
+0003FE0003FE0003FE0003FE0003FE0003FE00FFFFF8FFFFF8FFFFF8FFFFF8153A7DB91A
+>I<01FC00FF80003FE00000FFFC03FFF000FFFC0000FFFC0FFFF803FFFE0000FFFC1E03
+FC0780FF0000FFFC3801FE0E007F800007FC6001FF18007FC00003FCC000FF30003FC000
+03FD8000FFE0003FE00003FD8000FFE0003FE00003FF0000FFC0003FE00003FF0000FFC0
+003FE00003FF0000FFC0003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE
+0000FF80003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE0000FF80003F
+E00003FE0000FF80003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE0000
+FF80003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE0000FF80003FE000
+03FE0000FF80003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE0000FF80
+003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE0000FF80003FE00003FE
+0000FF80003FE000FFFFF83FFFFE0FFFFF80FFFFF83FFFFE0FFFFF80FFFFF83FFFFE0FFF
+FF80FFFFF83FFFFE0FFFFF8049257CA450>I<01FC00FF8000FFFC07FFE000FFFC0FFFF0
+00FFFC1E07F800FFFC3803FC0007FC6003FE0003FCC001FE0003FD8001FF0003FD8001FF
+0003FF0001FF0003FF0001FF0003FF0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF
+00FFFFF87FFFFCFFFFF87FFFFCFFFFF87FFFFCFFFFF87FFFFC2E257CA435>I<0001FFC0
+0000000FFFF80000007FFFFF000000FF80FF800003FE003FE00007FC001FF0000FF8000F
+F8001FF00007FC001FF00007FC003FF00007FE003FE00003FE007FE00003FF007FE00003
+FF007FE00003FF00FFE00003FF80FFE00003FF80FFE00003FF80FFE00003FF80FFE00003
+FF80FFE00003FF80FFE00003FF80FFE00003FF80FFE00003FF807FE00003FF007FE00003
+FF007FE00003FF003FE00003FE003FF00007FE001FF00007FC001FF00007FC000FF8000F
+F80007FC001FF00003FE003FE00001FF80FFC000007FFFFF0000001FFFFC00000001FFC0
+000029257DA430>I<00FE03FF0000FFFE1FFFE000FFFE7FFFF800FFFFFC0FFC00FFFFE0
+03FF0007FF8001FF8003FF0000FFC003FE00007FE003FE00007FE003FE00003FF003FE00
+003FF003FE00003FF803FE00003FF803FE00001FF803FE00001FFC03FE00001FFC03FE00
+001FFC03FE00001FFC03FE00001FFC03FE00001FFC03FE00001FFC03FE00001FFC03FE00
+001FFC03FE00001FF803FE00003FF803FE00003FF803FE00003FF003FE00007FF003FE00
+007FE003FF00007FC003FF0000FF8003FF8001FF0003FFE003FE0003FEF80FFC0003FE7F
+FFF00003FE1FFFC00003FE07FE000003FE0000000003FE0000000003FE0000000003FE00
+00000003FE0000000003FE0000000003FE0000000003FE0000000003FE0000000003FE00
+00000003FE0000000003FE00000000FFFFF8000000FFFFF8000000FFFFF8000000FFFFF8
+0000002E357DA435>I<01FC03F000FFFC0FFC00FFFC1FFF00FFFC3C7F80FFFC707F8007
+FCE0FFC003FCC0FFC003FD80FFC003FD80FFC003FF807F8003FF003F0003FF000C0003FF
+00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00
+000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE0000
+0003FE00000003FE00000003FE00000003FE00000003FE00000003FE000000FFFFFC0000
+FFFFFC0000FFFFFC0000FFFFFC000022257EA427>114 D<007FF03803FFFEF807FFFFF8
+1FC00FF83F0003F83E0000F87C0000F87C000078FC000078FC000078FE000078FF000000
+FFE000007FFF80007FFFF8003FFFFF001FFFFF800FFFFFE007FFFFF001FFFFF8007FFFFC
+0003FFFC00000FFE000003FE700000FEF00000FEF000007EF800007EF800007EFC00007C
+FE00007CFF0000F8FF8001F0FFF00FE0FFFFFFC0F0FFFF00C01FF8001F257DA426>I<00
+1E0000001E0000001E0000001E0000001E0000003E0000003E0000003E0000003E000000
+7E0000007E000000FE000000FE000001FE000003FE000007FE00001FFFFFE0FFFFFFE0FF
+FFFFE0FFFFFFE003FE000003FE000003FE000003FE000003FE000003FE000003FE000003
+FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003FE000003
+FE000003FE000003FE007803FE007803FE007803FE007803FE007803FE007803FE007803
+FE007801FE00F001FF00F000FF01E0007F83C0003FFF80001FFF000003FC001D357EB425
+>I<00FE00007F00FFFE007FFF00FFFE007FFF00FFFE007FFF00FFFE007FFF0007FE0003
+FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001
+FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001
+FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0001
+FF0003FE0001FF0003FE0001FF0003FE0001FF0003FE0003FF0003FE0003FF0003FE0003
+FF0001FE0007FF0001FE000FFF0000FF001DFF80007F8079FFFC003FFFF1FFFC001FFFC1
+FFFC0003FF01FFFC2E257CA435>I<FFFFE001FFF8FFFFE001FFF8FFFFE001FFF8FFFFE0
+01FFF803FE00001F0003FE00001E0003FF00003E0001FF00003C0001FF80007C0000FF80
+00780000FFC000F800007FC000F000007FE001F000003FE001E000003FE001E000001FF0
+03C000001FF003C000001FF807C000000FF8078000000FFC0F80000007FC0F00000007FE
+1F00000003FE1E00000003FF3E00000001FF3C00000001FF3C00000000FFF800000000FF
+F800000000FFF8000000007FF0000000007FF0000000003FE0000000003FE0000000001F
+C0000000001FC0000000000F80000000000F8000002D257EA432>I<FFFFE0FFFF803FFF
+FFFFE0FFFF803FFFFFFFE0FFFF803FFFFFFFE0FFFF803FFF07FC0007F80003E007FE0003
+F80003E003FE0003FC0003C003FE0007FC0007C001FF0007FC00078001FF0007FE000780
+01FF800FFE000F8000FF800FFF000F0000FF801FFF000F00007FC01E7F001E00007FC01E
+7F801E00007FE03E7F803E00003FE03C3FC03C00003FE07C3FC03C00001FF0781FC07800
+001FF0781FE07800001FF8F81FE0F800000FF8F00FF0F000000FF9F00FF0F000000FFDE0
+07F1F0000007FDE007F9E0000007FFE007FBE0000003FFC003FBC0000003FFC003FFC000
+0003FF8001FFC0000001FF8001FF80000001FF8001FF80000000FF0000FF00000000FF00
+00FF00000000FE00007F000000007E00007E000000007E00007E000000003C00003C0000
+40257EA445>I<FFFFC00FFFF0FFFFC00FFFF0FFFFC00FFFF0FFFFC00FFFF003FF0001F8
+0001FF8003F00000FF8003E000007FC007C000003FE00F8000001FF01F0000001FF83E00
+00000FFC7C00000007FCFC00000003FFF800000001FFF000000000FFE000000000FFC000
+0000007FE0000000003FE0000000003FF0000000007FF800000000FFFC00000000FFFE00
+000001F3FF00000003E1FF00000007C0FF8000000F807FC000001F803FE000003F003FF0
+00003E001FF800007C000FF80000F80007FC0001F80003FE00FFFF001FFFF8FFFF001FFF
+F8FFFF001FFFF8FFFF001FFFF82D257EA432>I<FFFFE001FFF8FFFFE001FFF8FFFFE001
+FFF8FFFFE001FFF803FE00001F0003FE00001E0003FF00003E0001FF00003C0001FF8000
+7C0000FF8000780000FFC000F800007FC000F000007FE001F000003FE001E000003FE001
+E000001FF003C000001FF003C000001FF807C000000FF8078000000FFC0F80000007FC0F
+00000007FE1F00000003FE1E00000003FF3E00000001FF3C00000001FF3C00000000FFF8
+00000000FFF800000000FFF8000000007FF0000000007FF0000000003FE0000000003FE0
+000000001FC0000000001FC0000000000F80000000000F80000000000F00000000000F00
+000000001F00000000001E00000000003E0000003E003C0000007F007C000000FF807800
+0000FF80F8000000FF81F0000000FF83E0000000FF07C00000007F1F800000003FFF0000
+00001FFC0000000007F0000000002D357EA432>I<3FFFFFFFC03FFFFFFFC03FFFFFFFC0
+3FF001FF803F8003FF003F0007FF003E0007FE003C000FFC007C001FF8007C001FF80078
+003FF00078007FE0007800FFE0007800FFC0007801FF80000003FF00000007FF00000007
+FE0000000FFC0000001FF80000003FF80000003FF003C0007FE003C000FFC003C001FFC0
+03C001FF8003C003FF0007C007FE0007C007FE0007C00FFC000F801FF8000F803FF8001F
+803FF0007F807FE001FF80FFFFFFFF80FFFFFFFF80FFFFFFFF8022257DA42A>I
+E /Fj 49 122 df<FFFFFFF8FFFFFFF8FFFFFFF8FFFFFFF8FFFFFFF8FFFFFFF8FFFFFFF8
+FFFFFFF8FFFFFFF81D097F9A25>45 D<00003FF800000001FFFF0000000FFFFFE000003F
+F01FF800007FC007FC0000FF8003FE0001FF0001FF0003FE0000FF8007FC00007FC007FC
+00007FC00FF800003FE00FF800003FE01FF800003FF01FF800003FF03FF800003FF83FF0
+00001FF83FF000001FF87FF000001FFC7FF000001FFC7FF000001FFC7FF000001FFC7FF0
+00001FFC7FF000001FFCFFF000001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF0
+00001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF0
+00001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF0
+00001FFEFFF000001FFEFFF000001FFEFFF000001FFEFFF000001FFE7FF000001FFC7FF0
+00001FFC7FF000001FFC7FF000001FFC7FF000001FFC3FF000001FF83FF800003FF83FF8
+00003FF81FF800003FF01FF800003FF00FF800003FE00FFC00007FE007FC00007FC007FC
+00007FC003FE0000FF8001FF0001FF0000FF8003FE00007FC007FC00003FF01FF800000F
+FFFFE0000003FFFF800000003FF800002F427CC038>48 D<000003C000000007C0000000
+1FC00000007FC0000003FFC000003FFFC000FFFFFFC000FFFFFFC000FFFFFFC000FFC3FF
+C0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0
+000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC000
+0003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC00000
+03FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003
+FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FF
+C0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0
+000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC0000003FFC000
+0003FFC000FFFFFFFFFCFFFFFFFFFCFFFFFFFFFCFFFFFFFFFC264177C038>I<0000FFE0
+0000000FFFFE0000003FFFFFC00000FFFFFFF00003FE01FFF80007F0007FFC000FC0001F
+FF001F80000FFF803F000007FF803F000003FFC07FC00003FFE07FE00001FFE0FFF00001
+FFF0FFF80000FFF0FFF80000FFF8FFF80000FFF8FFF80000FFF8FFF80000FFF87FF00000
+FFF87FF00000FFF83FE00000FFF81FC00000FFF800000000FFF000000000FFF000000001
+FFF000000001FFE000000001FFE000000003FFC000000003FF8000000007FF8000000007
+FF000000000FFE000000001FFC000000001FF8000000003FE0000000007FC000000000FF
+8000000000FF0000000001FC0000000003F80000000007F0000000000FC0000000001F80
+000000003F00007800007C0000780000F80000780001F00000F80003E00000F00007C000
+00F0000F000000F0001E000000F0003C000001F00078000003F000FFFFFFFFF001FFFFFF
+FFE003FFFFFFFFE007FFFFFFFFE00FFFFFFFFFE01FFFFFFFFFE03FFFFFFFFFE07FFFFFFF
+FFE0FFFFFFFFFFC0FFFFFFFFFFC0FFFFFFFFFFC0FFFFFFFFFFC02D417BC038>I<0000FF
+F000000007FFFF0000001FFFFFC000007F80FFF00000FC001FF80001F0000FFC0003C000
+0FFE0007E00007FF000FF80007FF800FFC0007FF800FFE0007FFC01FFF0007FFC01FFF00
+07FFC01FFF0007FFC01FFF0007FFC01FFF0007FFC00FFE0007FFC00FFE0007FF8007FC00
+07FF8003F8000FFF800000000FFF000000000FFE000000001FFE000000001FFC00000000
+3FF8000000003FF0000000007FC000000001FF800000000FFE00000007FFF800000007FF
+F000000007FFFF0000000000FFC0000000001FF0000000000FFC0000000007FE00000000
+07FF0000000003FF8000000003FFC000000003FFE000000001FFE000000001FFF0000000
+01FFF000000001FFF800000001FFF80FC00001FFF83FF00001FFF87FF80001FFF87FF800
+01FFF8FFFC0001FFF8FFFC0001FFF8FFFC0001FFF0FFFC0001FFF0FFFC0001FFF0FFF800
+03FFE07FF80003FFE07FF00003FFC03FE00007FF803F000007FF001FC0000FFF000FF000
+1FFC0003FF00FFF80001FFFFFFF000007FFFFFC000001FFFFE00000001FFE000002D427B
+C038>I<000000001F0000000000003F0000000000003F0000000000007F000000000000
+FF000000000001FF000000000001FF000000000003FF000000000007FF00000000000FFF
+00000000001FFF00000000001FFF00000000003FFF00000000007FFF0000000000FFFF00
+00000001F7FF0000000001E7FF0000000003C7FF000000000787FF000000000F87FF0000
+00001F07FF000000001E07FF000000003C07FF000000007807FF00000000F807FF000000
+01F007FF00000001E007FF00000003C007FF000000078007FF0000000F8007FF0000001F
+0007FF0000001E0007FF0000003C0007FF000000780007FF000000F80007FF000000F000
+07FF000001E00007FF000003C00007FF000007800007FF00000F800007FF00000F000007
+FF00001E000007FF00003C000007FF00007C000007FF0000F8000007FF0000FFFFFFFFFF
+FF80FFFFFFFFFFFF80FFFFFFFFFFFF80FFFFFFFFFFFF800000000FFF00000000000FFF00
+000000000FFF00000000000FFF00000000000FFF00000000000FFF00000000000FFF0000
+0000000FFF00000000000FFF00000000000FFF00000000000FFF00000000000FFF000000
+007FFFFFFF8000007FFFFFFF8000007FFFFFFF8000007FFFFFFF8031417DC038>I<0300
+0000030007E000003F0007FF0007FF0007FFFFFFFE0007FFFFFFFC0007FFFFFFF80007FF
+FFFFF00007FFFFFFE00007FFFFFFC00007FFFFFF000007FFFFFE000007FFFFF8000007FF
+FFE0000007FFFE00000007C00000000007C00000000007C00000000007C00000000007C0
+0000000007C00000000007C00000000007C00000000007C00000000007C00000000007C0
+3FF0000007C1FFFF000007C7FFFFC00007DFC03FF00007FE000FF80007F80007FC0007F0
+0003FE0007E00001FF0007C00001FF8003800001FFC000000001FFC000000000FFE00000
+0000FFE000000000FFF000000000FFF000000000FFF000000000FFF800000000FFF80600
+0000FFF81FC00000FFF83FE00000FFF87FF00000FFF8FFF00000FFF8FFF80000FFF8FFF8
+0000FFF8FFF80000FFF0FFF00000FFF0FFF00000FFF0FFE00000FFE07FC00001FFE07F80
+0001FFE03C000001FFC03E000003FF801E000003FF000F800007FE0007C0000FFC0003F0
+003FF80001FE00FFF00000FFFFFFE000003FFFFF8000000FFFFC00000001FFC000002D42
+7BC038>I<000001FF800000001FFFF00000007FFFFC000001FF807E000007FC001F0000
+0FF0000780001FE0001FC0003FC0007FC0007F8000FFE000FF0000FFE001FF0001FFE003
+FE0001FFE007FE0001FFE007FE0001FFE00FFC0000FFC00FFC0000FFC01FFC00007F801F
+FC00001E003FFC000000003FFC000000003FF8000000007FF8000000007FF8000000007F
+F8000000007FF81FFE00007FF83FFFC000FFF87FFFE000FFF8E00FF800FFF98007FC00FF
+FB8003FE00FFFB0001FF00FFFE0001FF80FFFE0001FFC0FFFE0000FFC0FFFC0000FFE0FF
+FC0000FFE0FFFC0000FFF0FFFC0000FFF0FFF80000FFF0FFF80000FFF8FFF80000FFF8FF
+F80000FFF87FF80000FFF87FF80000FFF87FF80000FFF87FF80000FFF87FF80000FFF87F
+F80000FFF83FF80000FFF83FF80000FFF83FF80000FFF01FF80000FFF01FFC0000FFF00F
+FC0000FFE00FFC0000FFE007FC0001FFC007FC0001FFC003FE0001FF8001FF0003FF0000
+FF0003FE00007FC007FC00003FF03FF800001FFFFFF0000007FFFFC0000001FFFF000000
+003FF800002D427BC038>I<1E00000000001F00000000001FFC000000001FFFFFFFFFFE
+1FFFFFFFFFFE1FFFFFFFFFFE1FFFFFFFFFFE3FFFFFFFFFFC3FFFFFFFFFF83FFFFFFFFFF0
+3FFFFFFFFFE03FFFFFFFFFC03FFFFFFFFFC03FFFFFFFFF807FFFFFFFFF007E0000003E00
+7C0000007C007C000000FC0078000001F80078000003F00078000007E000F8000007C000
+F000000F8000F000001F8000F000003F00000000007E00000000007C0000000000FC0000
+000001F80000000001F00000000003F00000000007F00000000007E0000000000FE00000
+00000FE0000000001FC0000000001FC0000000003FC0000000003FC0000000007F800000
+00007F8000000000FF8000000000FF8000000001FF8000000001FF8000000001FF800000
+0003FF0000000003FF0000000003FF0000000003FF0000000007FF0000000007FF000000
+0007FF0000000007FF0000000007FF000000000FFF000000000FFF000000000FFF000000
+000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000
+0007FE0000000007FE0000000003FC0000000000F00000002F447AC238>I<00007FF000
+000003FFFF0000000FFFFFC000003F801FF000007C0003F80000F80001FC0001F00000FE
+0003E000007F0007E000003F8007C000003F800FC000003F800FC000001FC00FC000001F
+C01FC000001FC01FE000001FC01FE000001FC01FF000001FC01FF800001FC01FFE00003F
+801FFF00003F801FFFC0003F000FFFF0007F000FFFFC00FE000FFFFE00FC0007FFFF81F8
+0003FFFFE7F00003FFFFFFE00001FFFFFF800000FFFFFF0000007FFFFFC000003FFFFFE0
+00000FFFFFF8000007FFFFFC00001FFFFFFE00007F7FFFFF0000FE1FFFFF8003F80FFFFF
+C007F003FFFFC00FF000FFFFE01FE0007FFFE01FC0001FFFF03FC00007FFF07F800001FF
+F87F800000FFF87F8000003FF8FF0000001FF8FF0000001FF8FF0000000FF8FF0000000F
+F8FF00000007F8FF00000007F8FF00000007F0FF00000007F07F80000007F07F80000007
+E07F8000000FE03FC000000FC01FE000001FC01FF000003F800FF800007F0007FE0001FE
+0003FFC00FFC0000FFFFFFF000003FFFFFC000000FFFFF00000000FFF000002D427BC038
+>I<00007FF000000007FFFE0000001FFFFF8000003FE03FC00000FF800FF00001FF0007
+F80003FE0003FC0007FC0003FE000FFC0001FE001FFC0001FF001FF80001FF803FF80001
+FF803FF80000FFC07FF80000FFC07FF80000FFE07FF80000FFE0FFF80000FFE0FFF80000
+FFE0FFF80000FFF0FFF80000FFF0FFF80000FFF0FFF80000FFF0FFF80000FFF0FFF80000
+FFF8FFF80000FFF8FFF80000FFF8FFF80000FFF87FF80000FFF87FF80001FFF87FF80001
+FFF83FF80001FFF83FF80001FFF81FF80003FFF81FFC0003FFF80FFC0003FFF807FC0006
+FFF803FE000EFFF801FF001CFFF800FF8038FFF8003FFFF0FFF8001FFFE0FFF00003FFC0
+FFF000000000FFF000000000FFF000000000FFF000000000FFE000000000FFE000000001
+FFE003C00001FFC00FF00001FFC01FF80001FF801FF80001FF803FFC0003FF003FFC0003
+FF003FFC0003FE003FFC0007FC003FF80007FC001FF8000FF8001FF0001FF0001FC0003F
+E0000FC000FFC00007F803FF000003FFFFFE000001FFFFF80000007FFFE000000007FE00
+00002D427BC038>I<0007FFC000007FFFFC0001FFFFFF8007F801FFE00FC0003FF01F00
+001FF83E00001FFC7F80000FFE7FC0000FFE7FE0000FFEFFF0000FFFFFF0000FFFFFF000
+0FFFFFF0000FFFFFF0000FFF7FE0000FFF3FC0000FFE1F80001FFE0600001FFC0000003F
+F80000007FF0000000FFE0000001FF80000001FF00000003FC00000007F80000000FE000
+00000FC00000001F800000001F800000003F000000003E000000003C000000007C000000
+0078000000007800000000F800000000F000000000F000000000F000000000F000000000
+F000000000F000000000F000000000F000000000F0000000006000000000000000000000
+00000000000000000000000000000000000000000000000000000000000000000000F000
+000003FC00000007FE0000000FFF0000000FFF0000001FFF8000001FFF8000001FFF8000
+001FFF8000000FFF0000000FFF00000007FE00000003FC00000000F0000028457AC435>
+63 D<000000001F8000000000000000001F8000000000000000003FC000000000000000
+003FC000000000000000007FE000000000000000007FE000000000000000007FE0000000
+0000000000FFF00000000000000000FFF00000000000000001FFF80000000000000001FF
+F80000000000000001FFF80000000000000003FFFC0000000000000003FFFC0000000000
+000007FFFE0000000000000007FFFE0000000000000007FFFE000000000000000FFFFF00
+0000000000000F9FFF000000000000001F9FFF800000000000001F1FFF80000000000000
+1F0FFF800000000000003F0FFFC00000000000003E07FFC00000000000007E07FFE00000
+000000007C07FFE00000000000007C03FFE0000000000000FC03FFF0000000000000F801
+FFF0000000000001F801FFF8000000000001F001FFF8000000000001F000FFF800000000
+0003F000FFFC000000000003E0007FFC000000000007E0007FFE000000000007C0007FFE
+000000000007C0003FFE00000000000FC0003FFF00000000000F80001FFF00000000001F
+80001FFF80000000001F00000FFF80000000001F00000FFF80000000003F00000FFFC000
+0000003E000007FFC0000000007E000007FFE0000000007FFFFFFFFFE0000000007FFFFF
+FFFFE000000000FFFFFFFFFFF000000000FFFFFFFFFFF000000001F8000001FFF8000000
+01F0000000FFF800000001F0000000FFF800000003F0000000FFFC00000003E00000007F
+FC00000007E00000007FFE00000007C00000003FFE00000007C00000003FFE0000000F80
+0000003FFF0000000F800000001FFF0000001F800000001FFF8000001F000000000FFF80
+00003F000000000FFFC000003E000000000FFFC000003E0000000007FFC00000FF800000
+0007FFE000FFFFFF00000FFFFFFFF0FFFFFF00000FFFFFFFF0FFFFFF00000FFFFFFFF0FF
+FFFF00000FFFFFFFF04C457CC455>65 D<FFFFFFFFFFFF000000FFFFFFFFFFFFF00000FF
+FFFFFFFFFFFE0000FFFFFFFFFFFFFF8000003FFC000007FFE000003FFC000001FFF00000
+3FFC000000FFF800003FFC0000003FFC00003FFC0000003FFE00003FFC0000001FFF0000
+3FFC0000000FFF00003FFC0000000FFF80003FFC0000000FFF80003FFC00000007FFC000
+3FFC00000007FFC0003FFC00000007FFC0003FFC00000007FFC0003FFC00000007FFC000
+3FFC00000007FFC0003FFC00000007FFC0003FFC00000007FFC0003FFC0000000FFF8000
+3FFC0000000FFF80003FFC0000000FFF00003FFC0000001FFF00003FFC0000003FFE0000
+3FFC0000003FFC00003FFC0000007FF800003FFC000001FFF000003FFC000003FFC00000
+3FFC00001FFF0000003FFFFFFFFFFC0000003FFFFFFFFFF00000003FFFFFFFFFFF000000
+3FFC000003FFC000003FFC000000FFF000003FFC0000003FFC00003FFC0000001FFE0000
+3FFC0000000FFF00003FFC00000007FF80003FFC00000007FFC0003FFC00000003FFE000
+3FFC00000003FFE0003FFC00000001FFF0003FFC00000001FFF0003FFC00000001FFF000
+3FFC00000001FFF8003FFC00000001FFF8003FFC00000001FFF8003FFC00000001FFF800
+3FFC00000001FFF8003FFC00000001FFF8003FFC00000001FFF8003FFC00000001FFF800
+3FFC00000001FFF0003FFC00000003FFF0003FFC00000003FFE0003FFC00000007FFE000
+3FFC00000007FFC0003FFC0000000FFFC0003FFC0000001FFF80003FFC0000003FFF0000
+3FFC000000FFFE00003FFC000007FFF800FFFFFFFFFFFFFFF000FFFFFFFFFFFFFFC000FF
+FFFFFFFFFFFE0000FFFFFFFFFFFFE0000045447CC350>I<00000000FFF8000030000000
+1FFFFF000070000001FFFFFFE001F0000007FFFFFFF803F000003FFFE003FE07F000007F
+FE00007F0FF00001FFF000001F9FF00003FFC0000007FFF0000FFF00000003FFF0001FFE
+00000000FFF0003FFC000000007FF0007FF8000000007FF000FFF0000000003FF001FFE0
+000000001FF001FFC0000000000FF003FFC0000000000FF007FF800000000007F007FF80
+0000000007F00FFF000000000007F01FFF000000000003F01FFF000000000003F01FFE00
+0000000003F03FFE000000000001F03FFE000000000001F03FFE000000000001F07FFE00
+0000000001F07FFC000000000000007FFC000000000000007FFC00000000000000FFFC00
+000000000000FFFC00000000000000FFFC00000000000000FFFC00000000000000FFFC00
+000000000000FFFC00000000000000FFFC00000000000000FFFC00000000000000FFFC00
+000000000000FFFC00000000000000FFFC00000000000000FFFC000000000000007FFC00
+0000000000007FFC000000000000007FFC000000000000007FFE000000000000003FFE00
+0000000000F03FFE000000000000F03FFE000000000000F01FFE000000000000F01FFF00
+0000000000F01FFF000000000001F00FFF000000000001E007FF800000000001E007FF80
+0000000003E003FFC00000000003C001FFC00000000007C001FFE000000000078000FFF0
+000000000F00007FF8000000001F00003FFC000000001E00001FFE000000007C00000FFF
+00000000F8000003FFC0000003F0000001FFF0000007E00000007FFE00003F800000003F
+FFE001FF0000000007FFFFFFFC0000000001FFFFFFF000000000001FFFFF800000000000
+00FFF800000044467AC451>I<FFFFFFFFFFFF00000000FFFFFFFFFFFFF0000000FFFFFF
+FFFFFFFE000000FFFFFFFFFFFFFF800000003FFE00001FFFE00000003FFE000001FFF800
+00003FFE0000007FFC0000003FFE0000001FFF0000003FFE00000007FF8000003FFE0000
+0003FFC000003FFE00000001FFE000003FFE00000000FFF000003FFE000000007FF00000
+3FFE000000007FF800003FFE000000003FFC00003FFE000000003FFC00003FFE00000000
+1FFE00003FFE000000001FFE00003FFE000000000FFF00003FFE000000000FFF00003FFE
+000000000FFF80003FFE000000000FFF80003FFE0000000007FF80003FFE0000000007FF
+C0003FFE0000000007FFC0003FFE0000000007FFC0003FFE0000000007FFC0003FFE0000
+000007FFC0003FFE0000000007FFE0003FFE0000000007FFE0003FFE0000000007FFE000
+3FFE0000000007FFE0003FFE0000000007FFE0003FFE0000000007FFE0003FFE00000000
+07FFE0003FFE0000000007FFE0003FFE0000000007FFE0003FFE0000000007FFE0003FFE
+0000000007FFE0003FFE0000000007FFE0003FFE0000000007FFE0003FFE0000000007FF
+C0003FFE0000000007FFC0003FFE0000000007FFC0003FFE0000000007FFC0003FFE0000
+000007FFC0003FFE0000000007FF80003FFE000000000FFF80003FFE000000000FFF8000
+3FFE000000000FFF00003FFE000000000FFF00003FFE000000001FFE00003FFE00000000
+1FFE00003FFE000000003FFC00003FFE000000003FF800003FFE000000007FF800003FFE
+00000000FFF000003FFE00000001FFE000003FFE00000003FFC000003FFE00000007FF80
+00003FFE0000001FFF0000003FFE0000003FFE0000003FFE000001FFF80000003FFE0000
+1FFFF00000FFFFFFFFFFFFFFC00000FFFFFFFFFFFFFE000000FFFFFFFFFFFFF0000000FF
+FFFFFFFFFF000000004B447CC356>I<FFFFFFFFFFFFFFF800FFFFFFFFFFFFFFF800FFFF
+FFFFFFFFFFF800FFFFFFFFFFFFFFF800001FFF000003FFFC00001FFF0000003FFC00001F
+FF0000000FFC00001FFF00000003FC00001FFF00000001FC00001FFF00000000FC00001F
+FF00000000FC00001FFF000000007C00001FFF000000007E00001FFF000000003E00001F
+FF000000003E00001FFF000000001E00001FFF000000001E00001FFF000000001E00001F
+FF000000001E00001FFF000078001F00001FFF000078000F00001FFF000078000F00001F
+FF000078000F00001FFF000078000000001FFF000078000000001FFF0000F8000000001F
+FF0000F8000000001FFF0000F8000000001FFF0001F8000000001FFF0003F8000000001F
+FF001FF8000000001FFFFFFFF8000000001FFFFFFFF8000000001FFFFFFFF8000000001F
+FFFFFFF8000000001FFF001FF8000000001FFF0003F8000000001FFF0001F8000000001F
+FF0000F8000000001FFF0000F8000000001FFF0000F8000000001FFF0000780001E0001F
+FF0000780001E0001FFF0000780001E0001FFF0000780003C0001FFF0000780003C0001F
+FF0000780003C0001FFF0000000003C0001FFF0000000003C0001FFF0000000007C0001F
+FF0000000007C0001FFF000000000780001FFF000000000F80001FFF000000000F80001F
+FF000000000F80001FFF000000001F80001FFF000000001F80001FFF000000003F80001F
+FF000000007F00001FFF00000000FF00001FFF00000001FF00001FFF00000007FF00001F
+FF0000001FFF00001FFF000001FFFF00FFFFFFFFFFFFFFFF00FFFFFFFFFFFFFFFE00FFFF
+FFFFFFFFFFFE00FFFFFFFFFFFFFFFE0043447DC34A>I<FFFFFFFFFFFFFF80FFFFFFFFFF
+FFFF80FFFFFFFFFFFFFF80FFFFFFFFFFFFFF80003FFE00001FFFC0003FFE000001FFC000
+3FFE0000007FC0003FFE0000003FC0003FFE0000001FC0003FFE0000000FC0003FFE0000
+0007C0003FFE00000007C0003FFE00000003E0003FFE00000003E0003FFE00000003E000
+3FFE00000001E0003FFE00000001E0003FFE00000001E0003FFE00000001E0003FFE0000
+0000F0003FFE0001E000F0003FFE0001E000F0003FFE0001E000F0003FFE0001E0000000
+3FFE0001E00000003FFE0001E00000003FFE0003E00000003FFE0003E00000003FFE0003
+E00000003FFE0007E00000003FFE000FE00000003FFE007FE00000003FFFFFFFE0000000
+3FFFFFFFE00000003FFFFFFFE00000003FFFFFFFE00000003FFE007FE00000003FFE000F
+E00000003FFE0007E00000003FFE0003E00000003FFE0003E00000003FFE0003E0000000
+3FFE0001E00000003FFE0001E00000003FFE0001E00000003FFE0001E00000003FFE0001
+E00000003FFE0001E00000003FFE0000000000003FFE0000000000003FFE000000000000
+3FFE0000000000003FFE0000000000003FFE0000000000003FFE0000000000003FFE0000
+000000003FFE0000000000003FFE0000000000003FFE0000000000003FFE000000000000
+3FFE0000000000003FFE0000000000003FFE0000000000003FFE0000000000FFFFFFFFF0
+000000FFFFFFFFF0000000FFFFFFFFF0000000FFFFFFFFF00000003C447CC346>I<FFFF
+FFFFE0FFFFFFFFE0FFFFFFFFE0FFFFFFFFE0001FFF0000001FFF0000001FFF0000001FFF
+0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF00
+00001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000
+001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF000000
+1FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001F
+FF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF
+0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF00
+00001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000
+001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000FFFFFFFFE0FF
+FFFFFFE0FFFFFFFFE0FFFFFFFFE023447DC32A>73 D<FFFFFE0000000000007FFFFF80FF
+FFFF000000000000FFFFFF80FFFFFF000000000000FFFFFF80FFFFFF800000000001FFFF
+FF80003FFF800000000001FFFE0000003FFF800000000001FFFE0000003DFFC000000000
+03DFFE0000003DFFC00000000003DFFE0000003CFFE000000000079FFE0000003CFFE000
+000000079FFE0000003C7FF0000000000F1FFE0000003C7FF0000000000F1FFE0000003C
+3FF8000000001E1FFE0000003C3FF8000000001E1FFE0000003C1FFC000000003C1FFE00
+00003C1FFC000000003C1FFE0000003C1FFC000000003C1FFE0000003C0FFE0000000078
+1FFE0000003C0FFE00000000781FFE0000003C07FF00000000F01FFE0000003C07FF0000
+0000F01FFE0000003C03FF80000001E01FFE0000003C03FF80000001E01FFE0000003C01
+FFC0000003C01FFE0000003C01FFC0000003C01FFE0000003C01FFC0000003C01FFE0000
+003C00FFE0000007801FFE0000003C00FFE0000007801FFE0000003C007FF000000F001F
+FE0000003C007FF000000F001FFE0000003C003FF800001E001FFE0000003C003FF80000
+1E001FFE0000003C001FFC00003C001FFE0000003C001FFC00003C001FFE0000003C001F
+FC00003C001FFE0000003C000FFE000078001FFE0000003C000FFE000078001FFE000000
+3C0007FF0000F0001FFE0000003C0007FF0000F0001FFE0000003C0003FF8001E0001FFE
+0000003C0003FF8001E0001FFE0000003C0001FFC003C0001FFE0000003C0001FFC003C0
+001FFE0000003C0000FFE00780001FFE0000003C0000FFE00780001FFE0000003C0000FF
+E00780001FFE0000003C00007FF00F00001FFE0000003C00007FF00F00001FFE0000003C
+00003FF81E00001FFE0000003C00003FF81E00001FFE0000003C00001FFC3C00001FFE00
+00003C00001FFC3C00001FFE0000003C00000FFE7800001FFE0000003C00000FFE780000
+1FFE0000003C00000FFE7800001FFE0000003C000007FFF000001FFE0000003C000007FF
+F000001FFE0000003C000003FFE000001FFE0000003C000003FFE000001FFE0000003C00
+0001FFC000001FFE0000003C000001FFC000001FFE0000003C000000FF8000001FFE0000
+003C000000FF8000001FFE000000FF000000FF8000001FFE0000FFFFFF00007F00007FFF
+FFFF80FFFFFF00007F00007FFFFFFF80FFFFFF00003E00007FFFFFFF80FFFFFF00001C00
+007FFFFFFF8061447CC36A>77 D<00000007FFC0000000000000FFFFFE000000000007FF
+FFFFC0000000001FFE00FFF0000000007FF0001FFC00000001FFC00007FF00000007FF00
+0001FFC000000FFE000000FFE000001FFC0000007FF000003FF80000003FF800007FF000
+00001FFC0000FFE00000000FFE0001FFC000000007FF0003FFC000000007FF8003FF8000
+000003FF8007FF8000000003FFC007FF0000000001FFC00FFF0000000001FFE00FFF0000
+000001FFE01FFE0000000000FFF01FFE0000000000FFF03FFE0000000000FFF83FFE0000
+000000FFF83FFE0000000000FFF87FFE0000000000FFFC7FFC00000000007FFC7FFC0000
+0000007FFC7FFC00000000007FFC7FFC00000000007FFCFFFC00000000007FFEFFFC0000
+0000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC0000
+0000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC0000
+0000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC00000000007FFE7FFC0000
+0000007FFC7FFE0000000000FFFC7FFE0000000000FFFC7FFE0000000000FFFC3FFE0000
+000000FFF83FFE0000000000FFF83FFE0000000000FFF81FFF0000000001FFF01FFF0000
+000001FFF01FFF0000000001FFF00FFF8000000003FFE00FFF8000000003FFE007FFC000
+000007FFC003FFC000000007FF8003FFE00000000FFF8001FFE00000000FFF0000FFF000
+00001FFE00007FF80000003FFC00003FFC0000007FF800001FFE000000FFF000000FFF00
+0001FFE0000007FFC00007FFC0000001FFF0001FFF00000000FFFE00FFFE000000003FFF
+FFFFF80000000007FFFFFFC00000000000FFFFFE00000000000007FFC000000047467AC4
+54>79 D<FFFFFFFFFFFF000000FFFFFFFFFFFFF00000FFFFFFFFFFFFFE0000FFFFFFFFFF
+FFFF8000001FFF00001FFFE000001FFF000001FFF000001FFF0000007FF800001FFF0000
+003FFC00001FFF0000001FFE00001FFF0000001FFF00001FFF0000000FFF80001FFF0000
+000FFF80001FFF00000007FFC0001FFF00000007FFC0001FFF00000007FFC0001FFF0000
+0007FFE0001FFF00000007FFE0001FFF00000007FFE0001FFF00000007FFE0001FFF0000
+0007FFE0001FFF00000007FFE0001FFF00000007FFE0001FFF00000007FFE0001FFF0000
+0007FFC0001FFF00000007FFC0001FFF00000007FFC0001FFF0000000FFF80001FFF0000
+000FFF80001FFF0000001FFF00001FFF0000001FFE00001FFF0000003FFC00001FFF0000
+00FFF800001FFF000001FFF000001FFF00001FFFC000001FFFFFFFFFFF0000001FFFFFFF
+FFFC0000001FFFFFFFFFC00000001FFF000000000000001FFF000000000000001FFF0000
+00000000001FFF000000000000001FFF000000000000001FFF000000000000001FFF0000
+00000000001FFF000000000000001FFF000000000000001FFF000000000000001FFF0000
+00000000001FFF000000000000001FFF000000000000001FFF000000000000001FFF0000
+00000000001FFF000000000000001FFF000000000000001FFF000000000000001FFF0000
+00000000001FFF000000000000001FFF000000000000001FFF000000000000001FFF0000
+00000000001FFF000000000000001FFF000000000000001FFF000000000000001FFF0000
+00000000FFFFFFFFE000000000FFFFFFFFE000000000FFFFFFFFE000000000FFFFFFFFE0
+0000000043447DC34D>I<FFFFFFFFFFF800000000FFFFFFFFFFFFC0000000FFFFFFFFFF
+FFF8000000FFFFFFFFFFFFFE000000001FFF00003FFF800000001FFF000007FFE0000000
+1FFF000001FFF00000001FFF0000007FF80000001FFF0000003FFC0000001FFF0000003F
+FE0000001FFF0000001FFF0000001FFF0000001FFF0000001FFF0000000FFF8000001FFF
+0000000FFF8000001FFF0000000FFFC000001FFF0000000FFFC000001FFF0000000FFFC0
+00001FFF0000000FFFC000001FFF0000000FFFC000001FFF0000000FFFC000001FFF0000
+000FFFC000001FFF0000000FFF8000001FFF0000000FFF8000001FFF0000001FFF800000
+1FFF0000001FFF0000001FFF0000001FFE0000001FFF0000003FFE0000001FFF0000003F
+FC0000001FFF0000007FF80000001FFF000001FFE00000001FFF000007FFC00000001FFF
+00007FFF000000001FFFFFFFFFF8000000001FFFFFFFFFC0000000001FFFFFFFFFE00000
+00001FFF0000FFF8000000001FFF00003FFC000000001FFF00000FFF000000001FFF0000
+07FF800000001FFF000003FFC00000001FFF000003FFE00000001FFF000001FFE0000000
+1FFF000001FFF00000001FFF000000FFF00000001FFF000000FFF80000001FFF000000FF
+F80000001FFF000000FFF80000001FFF000000FFF80000001FFF000000FFF80000001FFF
+000000FFF80000001FFF000000FFF80000001FFF000000FFFC0000001FFF000000FFFC00
+00001FFF000000FFFC0000001FFF000000FFFC0000001FFF000000FFFC0000001FFF0000
+00FFFC0000001FFF000000FFFC000F001FFF000000FFFC000F001FFF0000007FFE000F00
+1FFF0000007FFE000F001FFF0000003FFE001E001FFF0000003FFF001E001FFF0000001F
+FF003CFFFFFFFFE0000FFF803CFFFFFFFFE00007FFE0F8FFFFFFFFE00001FFFFF0FFFFFF
+FFE000003FFFE00000000000000003FF0050457DC354>82 D<0000FFE0000C000007FFFE
+001C00003FFFFF803C00007FFFFFE07C0001FF801FF0FC0003FC0003FDFC0007F800007F
+FC000FE000003FFC001FE000000FFC001FC0000007FC003FC0000003FC003F80000003FC
+007F80000001FC007F80000000FC007F80000000FC00FF80000000FC00FF800000007C00
+FF800000007C00FFC00000007C00FFC00000003C00FFE00000003C00FFE00000003C00FF
+F00000003C00FFFC00000000007FFF00000000007FFFE0000000007FFFFE000000003FFF
+FFF00000003FFFFFFF0000001FFFFFFFE000000FFFFFFFFC000007FFFFFFFE000003FFFF
+FFFF800001FFFFFFFFC00000FFFFFFFFE000007FFFFFFFF000001FFFFFFFF8000007FFFF
+FFF8000000FFFFFFFC0000000FFFFFFE00000000FFFFFE0000000007FFFF00000000007F
+FF00000000001FFF00000000000FFF000000000007FF800000000003FF807000000003FF
+80F000000001FF80F000000001FF80F000000000FF80F000000000FF80F000000000FF80
+F800000000FF80F800000000FF00F800000000FF00FC00000000FF00FC00000000FE00FE
+00000001FE00FF00000001FC00FF80000003FC00FFC0000003F800FFF0000007F000FFFC
+00000FE000FEFF80003FC000FC3FF800FF8000F81FFFFFFF0000F007FFFFFC0000E000FF
+FFF00000C00007FF80000031467AC43E>I<3FFFFFFFFFFFFFFFE03FFFFFFFFFFFFFFFE0
+3FFFFFFFFFFFFFFFE03FFFFFFFFFFFFFFFE03FFE000FFF8003FFE03FF0000FFF80007FE0
+7FC0000FFF80001FF07F80000FFF80000FF07F00000FFF800007F07E00000FFF800003F0
+7C00000FFF800001F07C00000FFF800001F07C00000FFF800001F07800000FFF800000F0
+7800000FFF800000F07800000FFF800000F07800000FFF800000F0F800000FFF800000F8
+F000000FFF80000078F000000FFF80000078F000000FFF80000078F000000FFF80000078
+F000000FFF800000780000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000000
+0000000FFF800000000007FFFFFFFFFF00000007FFFFFFFFFF00000007FFFFFFFFFF0000
+0007FFFFFFFFFF000045437CC24E>I<FFFFFFFF80000FFFFFF8FFFFFFFF80000FFFFFF8
+FFFFFFFF80000FFFFFF8FFFFFFFF80000FFFFFF8003FFE000000000FF800003FFE000000
+0003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003F
+FE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003
+E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE00
+00000003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000
+003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE000000
+0003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003F
+FE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003
+E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE00
+00000003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000
+003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE000000
+0003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003E000003F
+FE0000000003E000003FFE0000000003E000003FFE0000000003E000003FFE0000000003
+E000003FFE0000000003E000001FFE0000000007C000001FFE0000000007C000001FFF00
+00000007C000000FFF0000000007C000000FFF000000000F80000007FF000000000F8000
+0007FF800000001F00000003FF800000001F00000001FFC00000003E00000001FFC00000
+007C00000000FFE0000000FC000000007FF8000003F8000000003FFC000007F000000000
+0FFF00003FC00000000003FFE003FF800000000001FFFFFFFE0000000000003FFFFFF800
+000000000007FFFFE0000000000000007FFE000000004D457CC356>I<FFFFFFFE007FFF
+FFFF0000FFFFFEFFFFFFFE007FFFFFFF0000FFFFFEFFFFFFFE007FFFFFFF0000FFFFFEFF
+FFFFFE007FFFFFFF0000FFFFFE007FFC0000003FFE00000001FF00007FFC0000003FFE00
+0000003C00007FFE0000003FFF000000007C00003FFE0000001FFF000000007800003FFF
+0000001FFF000000007800003FFF0000001FFF80000000F800001FFF0000000FFF800000
+00F000001FFF8000000FFFC0000001F000000FFF80000007FFC0000001E000000FFF8000
+0007FFC0000001E000000FFFC0000007FFE0000003E0000007FFC0000007FFE0000003C0
+000007FFE0000007FFE0000003C0000007FFE000000FFFF0000007C0000003FFE000000F
+FFF000000780000003FFF000000FFFF800000F80000001FFF000001EFFF800000F000000
+01FFF000001EFFF800000F00000001FFF800003EFFFC00001F00000000FFF800003C7FFC
+00001E00000000FFFC00003C7FFC00001E000000007FFC00007C7FFE00003C000000007F
+FC0000783FFE00003C000000007FFE0000783FFF00007C000000003FFE0000F01FFF0000
+78000000003FFE0000F01FFF000078000000003FFF0001F01FFF8000F8000000001FFF00
+01E00FFF8000F0000000001FFF8001E00FFF8000F0000000000FFF8003E00FFFC001E000
+0000000FFF8003C007FFC001E0000000000FFFC003C007FFE003E00000000007FFC00780
+03FFE003C00000000007FFC0078003FFE003C00000000007FFE00F8003FFF007C0000000
+0003FFE00F0001FFF007800000000003FFF00F0001FFF007800000000001FFF01F0001FF
+F80F000000000001FFF01E0000FFF80F000000000001FFF81E0000FFFC1F000000000000
+FFF83C00007FFC1E000000000000FFF83C00007FFC1E000000000000FFFC7C00007FFE3E
+0000000000007FFC7800003FFE3C0000000000007FFE7800003FFF3C0000000000003FFE
+F800003FFF780000000000003FFEF000001FFF780000000000003FFFF000001FFFF80000
+000000001FFFE000000FFFF00000000000001FFFE000000FFFF00000000000001FFFE000
+000FFFF00000000000000FFFC0000007FFE00000000000000FFFC0000007FFE000000000
+000007FFC0000007FFC000000000000007FF80000003FFC000000000000007FF80000003
+FFC000000000000003FF00000001FF8000000000000003FF00000001FF80000000000000
+03FF00000001FF8000000000000001FE00000000FF0000000000000001FE00000000FF00
+00000000000000FC000000007E0000000000000000FC000000007E0000000000000000FC
+000000007E000000000000000078000000003C000000006F457EC374>87
+D<0007FFF0000000007FFFFF00000001FFFFFFC0000003FC007FF0000007FE001FF80000
+07FE000FFC00000FFF0007FE00000FFF0003FF00000FFF0003FF80000FFF0003FF800007
+FE0001FF800007FE0001FFC00003FC0001FFC00000F00001FFC00000000001FFC0000000
+0001FFC00000000001FFC00000000001FFC0000000000FFFC00000003FFFFFC0000003FF
+FFFFC000001FFF01FFC000007FF001FFC00001FFC001FFC00007FF0001FFC0000FFE0001
+FFC0001FFC0001FFC0003FF80001FFC0003FF00001FFC0007FF00001FFC0007FE00001FF
+C000FFE00001FFC000FFE00001FFC000FFE00001FFC000FFE00003FFC000FFE00003FFC0
+007FF00007FFC0007FF00006FFC0003FF8000CFFC0001FFC0038FFF0000FFF80F07FFFC0
+03FFFFE07FFFC000FFFF801FFFC0000FFE0007FFC0322C7DAB36>97
+D<007FC000000000FFFFC000000000FFFFC000000000FFFFC000000000FFFFC000000000
+03FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001
+FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FF
+C00000000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC0
+0000000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC01F
+F8000001FFC1FFFF000001FFC7FFFFE00001FFCFC03FF00001FFFF000FFC0001FFFC0003
+FE0001FFF00001FF0001FFE00000FF8001FFC00000FFC001FFC000007FC001FFC000007F
+E001FFC000007FF001FFC000007FF001FFC000003FF801FFC000003FF801FFC000003FF8
+01FFC000003FF801FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01
+FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01FF
+C000003FFC01FFC000003FF801FFC000003FF801FFC000003FF801FFC000003FF001FFC0
+00007FF001FFC000007FE001FFC000007FE001FFC00000FFC001FFC00000FF8001FFE000
+01FF8001FFF00001FF0001FF780007FE0001FE3E000FF80001FC0FC07FF00001F807FFFF
+C00001F001FFFF000001E0003FF0000036457DC43E>I<00003FFF00000003FFFFF00000
+0FFFFFFC00003FF001FE00007FC003FF0001FF0003FF0003FE0007FF8007FE0007FF800F
+FC0007FF800FFC0007FF801FF80003FF001FF80003FF003FF80001FE003FF8000078007F
+F0000000007FF0000000007FF000000000FFF000000000FFF000000000FFF000000000FF
+F000000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000000FF
+F0000000007FF0000000007FF0000000007FF8000000003FF8000000003FF8000000001F
+F8000003C01FFC000003C00FFC000007800FFE0000078007FE00000F0003FF00001E0001
+FF80003C00007FE000F800003FF807F000000FFFFFE0000003FFFF800000003FF800002A
+2C7CAB32>I<0000000003FE0000000007FFFE0000000007FFFE0000000007FFFE000000
+0007FFFE00000000001FFE00000000000FFE00000000000FFE00000000000FFE00000000
+000FFE00000000000FFE00000000000FFE00000000000FFE00000000000FFE0000000000
+0FFE00000000000FFE00000000000FFE00000000000FFE00000000000FFE00000000000F
+FE00000000000FFE00000000000FFE00000000000FFE00000000000FFE00000000000FFE
+0000003FF00FFE000003FFFE0FFE00000FFFFF8FFE00003FF807EFFE00007FC001FFFE00
+01FF80007FFE0003FE00003FFE0007FE00001FFE0007FC00000FFE000FFC00000FFE001F
+F800000FFE001FF800000FFE003FF800000FFE003FF000000FFE007FF000000FFE007FF0
+00000FFE007FF000000FFE00FFF000000FFE00FFF000000FFE00FFF000000FFE00FFF000
+000FFE00FFF000000FFE00FFF000000FFE00FFF000000FFE00FFF000000FFE00FFF00000
+0FFE00FFF000000FFE007FF000000FFE007FF000000FFE007FF000000FFE007FF000000F
+FE003FF800000FFE003FF800000FFE001FF800000FFE000FF800000FFE000FFC00001FFE
+0007FC00003FFE0003FE00007FFE0001FF0000FFFE0000FFC003EFFF00003FF01FCFFFFC
+001FFFFF0FFFFC0003FFFC0FFFFC00007FE00FFFFC36457CC43E>I<00003FF800000003
+FFFF8000000FFFFFE000003FF01FF80000FFC007FC0001FF0001FE0003FE0001FF0007FE
+0000FF800FFC00007F800FFC00007FC01FF800003FC01FF800003FE03FF800003FE03FF0
+00003FE07FF000003FE07FF000001FF07FF000001FF0FFF000001FF0FFF000001FF0FFFF
+FFFFFFF0FFFFFFFFFFF0FFFFFFFFFFF0FFF000000000FFF000000000FFF000000000FFF0
+00000000FFF0000000007FF0000000007FF0000000007FF0000000003FF8000000003FF8
+000000001FF8000000F01FF8000000F00FFC000000F007FC000001E007FE000003E003FF
+000007C000FF80000F80007FE0003F00001FF803FC000007FFFFF8000001FFFFC0000000
+1FFE00002C2C7DAB33>I<000001FF0000001FFFC00000FFFFF00001FF83F80007FE07FC
+000FFC0FFC001FF81FFE003FF01FFE003FF01FFE007FF01FFE007FE01FFE00FFE00FFC00
+FFE007F800FFE003F000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FF
+E0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE00000FFFFFFF800FFFFFF
+F800FFFFFFF800FFFFFFF80000FFE0000000FFE0000000FFE0000000FFE0000000FFE000
+0000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE00000
+00FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000
+FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FF
+E0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0
+000000FFE0000000FFE000007FFFFFE0007FFFFFE0007FFFFFE0007FFFFFE00027457DC4
+22>I<00000000007E000000FFE001FF00000FFFFE07FF80003FFFFF8F9F8000FFC07FFC
+3FC001FF001FF03FC003FE000FF83FC007FC0007FC3FC00FFC0007FE1F800FF80003FE0F
+001FF80003FF00001FF80003FF00003FF80003FF80003FF80003FF80003FF80003FF8000
+3FF80003FF80003FF80003FF80003FF80003FF80003FF80003FF80001FF80003FF00001F
+F80003FF00000FF80003FE00000FFC0007FE000007FC0007FC000003FE000FF8000001FF
+001FF0000000FFC07FE0000001BFFFFF800000038FFFFE0000000700FFE0000000070000
+00000000070000000000000F8000000000000F8000000000000F8000000000000FC00000
+0000000FF0000000000007FFFFFFC0000007FFFFFFFE000007FFFFFFFF800003FFFFFFFF
+E00003FFFFFFFFF00001FFFFFFFFF80000FFFFFFFFFC0001FFFFFFFFFE0007FFFFFFFFFE
+000FF000003FFF001FC0000007FF003F80000001FF807F80000000FF80FF000000007F80
+FF000000007F80FF000000007F80FF000000007F80FF000000007F807F80000000FF007F
+80000000FF003FC0000001FE001FE0000003FC000FF0000007F80007FE00003FF00001FF
+C001FFC000007FFFFFFF0000000FFFFFF800000000FFFF80000032417DAC38>I<007FC0
+00000000FFFFC000000000FFFFC000000000FFFFC000000000FFFFC00000000003FFC000
+00000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC00000
+000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC0000000
+0001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC000000000
+01FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC007FE000001
+FFC03FFFC00001FFC07FFFE00001FFC1F03FF00001FFC3C00FF80001FFC7000FFC0001FF
+CE000FFE0001FFDC0007FE0001FFD80007FE0001FFF00007FF0001FFF00007FF0001FFE0
+0007FF0001FFE00007FF0001FFE00007FF0001FFC00007FF0001FFC00007FF0001FFC000
+07FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007
+FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF
+0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF00
+01FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001
+FFC00007FF0001FFC00007FF0001FFC00007FF00FFFFFF83FFFFFEFFFFFF83FFFFFEFFFF
+FF83FFFFFEFFFFFF83FFFFFE37457CC43E>I<00780001FE0003FF0007FF8007FF800FFF
+C00FFFC00FFFC00FFFC007FF8007FF8003FF0001FE000078000000000000000000000000
+00000000000000000000000000000000000000000000000000007FC07FFFC07FFFC07FFF
+C07FFFC003FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FF
+C001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FF
+C001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FFC001FF
+C0FFFFFFFFFFFFFFFFFFFFFFFF18467CC520>I<007FC000FFFFC000FFFFC000FFFFC000
+FFFFC00003FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000
+01FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000
+01FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000
+01FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000
+01FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000
+01FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000
+01FFC00001FFC00001FFC00001FFC00001FFC00001FFC00001FFC000FFFFFF80FFFFFF80
+FFFFFF80FFFFFF8019457CC420>108 D<007F8007FF00000FFE0000FFFF801FFFC0003F
+FF8000FFFF807FFFF000FFFFE000FFFF81F81FF803F03FF000FFFF83C00FFC07801FF800
+03FF870007FE0E000FFC0001FF8E0007FF1C000FFE0001FF9C0003FF380007FE0001FF98
+0003FF300007FE0001FFB00003FFE00007FF0001FFB00003FFE00007FF0001FFE00003FF
+C00007FF0001FFE00003FFC00007FF0001FFE00003FFC00007FF0001FFC00003FF800007
+FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001
+FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC000
+03FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF80
+0007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF
+0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FF
+C00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003
+FF800007FF0001FFC00003FF800007FF0001FFC00003FF800007FF0001FFC00003FF8000
+07FF0001FFC00003FF800007FF0001FFC00003FF800007FF00FFFFFF81FFFFFF03FFFFFE
+FFFFFF81FFFFFF03FFFFFEFFFFFF81FFFFFF03FFFFFEFFFFFF81FFFFFF03FFFFFE572C7C
+AB5E>I<007F8007FE0000FFFF803FFFC000FFFF807FFFE000FFFF81F03FF000FFFF83C0
+0FF80003FF87000FFC0001FF8E000FFE0001FF9C0007FE0001FF980007FE0001FFB00007
+FF0001FFB00007FF0001FFE00007FF0001FFE00007FF0001FFE00007FF0001FFC00007FF
+0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF00
+01FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001
+FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FF
+C00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC0
+0007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF00FFFFFF83
+FFFFFEFFFFFF83FFFFFEFFFFFF83FFFFFEFFFFFF83FFFFFE372C7CAB3E>I<00001FFC00
+00000001FFFFC00000000FFFFFF80000003FF80FFE0000007FC001FF000001FF00007FC0
+0003FE00003FE00007FC00001FF0000FFC00001FF8000FF800000FF8001FF800000FFC00
+1FF800000FFC003FF800000FFE003FF0000007FE007FF0000007FF007FF0000007FF007F
+F0000007FF00FFF0000007FF80FFF0000007FF80FFF0000007FF80FFF0000007FF80FFF0
+000007FF80FFF0000007FF80FFF0000007FF80FFF0000007FF80FFF0000007FF80FFF000
+0007FF807FF0000007FF007FF0000007FF007FF0000007FF007FF0000007FF003FF80000
+0FFE003FF800000FFE001FF800000FFC000FFC00001FF8000FFC00001FF80007FE00003F
+F00003FF00007FE00001FF8000FFC00000FFC001FF8000003FF80FFE0000000FFFFFF800
+000001FFFFC0000000001FFC000000312C7DAB38>I<007FC01FF80000FFFFC1FFFF0000
+FFFFC7FFFFE000FFFFCFC03FF000FFFFFF000FFC0003FFFC0007FE0001FFF00003FF0001
+FFE00001FF8001FFC00001FFC001FFC00000FFC001FFC00000FFE001FFC000007FF001FF
+C000007FF001FFC000007FF801FFC000007FF801FFC000003FF801FFC000003FF801FFC0
+00003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC000
+003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC000003FFC01FFC00000
+3FF801FFC000007FF801FFC000007FF801FFC000007FF001FFC000007FF001FFC00000FF
+E001FFC00000FFE001FFC00001FFC001FFC00001FF8001FFE00003FF8001FFF00003FF00
+01FFF8000FFE0001FFFE001FF80001FFCFC07FF00001FFC7FFFFC00001FFC1FFFF000001
+FFC03FF0000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FF
+C00000000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC0
+0000000001FFC00000000001FFC00000000001FFC00000000001FFC00000000001FFC000
+000000FFFFFF80000000FFFFFF80000000FFFFFF80000000FFFFFF80000000363F7DAB3E
+>I<00003FF0001E000003FFFC003E00000FFFFF007E00003FF80F80FE00007FE003E0FE
+0000FFC000F1FE0003FF00007BFE0007FF00003BFE0007FE00003FFE000FFE00001FFE00
+1FFC00001FFE001FFC00000FFE003FF800000FFE003FF800000FFE007FF800000FFE007F
+F800000FFE007FF000000FFE00FFF000000FFE00FFF000000FFE00FFF000000FFE00FFF0
+00000FFE00FFF000000FFE00FFF000000FFE00FFF000000FFE00FFF000000FFE00FFF000
+000FFE00FFF000000FFE007FF000000FFE007FF000000FFE007FF800000FFE003FF80000
+0FFE003FF800000FFE003FF800000FFE001FFC00000FFE000FFC00001FFE000FFE00001F
+FE0007FE00003FFE0003FF00007FFE0001FF8000FFFE0000FFC003EFFE00003FF01F8FFE
+00001FFFFF0FFE000003FFFC0FFE0000007FE00FFE00000000000FFE00000000000FFE00
+000000000FFE00000000000FFE00000000000FFE00000000000FFE00000000000FFE0000
+0000000FFE00000000000FFE00000000000FFE00000000000FFE00000000000FFE000000
+00000FFE00000000000FFE00000000000FFE0000000007FFFFFC00000007FFFFFC000000
+07FFFFFC00000007FFFFFC363F7CAB3B>I<007F807F00FFFF81FFC0FFFF83FFF0FFFF87
+87F8FFFF8E0FFC03FF8C0FFC01FF9C1FFE01FF981FFE01FFB01FFE01FFB01FFE01FFF00F
+FC01FFE00FFC01FFE007F801FFE001E001FFE0000001FFC0000001FFC0000001FFC00000
+01FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001
+FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FF
+C0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0000001FFC0
+0000FFFFFFE000FFFFFFE000FFFFFFE000FFFFFFE000272C7DAB2E>I<001FFE038000FF
+FFCF8003FFFFFF800FF003FF801F80007F801F00003F803F00001F807E00000F807E0000
+0F80FE00000780FE00000780FF00000780FF00000780FFC0000000FFF0000000FFFF8000
+007FFFFC00007FFFFF80003FFFFFE0001FFFFFF8000FFFFFFC0007FFFFFE0003FFFFFF00
+00FFFFFF80003FFFFFC00001FFFFC000000FFFC0000000FFE07000007FE0F000001FE0F0
+00001FE0F800000FE0F800000FE0F800000FE0FC00000FC0FE00000FC0FE00000F80FF00
+001F80FF80001F00FFE0007E00FFF801FC00F8FFFFF800F03FFFE000E007FE0000232C7C
+AB2C>I<0001E000000001E000000001E000000001E000000001E000000003E000000003
+E000000003E000000003E000000007E000000007E00000000FE00000000FE00000001FE0
+0000001FE00000003FE00000007FE0000000FFE0000003FFE000000FFFFFFF80FFFFFFFF
+80FFFFFFFF80FFFFFFFF8000FFE0000000FFE0000000FFE0000000FFE0000000FFE00000
+00FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000
+FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FFE0000000FF
+E0000000FFE0000000FFE0000000FFE001E000FFE001E000FFE001E000FFE001E000FFE0
+01E000FFE001E000FFE001E000FFE001E000FFE001E000FFE001E0007FE003C0007FF003
+C0003FF00780001FF80700000FFC1F000007FFFE000001FFF80000003FE000233F7EBE2C
+>I<007FC00001FF00FFFFC003FFFF00FFFFC003FFFF00FFFFC003FFFF00FFFFC003FFFF
+0003FFC0000FFF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF00
+01FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001
+FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FF
+C00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC0
+0007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC00007FF0001FFC000
+07FF0001FFC00007FF0001FFC0000FFF0001FFC0000FFF0001FFC0000FFF0001FFC0001F
+FF0000FFC0001FFF0000FFC00037FF00007FE00067FF00003FE000C7FF80001FF80787FF
+FE000FFFFF07FFFE0003FFFE07FFFE00007FF807FFFE372C7CAB3E>I<FFFFFF0003FFFC
+FFFFFF0003FFFCFFFFFF0003FFFCFFFFFF0003FFFC01FFC000007F0001FFE000003E0000
+FFE000003C0000FFF000003C00007FF000007800007FF800007800007FF80000F800003F
+F80000F000003FFC0001F000001FFC0001E000001FFE0003E000000FFE0003C000000FFF
+0007C0000007FF000780000007FF800F80000003FF800F00000003FFC00F00000003FFC0
+1F00000001FFE01E00000001FFE03E00000000FFE03C00000000FFF07C000000007FF078
+000000007FF8F8000000003FF8F0000000003FFDF0000000001FFDE0000000001FFFE000
+0000000FFFC0000000000FFFC0000000000FFFC00000000007FF800000000007FF800000
+000003FF000000000003FF000000000001FE000000000001FE000000000000FC00000000
+0000FC00000000000078000000362C7EAB3B>I<FFFFFE003FFFF0FFFFFE003FFFF0FFFF
+FE003FFFF0FFFFFE003FFFF001FFE00007F80000FFF00003E000007FF80007C000003FF8
+000F8000001FFC001F0000001FFE003F0000000FFF007E00000007FF807C00000003FFC0
+F800000001FFC1F000000001FFE3E000000000FFF7C0000000007FFF80000000003FFF80
+000000001FFF00000000001FFE00000000000FFF000000000007FF800000000003FFC000
+00000003FFC00000000007FFE0000000000FFFF0000000000FFFF8000000001F3FFC0000
+00003E1FFC000000007C1FFE00000000F80FFF00000001F007FF80000003F003FFC00000
+07E001FFC0000007C001FFE000000F8000FFF000001F00007FF800003E00003FFC00007C
+00001FFC0001FE00000FFE00FFFFE000FFFFFCFFFFE000FFFFFCFFFFE000FFFFFCFFFFE0
+00FFFFFC362C7EAB3B>120 D<FFFFFF0003FFFCFFFFFF0003FFFCFFFFFF0003FFFCFFFF
+FF0003FFFC01FFC000007F0001FFE000003E0000FFE000003C0000FFF000003C00007FF0
+00007800007FF800007800007FF80000F800003FF80000F000003FFC0001F000001FFC00
+01E000001FFE0003E000000FFE0003C000000FFF0007C0000007FF000780000007FF800F
+80000003FF800F00000003FFC00F00000003FFC01F00000001FFE01E00000001FFE03E00
+000000FFE03C00000000FFF07C000000007FF078000000007FF8F8000000003FF8F00000
+00003FFDF0000000001FFDE0000000001FFFE0000000000FFFC0000000000FFFC0000000
+000FFFC00000000007FF800000000007FF800000000003FF000000000003FF0000000000
+01FE000000000001FE000000000000FC000000000000FC00000000000078000000000000
+78000000000000F8000000000000F0000000000001F0000000000001E00000001F0003E0
+0000003F8003C00000007FC007C0000000FFE00780000000FFE00F80000000FFE00F0000
+0000FFE01F00000000FFE03E000000007FC07C000000007FC0F8000000003F07F0000000
+001FFFC0000000000FFF800000000001FC0000000000363F7EAB3B>I
+E /Fk 8 117 df<0F003FC07FE07FE0FFF0FFF0FFF0FFF07FE07FE03FC00F000C0C7A8B
+19>46 D<0000000F000000000000001F800000000000001F800000000000003FC0000000
+0000003FC00000000000007FE00000000000007FE00000000000007FE0000000000000FF
+F0000000000000FFF0000000000001FFF8000000000001FFF8000000000003FFFC000000
+000003FFFC000000000003DFFC000000000007DFFE0000000000078FFE00000000000F8F
+FF00000000000F07FF00000000001F07FF80000000001E07FF80000000001E03FF800000
+00003E03FFC0000000003C01FFC0000000007C01FFE0000000007800FFE000000000F800
+FFF000000000F000FFF000000000F0007FF000000001F0007FF800000001E0003FF80000
+0003E0003FFC00000003C0001FFC00000007FFFFFFFE00000007FFFFFFFE00000007FFFF
+FFFE0000000FFFFFFFFF0000000F000007FF0000001F000007FF8000001E000003FF8000
+003E000003FFC000003C000003FFC000003C000001FFC000007C000001FFE00000780000
+00FFE00000F8000000FFF00000F00000007FF000FFFFE0003FFFFFF0FFFFE0003FFFFFF0
+FFFFE0003FFFFFF0FFFFE0003FFFFFF03C337DB243>65 D<007FFE000003FFFFE00007FF
+FFF8000FF00FFC001FF801FE001FF800FF001FF800FF801FF8007F801FF8007FC00FF000
+7FC007E0007FC00180007FC00000007FC0000007FFC00007FFFFC0007FFFFFC001FFC07F
+C007FE007FC01FF8007FC03FE0007FC07FC0007FC07FC0007FC0FF80007FC0FF80007FC0
+FF80007FC0FF80007FC0FF8000FFC07FC001FFC03FE003BFE01FF80F3FFF0FFFFE1FFF03
+FFF80FFF007FE003FF28217EA02B>97 D<01FC00000000FFFC00000000FFFC00000000FF
+FC00000000FFFC000000000FFC0000000007FC0000000007FC0000000007FC0000000007
+FC0000000007FC0000000007FC0000000007FC0000000007FC0000000007FC0000000007
+FC0000000007FC0000000007FC0000000007FC0000000007FC07FC000007FC7FFF800007
+FDFFFFE00007FFF00FF80007FFC003FC0007FF0001FE0007FC0000FF0007FC0000FF0007
+FC0000FF8007FC00007FC007FC00007FC007FC00007FC007FC00007FE007FC00007FE007
+FC00007FE007FC00007FE007FC00007FE007FC00007FE007FC00007FE007FC00007FE007
+FC00007FE007FC00007FC007FC00007FC007FC0000FF8007FC0000FF8007FC0000FF0007
+FE0001FE0007FF0001FE0007FFC007FC0007F3F01FF00007E0FFFFE00007C07FFF800007
+800FF800002B347EB331>I<0007FF8000003FFFF00000FFFFFC0001FE01FE0007F803FF
+000FF003FF001FF003FF001FE003FF003FE003FF003FE001FE007FC000FC007FC0003000
+FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FFC0000000FF
+C0000000FFC00000007FC00000007FE00000003FE00000003FE00007801FF00007801FF0
+000F000FF8000F0007FC003E0001FF80FC0000FFFFF000003FFFE0000007FF000021217D
+A027>I<01F80FC0FFF83FF0FFF87FF8FFF8F1FCFFF9C3FE0FF983FE07FB03FE07FB03FE
+07FE01FC07FE00F807FE002007FE000007FC000007FC000007FC000007FC000007FC0000
+07FC000007FC000007FC000007FC000007FC000007FC000007FC000007FC000007FC0000
+07FC000007FC000007FC0000FFFFF000FFFFF000FFFFF000FFFFF0001F217EA024>114
+D<00FFE1C007FFFFC00FFFFFC01F803FC03E000FC07C0007C07C0003C0FC0003C0FC0003
+C0FE0003C0FF800000FFFC00007FFFE0007FFFFC003FFFFE001FFFFF000FFFFF8003FFFF
+C000FFFFE0000FFFE000007FF000000FF0700007F0F00003F0F80003F0F80003F0FC0003
+E0FC0007E0FF0007C0FFC01F80FFFFFF00F1FFFC00E03FE0001C217DA023>I<003C0000
+003C0000003C0000003C0000003C0000007C0000007C0000007C000000FC000000FC0000
+01FC000001FC000003FC000007FC00001FFFFF80FFFFFF80FFFFFF80FFFFFF8007FC0000
+07FC000007FC000007FC000007FC000007FC000007FC000007FC000007FC000007FC0000
+07FC000007FC000007FC000007FC000007FC000007FC000007FC03C007FC03C007FC03C0
+07FC03C007FC03C007FC03C007FC03C003FC078003FE078001FF0F0000FFFE00003FFC00
+000FF0001A2F7EAE22>I E /Fl 64 123 df<00001FE0000001FFFC000007F01E00000F
+C00300001F000780003E000FC0007C001FC000FC001FC001F8001FC001F8000F8001F800
+070001F800000001F800000001F800000001F800000001F800000001F800000001F80000
+0001F800000001F8000000FFFFFFFFC0FFFFFFFFC001F8001FC001F8000FC001F8000FC0
+01F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001
+F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8
+000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F8000FC001F800
+0FC001F8000FC001F8000FC003FC001FE07FFFC1FFFF7FFFC1FFFF28347FB32B>12
+D<007800FC00FC01FC03FC07F807E00FC01F801F003C007800F00040000E0E71B326>19
+D<0000C00001C0000300000700000E00001C0000380000780000700000E00001E00001C0
+0003C0000780000780000F00000F00000F00001E00001E00001E00003E00003C00003C00
+007C00007C00007C00007C0000780000F80000F80000F80000F80000F80000F80000F800
+00F80000F80000F80000F80000F80000F80000F80000F80000F800007800007C00007C00
+007C00007C00003C00003C00003E00001E00001E00001E00000F00000F00000F00000780
+0007800003C00001C00001E00000E000007000007800003800001C00000E000007000003
+000001C00000C0124A79B71E>40 D<800000C000006000007000003800001C00000E0000
+0F000007000003800003C00001C00001E00000F00000F000007800007800007800003C00
+003C00003C00003E00001E00001E00001F00001F00001F00001F00000F00000F80000F80
+000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80000F80
+000F80000F80000F00001F00001F00001F00001F00001E00001E00003E00003C00003C00
+003C0000780000780000780000F00000F00001E00001C00003C0000380000700000F0000
+0E00001C0000380000700000600000C00000800000114A7BB71E>I<3C007E00FF00FF00
+FF80FF807F803D8001800180018001800300030003000600060006000C00180030007000
+200009177A8715>44 D<FFFFF0FFFFF0FFFFF0FFFFF0FFFFF014057F921A>I<3C7EFFFF
+FFFF7E3C08087A8715>I<000000300000007800000078000000F8000000F0000000F000
+0001F0000001E0000001E0000003E0000003C0000007C0000007800000078000000F8000
+000F0000000F0000001F0000001E0000001E0000003E0000003C0000003C0000007C0000
+007800000078000000F8000000F0000001F0000001E0000001E0000003E0000003C00000
+03C0000007C0000007800000078000000F8000000F0000000F0000001F0000001E000000
+1E0000003E0000003C0000003C0000007C00000078000000F8000000F0000000F0000001
+F0000001E0000001E0000003E0000003C0000003C0000007C0000007800000078000000F
+8000000F0000000F0000001F0000001E0000003E0000003C0000003C0000007C00000078
+00000078000000F8000000F0000000F0000000600000001D4B7CB726>I<000FE000007F
+FC0000F83E0003E00F8007C007C00F8003E00F0001E01F0001F01E0000F03E0000F83E00
+00F83E0000F87C00007C7C00007C7C00007C7C00007C7C00007CFC00007EFC00007EFC00
+007EFC00007EFC00007EFC00007EFC00007EFC00007EFC00007EFC00007EFC00007EFC00
+007EFC00007EFC00007EFC00007EFC00007EFC00007E7C00007C7C00007C7C00007C7E00
+00FC3E0000F83E0000F83E0000F81E0000F01F0001F00F0001E00F8003E007C007C003E0
+0F8001F83F00007FFC00000FE0001F327DB026>I<00070000000F0000001F0000007F00
+0007FF0000FFBF0000F83F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F00
+00003F0000003F0000003F0000003F0000003F0000003F000000FFC0007FFFFF807FFFFF
+8019317AB026>I<003FC00001FFF80003C07C0006003F000C000F8018000FC0300007E0
+600007E0600007F07C0003F0FE0003F8FF0003F8FF0003F8FF0003F8FF0003F87E0003F8
+3C0003F8000003F8000003F0000007F0000007E0000007E000000FC000000FC000001F80
+00001F0000003E0000007C000000F8000000F0000001E0000003C00000078000000F0000
+000E0000001C0000003800180070001800E0001801C00030038000300300003006000070
+0FFFFFF01FFFFFF03FFFFFF07FFFFFE0FFFFFFE0FFFFFFE01D317CB026>I<001FE00000
+FFFC0003E03F0007000F800C0007C0180007E01F0003F03F8003F83F8003F83FC003F83F
+8003F81F8003F80F0003F8000003F0000007F0000007F0000007E000000FC000000F8000
+001F0000003E000001F800007FE000007FFC0000003F0000000F80000007C0000007E000
+0003F0000003F8000003FC000001FC000001FC000001FE000001FE3C0001FE7E0001FEFF
+0001FEFF0001FEFF0001FCFE0001FCFC0003FC780003F8300003F0300007E01C0007C00F
+000F8003E03F0000FFFC00001FE0001F327DB026>I<000001C000000001C000000003C0
+00000007C00000000FC00000000FC00000001FC00000003FC00000003FC00000006FC000
+0000EFC0000000CFC00000018FC00000038FC00000030FC00000060FC000000E0FC00000
+1C0FC00000180FC00000300FC00000700FC00000600FC00000C00FC00001C00FC0000180
+0FC00003000FC00007000FC00006000FC0000C000FC0001C000FC00038000FC00030000F
+C00060000FC000E0000FC000FFFFFFFF80FFFFFFFF8000000FC00000000FC00000000FC0
+0000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC000
+00001FE0000007FFFF800007FFFF8021317EB026>I<000FF000007FFC0000F01F000380
+0780070001C00E0001E00E0000F01C0000F01C0000783C0000783C0000783C0000783E00
+00783E0000783F0000F01FC000F01FE001E01FF801C00FFE038007FF0F0003FFDE0001FF
+F80000FFF800003FFC00003FFF0000F7FF8001C1FFC00780FFE00F003FF01E001FF81C00
+07FC3C0003FC780000FC7800007EF000003EF000003EF000001EF000001EF000001EF000
+001EF000001C7800001C780000383C0000301E0000700F0000E00780038003F01F0000FF
+FC00001FF0001F327DB026>56 D<000FE000007FFC0000F83E0003E00F0007C007800F80
+03C01F0003E01F0001E03F0001F07E0001F07E0001F87E0001F8FE0000FCFE0000FCFE00
+00FCFE0000FCFE0000FCFE0000FEFE0000FEFE0000FE7E0000FE7E0001FE7E0001FE3F00
+01FE3F0001FE1F0003FE0F8003FE078006FE03C00CFE01F038FE007FF0FE001FC0FC0000
+00FC000000FC000000FC000001F8000001F8000001F0000001F01F0003E03F8003E03F80
+07C03F8007803F800F803F000F001C001E000C007C000701F00003FFE00000FF00001F32
+7DB026>I<3C7EFFFFFFFF7E3C000000000000000000000000000000003C7EFFFFFFFF7E
+3C08207A9F15>I<3C7EFFFFFFFF7E3C000000000000000000000000000000003C7EFEFF
+FFFF7F3F03030303030606060C0C1818306020082F7A9F15>I<000000E0000000000000
+E0000000000000E0000000000001F0000000000001F0000000000003F8000000000003F8
+000000000003F8000000000007FC000000000007FC000000000007FC00000000000CFE00
+000000000CFE00000000001CFF0000000000187F0000000000187F0000000000307F8000
+000000303F8000000000303F8000000000601FC000000000601FC000000000E01FE00000
+0000C00FE000000000C00FE000000001800FF0000000018007F0000000018007F0000000
+030003F8000000030003F8000000070003FC000000060001FC000000060001FC0000000E
+0001FE0000000FFFFFFE0000000FFFFFFE0000001800007F0000001800007F0000001800
+007F0000003000003F8000003000003F8000007000003FC000006000001FC00000600000
+1FC00000C000001FE00000C000000FE00000C000000FE00001C0000007F00003C0000007
+F00007E0000007F8001FF000001FFC00FFFE0001FFFFE0FFFE0001FFFFE033347DB33A>
+65 D<FFFFFFFF0000FFFFFFFFE00003FE0003F80001FC0000FE0001FC00007F0001FC00
+003F8001FC00001FC001FC00001FE001FC00000FE001FC00000FE001FC00000FF001FC00
+000FF001FC00000FF001FC00000FF001FC00000FF001FC00000FF001FC00000FE001FC00
+001FE001FC00001FC001FC00003F8001FC00007F0001FC0000FE0001FC0003FC0001FFFF
+FFF00001FFFFFFE00001FC0007F80001FC0000FE0001FC00003F8001FC00001FC001FC00
+000FE001FC00000FF001FC000007F001FC000007F801FC000003F801FC000003FC01FC00
+0003FC01FC000003FC01FC000003FC01FC000003FC01FC000003FC01FC000003FC01FC00
+0007F801FC000007F801FC000007F001FC00000FE001FC00001FE001FC00003FC001FC00
+007F0003FE0003FE00FFFFFFFFF800FFFFFFFFC0002E337DB236>I<000003FE000C0000
+3FFF800C0000FC01E01C0003F000783C000FC0001C7C001F0000067C003E000003FC00FC
+000001FC01F8000000FC01F0000000FC03F00000007C07E00000003C0FE00000003C0FC0
+0000003C1FC00000001C3F800000001C3F800000001C3F800000000C7F800000000C7F80
+0000000C7F000000000CFF0000000000FF0000000000FF0000000000FF0000000000FF00
+00000000FF0000000000FF0000000000FF0000000000FF0000000000FF0000000000FF00
+000000007F00000000007F800000000C7F800000000C3F800000000C3F800000000C3F80
+0000000C1FC0000000180FC0000000180FE00000001807E00000003003F00000003001F0
+0000006001F80000006000FC000000C0003E00000180001F00000700000FC0000E000003
+F00038000000FC01F00000003FFFC000000003FE00002E357CB337>I<FFFFFFFF800000
+FFFFFFFFF0000001FF0001FE000000FE00003F000000FE00001FC00000FE000007E00000
+FE000003F00000FE000001F80000FE000000FC0000FE0000007E0000FE0000007E0000FE
+0000003F0000FE0000003F8000FE0000001F8000FE0000001FC000FE0000001FC000FE00
+00001FC000FE0000000FE000FE0000000FE000FE0000000FE000FE0000000FE000FE0000
+000FF000FE0000000FF000FE0000000FF000FE0000000FF000FE0000000FF000FE000000
+0FF000FE0000000FF000FE0000000FF000FE0000000FF000FE0000000FF000FE0000000F
+E000FE0000000FE000FE0000000FE000FE0000000FE000FE0000001FC000FE0000001FC0
+00FE0000001F8000FE0000003F8000FE0000003F0000FE0000007F0000FE0000007E0000
+FE000000FC0000FE000001F80000FE000003F00000FE000007E00000FE00000FC00000FE
+00003F800001FF0001FE0000FFFFFFFFF80000FFFFFFFF80000034337EB23B>I<FFFFFF
+FFFFC0FFFFFFFFFFC003FE00007FC001FC00000FC001FC000003E001FC000001E001FC00
+0001E001FC000000E001FC000000E001FC0000006001FC0000006001FC0000006001FC00
+00006001FC0000003001FC0000003001FC0006003001FC0006003001FC0006000001FC00
+06000001FC0006000001FC000E000001FC000E000001FC001E000001FC007E000001FFFF
+FE000001FFFFFE000001FC007E000001FC001E000001FC000E000001FC000E000001FC00
+06000001FC0006000001FC0006000C01FC0006000C01FC0006000C01FC0000001801FC00
+00001801FC0000001801FC0000001801FC0000003801FC0000003801FC0000003001FC00
+00007001FC0000007001FC000000F001FC000001F001FC000003F001FC00000FF003FE00
+007FE0FFFFFFFFFFE0FFFFFFFFFFE02E337DB234>I<FFFFFFFFFF80FFFFFFFFFF8003FE
+0000FF8001FC00001F8001FC000007C001FC000003C001FC000003C001FC000001C001FC
+000001C001FC000000C001FC000000C001FC000000C001FC000000C001FC0000006001FC
+0000006001FC000C006001FC000C006001FC000C000001FC000C000001FC000C000001FC
+001C000001FC001C000001FC003C000001FC00FC000001FFFFFC000001FFFFFC000001FC
+00FC000001FC003C000001FC001C000001FC001C000001FC000C000001FC000C000001FC
+000C000001FC000C000001FC000C000001FC0000000001FC0000000001FC0000000001FC
+0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC
+0000000001FC0000000001FC0000000001FC0000000003FF00000000FFFFFE000000FFFF
+FE0000002B337DB232>I<000003FE000C0000003FFF800C000000FC01E01C000003F000
+783C00000FC0001C7C00001F0000067C00003E000003FC0000FC000001FC0001F8000000
+FC0001F0000000FC0003F00000007C0007E00000003C000FE00000003C000FC00000003C
+001FC00000001C003F800000001C003F800000001C003F800000000C007F800000000C00
+7F800000000C007F000000000C00FF000000000000FF000000000000FF000000000000FF
+000000000000FF000000000000FF000000000000FF000000000000FF000000000000FF00
+0000000000FF000000000000FF000003FFFFE07F000003FFFFE07F80000007FE007F8000
+0001FC003F80000001FC003F80000001FC003F80000001FC001FC0000001FC000FC00000
+01FC000FE0000001FC0007E0000001FC0003F0000001FC0001F0000001FC0001F8000001
+FC0000FC000001FC00003E000003FC00001F0000067C00000FC0000C7C000003F000383C
+000000FC01F01C0000003FFFC00C00000003FE00000033357CB33C>I<FFFFFEFFFFFE01
+FF0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000
+FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000
+FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000
+FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0001FF00FFFFFEFF
+FFFE17337EB21C>73 D<007FFFFF007FFFFF00007FE000001FC000001FC000001FC00000
+1FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC00000
+1FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC00000
+1FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC00000
+1FC000001FC000001FC000001FC000001FC000001FC03C001FC07E001FC0FF001FC0FF00
+1FC0FF001F80FE003F807C003F0060007F0030007E001C00FC000F03F00003FFE00000FF
+000020347DB227>I<FFFFFE0007FFF8FFFFFE0007FFF801FF000001FF8000FE000000FE
+0000FE000000780000FE000000E00000FE000000C00000FE000001800000FE0000030000
+00FE000006000000FE00000C000000FE000018000000FE000030000000FE0000E0000000
+FE0001C0000000FE000300000000FE000600000000FE000C00000000FE001800000000FE
+003000000000FE007800000000FE00F800000000FE01FC00000000FE03FE00000000FE06
+FE00000000FE0C7F00000000FE383F80000000FE703F80000000FEC01FC0000000FF800F
+E0000000FF000FF0000000FE0007F0000000FE0003F8000000FE0003FC000000FE0001FC
+000000FE0000FE000000FE0000FF000000FE00007F000000FE00003F800000FE00001FC0
+0000FE00001FC00000FE00000FE00000FE000007F00000FE000007F80000FE000003F800
+00FE000003FC0000FE000001FE0000FE000001FF0001FF000003FF80FFFFFE003FFFFCFF
+FFFE003FFFFC36337EB23C>I<FFFFFE000000FFFFFE00000003FF0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000018001FC000001
+8001FC0000018001FC0000018001FC0000038001FC0000030001FC0000030001FC000003
+0001FC0000070001FC0000070001FC0000070001FC00000F0001FC00001F0001FC00003F
+0001FC00007E0001FC0001FE0003FE0007FE00FFFFFFFFFE00FFFFFFFFFE0029337DB230
+>I<FFFC00000001FFF8FFFE00000003FFF803FE00000003FE0001FE00000003FC0001BF
+00000006FC0001BF00000006FC0001BF00000006FC00019F8000000CFC00019F8000000C
+FC00018FC0000018FC00018FC0000018FC00018FC0000018FC000187E0000030FC000187
+E0000030FC000183F0000060FC000183F0000060FC000183F0000060FC000181F80000C0
+FC000181F80000C0FC000181F80000C0FC000180FC000180FC000180FC000180FC000180
+7E000300FC0001807E000300FC0001807E000300FC0001803F000600FC0001803F000600
+FC0001801F800C00FC0001801F800C00FC0001801F800C00FC0001800FC01800FC000180
+0FC01800FC0001800FC01800FC00018007E03000FC00018007E03000FC00018003F06000
+FC00018003F06000FC00018003F06000FC00018001F8C000FC00018001F8C000FC000180
+01F8C000FC00018000FD8000FC00018000FD8000FC000180007F0000FC000180007F0000
+FC000180007F0000FC0003C0003E0000FC0007E0003E0000FC000FF0001C0001FE00FFFF
+001C007FFFF8FFFF001C007FFFF83D337CB246>I<FFFE00001FFFF8FFFF00001FFFF800
+FF000001FF8000FF8000007E0000FFC000003C0000DFE00000180000CFE00000180000C7
+F00000180000C7F80000180000C3F80000180000C1FC0000180000C1FE0000180000C0FF
+0000180000C07F0000180000C03F8000180000C03FC000180000C01FC000180000C00FE0
+00180000C00FF000180000C007F800180000C003F800180000C001FC00180000C001FE00
+180000C000FE00180000C0007F00180000C0007F80180000C0003FC0180000C0001FC018
+0000C0000FE0180000C0000FF0180000C00007F0180000C00003F8180000C00003FC1800
+00C00001FE180000C00000FE180000C000007F180000C000007F980000C000003F980000
+C000001FD80000C000001FF80000C000000FF80000C0000007F80000C0000003F80000C0
+000003F80000C0000001F80000C0000000F80001E0000000F80003F000000078000FFC00
+00003800FFFFC000001800FFFFC00000180035337EB23A>I<000007FC00000000007FFF
+C000000001FC07F000000007E000FC0000001F80003F0000003F00001F8000007E00000F
+C00000FC000007E00001F8000003F00003F0000001F80007F0000001FC0007E0000000FC
+000FC00000007E001FC00000007F001FC00000007F003F800000003F803F800000003F80
+3F800000003F807F800000003FC07F000000001FC07F000000001FC0FF000000001FE0FF
+000000001FE0FF000000001FE0FF000000001FE0FF000000001FE0FF000000001FE0FF00
+0000001FE0FF000000001FE0FF000000001FE0FF000000001FE0FF000000001FE07F0000
+00001FC07F800000003FC07F800000003FC07F800000003FC03F800000003F803FC00000
+007F801FC00000007F001FC00000007F000FE0000000FE000FE0000000FE0007F0000001
+FC0003F8000003F80001F8000003F00000FC000007E000007E00000FC000003F00001F80
+00001F80003F00000007E000FC00000001FC07F0000000007FFFC00000000007FC000000
+33357CB33C>I<FFFFFFFE0000FFFFFFFFC00003FE0007F80001FC0001FC0001FC00007E
+0001FC00003F8001FC00001F8001FC00001FC001FC00001FE001FC00000FE001FC00000F
+F001FC00000FF001FC00000FF001FC00000FF001FC00000FF001FC00000FF001FC00000F
+F001FC00000FE001FC00001FE001FC00001FC001FC00001F8001FC00003F8001FC00007E
+0001FC0001FC0001FC0007F80001FFFFFFC00001FFFFFE000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000001FC0000000001FC0000000001FC0000000001FC0000000001FC000000
+0001FC0000000003FE00000000FFFFF8000000FFFFF80000002C337DB234>I<FFFFFFFC
+000000FFFFFFFFC0000001FF000FF0000000FE0001FC000000FE00007E000000FE00003F
+000000FE00001F800000FE00001FC00000FE00001FE00000FE00000FE00000FE00000FF0
+0000FE00000FF00000FE00000FF00000FE00000FF00000FE00000FF00000FE00000FF000
+00FE00000FE00000FE00001FE00000FE00001FC00000FE00001F800000FE00003F000000
+FE00007E000000FE0001FC000000FE000FF0000000FFFFFFC0000000FFFFFF00000000FE
+001FC0000000FE0007E0000000FE0001F0000000FE0001F8000000FE0000FC000000FE00
+00FE000000FE00007E000000FE00007F000000FE00007F000000FE00007F000000FE0000
+7F000000FE00007F000000FE00007F800000FE00007F800000FE00007F800000FE00007F
+800000FE00007F800000FE00007F800C00FE00007FC00C00FE00003FC00C00FE00003FC0
+0C00FE00001FC01801FF00000FE030FFFFFE0007F070FFFFFE0001FFC000000000003F80
+36347EB239>82 D<001FE0030000FFFC030001F01F0700078003CF000F0000FF001E0000
+3F001C00003F003C00001F007800000F007800000F007800000700F800000700F8000007
+00F800000300F800000300FC00000300FC00000300FE000000007F000000007FC0000000
+3FF00000003FFF0000001FFFF000000FFFFF000007FFFFC00003FFFFF00000FFFFF80000
+3FFFFC000003FFFE0000003FFE00000003FF00000000FF800000003F800000001F800000
+001FC00000000FC04000000FC0C0000007C0C0000007C0C0000007C0C0000007C0E00000
+07C0E000000780E000000780F000000F00F000000F00F800001E00FC00001C00FF000038
+00F3C000F000E0FC03E000C03FFF8000C003FE000022357CB32B>I<7FFFFFFFFFFE7FFF
+FFFFFFFE7F800FF801FE7C0007F0003E780007F0001E700007F0000E700007F0000E6000
+07F00006600007F00006E00007F00007E00007F00007C00007F00003C00007F00003C000
+07F00003C00007F00003C00007F00003C00007F00003000007F00000000007F000000000
+07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000
+07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000
+07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000
+07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000
+07F00000000007F00000000007F00000000007F00000000007F0000000001FFC0000001F
+FFFFFC00001FFFFFFC0030337DB237>I<FFFFFE001FFFF8FFFFFE001FFFF801FF000001
+FF8000FE0000007E0000FE0000003C0000FE000000180000FE000000180000FE00000018
+0000FE000000180000FE000000180000FE000000180000FE000000180000FE0000001800
+00FE000000180000FE000000180000FE000000180000FE000000180000FE000000180000
+FE000000180000FE000000180000FE000000180000FE000000180000FE000000180000FE
+000000180000FE000000180000FE000000180000FE000000180000FE000000180000FE00
+0000180000FE000000180000FE000000180000FE000000180000FE000000180000FE0000
+00180000FE000000180000FE000000180000FE000000180000FE0000001800007E000000
+3000007F0000003000007F0000003000003F0000006000001F0000006000001F800000C0
+00000F800000C0000007C0000180000003E0000300000001F0000E00000000FC003C0000
+00003F00F0000000000FFFC00000000001FF00000035347EB23A>I<FFFFF00003FFF8FF
+FFF00003FFF807FE0000007FC003FC0000001F0001FC0000001E0001FC0000000C0001FE
+0000000C0000FE000000180000FE0000001800007F0000003000007F0000003000007F80
+00003000003F8000006000003F8000006000003FC00000E000001FC00000C000001FE000
+00C000000FE000018000000FE000018000000FF0000380000007F0000300000007F80003
+00000003F8000600000003F8000600000003FC000E00000001FC000C00000001FE000C00
+000000FE001800000000FE001800000000FF0038000000007F0030000000007F80300000
+00003F8060000000003F8060000000003FC0E0000000001FC0C0000000001FE0C0000000
+000FE180000000000FE180000000000FF3800000000007F3000000000007FB0000000000
+03FE000000000003FE000000000003FE000000000001FC000000000001FC000000000000
+F8000000000000F8000000000000F8000000000000700000000000007000000035347EB2
+3A>I<FFFFF007FFFF800FFFF0FFFFF007FFFF800FFFF007FF00007FF00001FF0003FC00
+001FE000007E0001FC00001FC000003C0001FC00001FE00000380000FE00000FE0000030
+0000FE00000FE00000300000FE00000FF000003000007F000007F000006000007F000007
+F000006000007F00000FF800006000003F80000FF80000C000003F80000FF80000C00000
+3F80001FFC0000C000001FC00019FC00018000001FC00019FC00018000001FC00039FE00
+018000000FE00030FE00030000000FE00030FE00030000000FE00070FF000300000007F0
+00607F000600000007F000607F000600000007F000E07F800600000003F800C03F800C00
+000003F800C03F800C00000003F801C03FC00C00000001FC01801FC01800000001FC0180
+1FC01800000001FC03801FE01800000000FE03000FE03000000000FE03000FE030000000
+00FE07000FF030000000007F060007F060000000007F060007F060000000007F0C0003F8
+60000000003F8C0003F8C0000000003F8C0003F8C0000000003F980001FCC0000000001F
+D80001FD80000000001FD80001FD80000000001FF00000FF80000000000FF00000FF0000
+0000000FF00000FF00000000000FE000007F000000000007E000007E000000000007E000
+007E000000000007C000003E000000000003C000003C000000000003C000003C00000000
+00038000001C000000000001800000180000004C347FB24F>I<7FFFFC00FFFFC07FFFFC
+00FFFFC001FFE0001FFC0000FF80000FE000007F8000078000003F8000070000003FC000
+060000001FE0000E0000000FE0000C0000000FF0001800000007F8003800000003F80070
+00000003FC006000000001FE00E000000000FF01C000000000FF0180000000007F830000
+0000003FC700000000003FC600000000001FEC00000000000FFC00000000000FF8000000
+000007F8000000000003FC000000000003FC000000000001FE000000000001FF00000000
+0003FF0000000000037F8000000000063FC0000000000E3FC0000000001C1FE000000000
+180FF0000000003807F0000000007007F8000000006003FC00000000C001FC00000001C0
+01FE000000018000FF0000000300007F0000000700007F8000000E00003FC000000C0000
+1FE000001C00001FE000003800000FF0000038000007F80000F8000007F80001FC000007
+FC000FFE00001FFE00FFFF8000FFFFF8FFFF8000FFFFF835337EB23A>I<03FFC000000F
+FFF800001F00FC00003F803F00003F801F80003F800FC0001F000FC0000E0007E0000000
+07E000000007E000000007E000000007E0000001FFE000003FFFE00000FF87E00003F807
+E0000FE007E0001F8007E0003F0007E0007E0007E0007E0007E000FC0007E0C0FC0007E0
+C0FC0007E0C0FC0007E0C0FC000FE0C07C000FE0C07E001BE0C03F0033F1801FC0E1FF80
+07FFC0FF0000FF007C0022207D9F26>97 D<03F0000000FFF0000000FFF000000007F000
+000003F000000003F000000003F000000003F000000003F000000003F000000003F00000
+0003F000000003F000000003F000000003F000000003F000000003F000000003F0000000
+03F000000003F000000003F03F800003F1FFF00003F3C0F80003F6003E0003FC000F0003
+F8000F8003F00007C003F00007C003F00003E003F00003F003F00003F003F00001F003F0
+0001F803F00001F803F00001F803F00001F803F00001F803F00001F803F00001F803F000
+01F803F00001F003F00003F003F00003E003F00003E003F00007C003F000078003F8000F
+8003EC001F0003E6003C0003C381F8000381FFE00003007F000025347EB32B>I<000FFE
+00007FFF8000F807C003E00FE007800FE00F800FE01F0007C01F0003803E0000007E0000
+007E0000007C000000FC000000FC000000FC000000FC000000FC000000FC000000FC0000
+00FC0000007C0000007E0000007E0000003E0000301F0000301F0000600F80006007C000
+C003E0038000F80F00007FFC00000FF0001C207D9F22>I<0000003F0000000FFF000000
+0FFF000000007F000000003F000000003F000000003F000000003F000000003F00000000
+3F000000003F000000003F000000003F000000003F000000003F000000003F000000003F
+000000003F000000003F000000003F000007F03F00003FFE3F0000FC0F3F0001E001BF00
+07C000FF000F80007F000F00003F001F00003F003E00003F003E00003F007E00003F007C
+00003F00FC00003F00FC00003F00FC00003F00FC00003F00FC00003F00FC00003F00FC00
+003F00FC00003F007C00003F007E00003F007E00003F003E00003F001F00003F001F0000
+7F000F8000FF00078001FF0003E003BF0000F81E3F80007FFC3FFC000FE03FFC26347DB3
+2B>I<000FF000007FFC0000F81F0003E00780078003C00F8001E01F0001E01E0001F03E
+0000F07E0000F07C0000F87C0000F8FC0000F8FFFFFFF8FFFFFFF8FC000000FC000000FC
+000000FC000000FC0000007C0000007E0000003E0000003E0000181F0000180F0000300F
+80003007C0006001E001C000F80F80003FFE000007F0001D207E9F22>I<0001FC00000F
+FE00001F0780003E0F80007C1FC000F81FC001F81FC001F00F8003F0070003F0000003F0
+000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0
+0000FFFFF000FFFFF00003F0000003F0000003F0000003F0000003F0000003F0000003F0
+000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0
+000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0
+000003F0000003F0000007F800007FFFE0007FFFE0001A347FB317>I<0000001F00001F
+C07F80007FF1E3C001F07F83C003C01E03C007800F018007800F00000F000780000F0007
+80001F0007C0001F0007C0001F0007C0001F0007C0001F0007C0000F000780000F000780
+0007800F000007800F000003C01E000003F07C0000067FF000000E1FC000000E00000000
+0E000000000E000000000E000000000E000000000F800000000FFFFE000007FFFFC00003
+FFFFF00001FFFFF80007FFFFFC001F0001FE003E00003F007C00001F007C00001F80F800
+000F80F800000F80F800000F80F800000F807800000F007C00001F003E00003E001F0000
+7C000F8000F80003F007E00000FFFF8000001FFC000022317EA026>I<03F0000000FFF0
+000000FFF000000007F000000003F000000003F000000003F000000003F000000003F000
+000003F000000003F000000003F000000003F000000003F000000003F000000003F00000
+0003F000000003F000000003F000000003F000000003F01FC00003F0FFF00003F1E0F800
+03F3007C0003F6007E0003FC003E0003FC003F0003F8003F0003F8003F0003F0003F0003
+F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0
+003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F000
+3F0003F0003F0003F0003F0003F0003F0003F0003F0007F8007F80FFFFC7FFFCFFFFC7FF
+FC26347EB32B>I<07800FC01FE01FE01FE01FE00FC00780000000000000000000000000
+0000000000000000000007E0FFE0FFE00FE007E007E007E007E007E007E007E007E007E0
+07E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E00FF0FFFF
+FFFF10337EB215>I<0003C00007E0000FF0000FF0000FF0000FF00007E00003C0000000
+0000000000000000000000000000000000000000000000000000000000000003F000FFF0
+00FFF00007F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F0
+0003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F0
+0003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F0
+3803F07C03E0FE07E0FE07C0FE07C07C0F80781F003FFC0007F000144284B217>I<03F0
+000000FFF0000000FFF000000007F000000003F000000003F000000003F000000003F000
+000003F000000003F000000003F000000003F000000003F000000003F000000003F00000
+0003F000000003F000000003F000000003F000000003F000000003F003FFE003F003FFE0
+03F000FF0003F000FC0003F000F00003F000E00003F001C00003F003000003F006000003
+F00C000003F038000003F070000003F0F0000003F1F8000003F3F8000003FEFC000003FC
+7E000003F03E000003F01F000003F01F800003F00FC00003F007C00003F007E00003F003
+F00003F001F00003F001F80003F000FC0003F000FE0003F000FF0007F800FF80FFFFC3FF
+F0FFFFC3FFF024347EB329>I<07E0FFE0FFE00FE007E007E007E007E007E007E007E007
+E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007
+E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007E007
+E007E00FF0FFFFFFFF10347EB315>I<03F01FE000FF0000FFF07FF803FFC000FFF1E07C
+0F03E00007F3803E1C01F00003F6003F3001F80003FC001F6000F80003FC001FE000FC00
+03F8001FC000FC0003F8001FC000FC0003F0001F8000FC0003F0001F8000FC0003F0001F
+8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F8000FC00
+03F0001F8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F
+8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F8000FC00
+03F0001F8000FC0003F0001F8000FC0003F0001F8000FC0003F0001F8000FC0007F8003F
+C001FE00FFFFC7FFFE3FFFF0FFFFC7FFFE3FFFF03C207E9F41>I<03F01FC000FFF0FFF0
+00FFF1E0F80007F3007C0003F6007E0003FC003E0003FC003F0003F8003F0003F8003F00
+03F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003
+F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0
+003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0007F8007F80FFFFC7
+FFFCFFFFC7FFFC26207E9F2B>I<000FF80000003FFE000000F80F800003E003E00007C0
+01F0000F8000F8001F00007C001E00003C003E00003E007E00003F007C00001F007C0000
+1F00FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80FC00001F
+80FC00001F807C00001F007C00001F007E00003F003E00003E003E00003E001F00007C00
+0F8000F80007C001F00003E003E00000F80F8000007FFF0000000FF8000021207E9F26>
+I<03F03F8000FFF1FFF000FFF3C0F80007F6003E0003FC001F0003F8000F8003F00007C0
+03F00007C003F00003E003F00003F003F00003F003F00001F003F00001F803F00001F803
+F00001F803F00001F803F00001F803F00001F803F00001F803F00001F803F00003F003F0
+0003F003F00003E003F00007E003F00007C003F0000F8003F8000F8003FC001F0003F600
+7C0003F381F80003F1FFE00003F07F000003F000000003F000000003F000000003F00000
+0003F000000003F000000003F000000003F000000003F000000003F000000003F0000000
+03F000000007F8000000FFFFC00000FFFFC00000252F7E9F2B>I<03E07C00FFE0FF00FF
+E38F8007E31FC003E61FC003EC1FC003EC0F8003F8070003F8000003F8000003F0000003
+F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003
+F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000007
+F80000FFFFE000FFFFE0001A207F9F1E>114 D<00FF060007FFEE001F00FE003C001E00
+38000E0070000E00F0000600F0000600F0000600F8000600FE0000007FE000007FFF0000
+3FFFE0001FFFF0000FFFF80003FFFC00007FFE000003FF0000003F8040001F80C0000F80
+C0000780E0000780E0000780F0000700F0000700F8000E00FE001C00F7807800E1FFF000
+C07F800019207E9F1E>I<00300000300000300000300000300000700000700000700000
+F00000F00001F00003F00007F0001FF000FFFFFEFFFFFE03F00003F00003F00003F00003
+F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003
+F00303F00303F00303F00303F00303F00303F00303F00301F00601F80600F80C007E1C00
+3FF80007E0182E7FAD1E>I<03F0003F00FFF00FFF00FFF00FFF0007F0007F0003F0003F
+0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F00
+03F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003
+F0003F0003F0003F0003F0003F0003F0003F0003F0003F0003F0007F0003F0007F0001F0
+00FF0001F000FF0000F801BF00007C073F80003FFE3FFC0007F83FFC26207E9F2B>I<FF
+FF00FFF0FFFF00FFF00FF0003FC007F0001F0007F0000E0003F0000C0003F0000C0001F8
+00180001F800180001FC00380000FC00300000FC003000007E006000007E006000007F00
+E000003F00C000003F81C000001F818000001F818000000FC30000000FC30000000FE700
+000007E600000007F600000003FC00000003FC00000001F800000001F800000001F80000
+0000F000000000F00000000060000024207E9F29>I<FFFF1FFF81FFF0FFFF1FFF81FFF0
+0FF803FC003F8007F001F8001F0003F000F8001E0003F000F8000C0003F800FC001C0001
+F8007C00180001F8007E00180000FC00FE00300000FC00FE00300000FC00FF003000007E
+019F006000007E019F006000007F019F80E000003F030F80C000003F030FC0C000001F87
+0FC18000001F8607C18000001F8607E18000000FCC03E30000000FCC03E30000000FEC03
+F700000007F801F600000007F801FE00000003F801FC00000003F000FC00000003F000FC
+00000001E0007800000001E0007800000001E0007800000000C00030000034207F9F37>
+I<FFFF01FFF8FFFF01FFF807FC007F8003FC007E0001FC00380000FC007000007E006000
+007F00E000003F81C000001F838000000FC300000007E600000007FE00000003FC000000
+01F800000000FC00000000FE00000000FF00000001FF000000039F800000071FC0000006
+0FE000000C07E000001C03F000003801F800007001FC00006000FC0001E0007E0003E000
+7F000FF000FF80FFFC03FFFCFFFC03FFFC26207F9F29>I<7FFF807FF87FFF807FF807F8
+001FE003F8000F8003F800070001F800060001F800060000FC000C0000FC000C0000FE00
+1C00007E001800007E001800003F003000003F003000003F807000001F806000001FC0E0
+00000FC0C000000FC0C0000007E180000007E180000007F380000003F300000003FB0000
+0001FE00000001FE00000000FC00000000FC00000000FC00000000780000000078000000
+003000000000300000000060000000006000000000E000000000C000000000C000000001
+8000007801800000FC03000000FC07000000FC06000000FC0C00000070380000003FF000
+00000FC0000000252F7F9F29>I<3FFFFFF03FFFFFF03F0007E03C000FC038001FC03000
+3F8070003F0070007E006000FE006000FC006001F8006003F8000007F0000007E000000F
+C000001FC000003F8000003F0000007E003000FE003001FC003001F8003003F0003007F0
+007007E000700FC000601FC000E03F8000E03F0003E07E000FE0FFFFFFE0FFFFFFE01C20
+7E9F22>I E /Fm 1 64 df<000100000003000000030000000300000003000000030000
+0007800000078000000780000007800040078008FC0780FC7FE79FF80FFFFFC003FFFF00
+00FFFC00003FF000001FE000001FE000003FF000003CF0000078780000F03C0000E01C00
+01C00E00018006000380070007000380020001001E1D7E9C22>63
+D E /Fn 76 127 df<00000FF800FC0000007FFF07FF000001F8078F83800007E001DE0F
+C0000F8003FC0FE0001F0007FC1FE0003E000FF81FE0007C000FF81FE000FC000FF80FC0
+00FC0007F0078001F80003F0000001F80003F0000001F80003F0000001F80003F0000001
+F80003F0000001F80003F0000001F80003F0000001F80003F0000001F80003F0000001F8
+0003F0000001F80003F0000001F80003F0000001F80003F00000FFFFFFFFFFF800FFFFFF
+FFFFF800FFFFFFFFFFF80001F80003F0000001F80003F0000001F80003F0000001F80003
+F0000001F80003F0000001F80003F0000001F80003F0000001F80003F0000001F80003F0
+000001F80003F0000001F80003F0000001F80003F0000001F80003F0000001F80003F000
+0001F80003F0000001F80003F0000001F80003F0000001F80003F0000001F80003F00000
+01F80003F0000001F80003F0000001F80003F0000001F80003F0000001F80003F0000001
+F80003F0000001F80003F0000001F80003F0000001F80003F0000001F80003F0000003FC
+0007F800007FFFE0FFFFF0007FFFE0FFFFF0007FFFE0FFFFF000333B7FBA30>11
+D<00000FF8000000007FFE00000001F80780000007E001C000000F80006000001F0003E0
+00003E0007F000007C000FF00000FC000FF00000FC000FF00001F80007E00001F80003C0
+0001F80001800001F80000000001F80000000001F80000000001F80000000001F8000000
+0001F80000000001F80000000001F80000000001F80000000001F80003F000FFFFFFFFF0
+00FFFFFFFFF000FFFFFFFFF00001F8000FF00001F80003F00001F80003F00001F80003F0
+0001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F0
+0001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F0
+0001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F0
+0001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F0
+0001F80003F00003FC0007F8007FFFE0FFFFC07FFFE0FFFFC07FFFE0FFFFC02A3B7FBA2E
+>I<00000FFC000000007FFF70000001F803F0000007E007F000000F800FF000001F000F
+F000003E000FF000007C000FF00000FC0007F00000FC0003F00001F80003F00001F80003
+F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003
+F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F000FFFFFFFF
+F000FFFFFFFFF000FFFFFFFFF00001F80003F00001F80003F00001F80003F00001F80003
+F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003
+F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003
+F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003
+F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003F00001F80003
+F00001F80003F00003FC0007F8007FFFE0FFFFC07FFFE0FFFFC07FFFE0FFFFC02A3B7FBA
+2E>I<00000FF0001FF0000000007FFE00FFFC00000001F80F03F00F00000007E0018FC0
+038000000F8000DF0000C000001F0003FE0007C000003E0007FC000FE000007C000FF800
+1FE00000FC000FF8001FE00000FC000FF8001FE00001F8000FF0000FC00001F80007F000
+07800001F80003F00003000001F80003F00000000001F80003F00000000001F80003F000
+00000001F80003F00000000001F80003F00000000001F80003F00000000001F80003F000
+00000001F80003F00000000001F80003F00000000001F80003F00007E000FFFFFFFFFFFF
+FFE000FFFFFFFFFFFFFFE000FFFFFFFFFFFFFFE00001F80003F0001FE00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00001F80003F000
+07E00001F80003F00007E00001F80003F00007E00001F80003F00007E00003FC0007F800
+0FF0007FFFE0FFFFC1FFFF807FFFE0FFFFC1FFFF807FFFE0FFFFC1FFFF80413B7FBA45>
+I<1C001C007E007E007F007F00FF80FF80FF80FF80FFC0FFC07FC07FC07FC07FC01CC01C
+C000C000C000C000C000C000C000C000C001800180018001800180018003000300030003
+0003000300060006000C000C000C000C001800180030003000200020001A197DB92A>34
+D<007C00000000600001FF00000000F00003C380000001F0000700C0000001E0000E0060
+000003E0001E007000000FC0001C003C00001F80003C003F00007F80003C001BE003FF00
+007C0018FFFF9E00007800181FFC3E000078000C00007C0000F8000C0000780000F8000C
+0000F80000F8000C0001F00000F8000C0001E00000F8000C0003E00000F8000C0007C000
+00F8000C0007800000F8000C000F800000F8000C001F00000078000C001E000000780018
+003E0000007C0018007C0000003C001800780000003C003000F80000001C003001F00000
+001E006001E00000000E006003E00000000700C007C000000003C380078000000001FF00
+0F80000000007C001F000000000000001E0007C0000000003E001FF0000000007C003C38
+000000007800700C00000000F800F00600000001F001E00600000001E001E00300000003
+E003C00300000007C003C001800000078007C0018000000F800780018000001F00078001
+8000001E000F8000C000003E000F8000C000007C000F8000C0000078000F8000C00000F8
+000F8000C00001F0000F8000C00001E0000F8000C00003E0000F8000C00007C0000F8000
+C0000780000F8000C0000F800007800180001F000007800180001E000007C00180003E00
+0003C00180007C000003C003000078000001E0030000F8000001E0060001F0000000F006
+0001E0000000700C0003E00000003C380003C00000001FF000018000000007C0003A437B
+BD45>37 D<1C007E007F00FF80FF80FFC07FC07FC01CC000C000C000C000C00180018001
+8003000300030006000C000C001800300020000A1979B917>39 D<0000600000E00001C0
+000380000700000E00001C00003C0000380000700000F00000E00001E00003C00003C000
+0780000780000780000F00000F00001F00001E00001E00003E00003E00003C00003C0000
+7C00007C00007C00007C00007C0000780000F80000F80000F80000F80000F80000F80000
+F80000F80000F80000F80000F80000F80000F80000F80000F80000F800007800007C0000
+7C00007C00007C00007C00003C00003C00003E00003E00001E00001E00001F00000F0000
+0F000007800007800007800003C00003C00001E00000E00000F000007000003800003C00
+001C00000E000007000003800001C00000E0000060135278BD20>I<800000C00000E000
+007000003800001C00000E00000F000007000003800003C00001C00001E00000F00000F0
+00007800007800007800003C00003C00003E00001E00001E00001F00001F00000F00000F
+00000F80000F80000F80000F80000F800007800007C00007C00007C00007C00007C00007
+C00007C00007C00007C00007C00007C00007C00007C00007C00007C00007C0000780000F
+80000F80000F80000F80000F80000F00000F00001F00001F00001E00001E00003E00003C
+00003C0000780000780000780000F00000F00001E00001C00003C0000380000700000F00
+000E00001C0000380000700000E00000C0000080000012527BBD20>I<1C007E007F00FF
+80FF80FFC07FC07FC01CC000C000C000C000C001800180018003000300030006000C000C
+001800300020000A19798817>44 D<FFFFFCFFFFFCFFFFFCFFFFFCFFFFFC16057F941C>
+I<1C003E007F00FF80FF80FF807F003E001C000909798817>I<0000000C0000001E0000
+001E0000003E0000003C0000003C0000007C0000007800000078000000F8000000F00000
+00F0000001F0000001E0000001E0000003E0000003C0000003C0000007C0000007800000
+078000000F8000000F0000001F0000001E0000001E0000003E0000003C0000003C000000
+7C0000007800000078000000F8000000F0000000F0000001F0000001E0000001E0000003
+E0000003C0000003C0000007C0000007800000078000000F8000000F0000000F0000001F
+0000001E0000001E0000003E0000003C0000003C0000007C0000007800000078000000F8
+000000F0000000F0000001F0000001E0000003E0000003C0000003C0000007C000000780
+0000078000000F8000000F0000000F0000001F0000001E0000001E0000003E0000003C00
+00003C0000007C0000007800000078000000F8000000F0000000F0000000600000001F53
+7BBD2A>I<0003F80000001FFF0000007E0FC00000F803E00003E000F80003C000780007
+C0007C000F80003E000F80003E001F00001F001F00001F003F00001F803F00001F803F00
+001F807E00000FC07E00000FC07E00000FC07E00000FC07E00000FC0FE00000FE0FE0000
+0FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000F
+E0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000FE0
+FE00000FE0FE00000FE07E00000FC07E00000FC07E00000FC07E00000FC07F00001FC03F
+00001F803F00001F803F00001F801F00001F001F00001F000F80003E000F80003E0007C0
+007C0003E000F80003E000F80000F803E000007E0FC000001FFF00000007FC000023387D
+B62A>I<0001800000078000000F8000003F800001FF8000FFFF8000FFDF8000FE1F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000
+001F8000001F8000001F8000001F8000001F8000001F8000001F8000003FC0007FFFFFE0
+7FFFFFE07FFFFFE01B3779B62A>I<001FF00000007FFE000001FFFF800003E03FE00007
+000FF0000C0003F800180003FC00300001FE00700000FE00600000FF007C0000FF00FF00
+007F00FF00007F80FF80007F80FF80007F80FF80007F807F00007F807F00007F801C0000
+7F800000007F000000007F00000000FF00000000FE00000000FE00000001FC00000001F8
+00000003F800000003F000000007E00000000FC00000000F800000001F000000003E0000
+00007C00000000F800000000F000000001C0000000038000000007000000000E00000000
+1C0000000038000180007000018000E000018000C0000300018000030003000003000600
+0003000C000007001FFFFFFF003FFFFFFF007FFFFFFE00FFFFFFFE00FFFFFFFE00FFFFFF
+FE0021377CB62A>I<0007F80000003FFF000000FFFFC00001F00FE000038003F0000700
+01F8000F0001FC000FC001FE001FE000FE001FE000FF001FE000FF001FE000FF000FE000
+FF000FC000FF00038000FF00000000FE00000000FE00000001FE00000001FC00000001F8
+00000003F000000003E000000007C00000000F800000007F0000001FFC0000001FFF8000
+00000FE000000003F000000001FC00000000FE00000000FF000000007F000000007F8000
+00007FC00000003FC00000003FC00000003FE00000003FE03E00003FE07F00003FE0FF80
+003FE0FF80003FE0FF80003FE0FF80003FC0FF00007FC07E00007F807C00007F80300000
+FF00380000FE001C0001FC000F0003F80007F00FF00001FFFFC000007FFF8000000FFC00
+0023387DB62A>I<00000070000000007000000000F000000001F000000001F000000003
+F000000007F000000007F00000000FF00000001FF00000001BF000000033F000000073F0
+000000E3F0000000C3F0000001C3F000000383F000000303F000000703F000000E03F000
+000C03F000001C03F000003803F000003003F000007003F00000E003F00000C003F00001
+8003F000038003F000030003F000060003F0000E0003F0000C0003F000180003F0003800
+03F000300003F000600003F000E00003F000FFFFFFFFF8FFFFFFFFF8FFFFFFFFF8000003
+F000000003F000000003F000000003F000000003F000000003F000000003F000000003F0
+00000003F000000003F000000003F000000007F8000003FFFFF00003FFFFF00003FFFFF0
+25387EB72A>I<0600000C000780003C0007F003F80007FFFFF00007FFFFE00007FFFFC0
+0007FFFF800007FFFF000007FFFC0000067FE00000060000000006000000000600000000
+060000000006000000000600000000060000000006000000000600000000060000000006
+000000000607F80000063FFF000006F80F800007C003C000070001F000060000F8000400
+00F8000000007C000000007E000000007E000000003F000000003F000000003F00000000
+3F800000003F800000003F803C00003F807E00003F80FF00003F80FF00003F80FF00003F
+80FF00003F00FE00003F00FC00007F006000007E006000007E00300000FC00380000F800
+180001F8000E0003F000070007E00003E03F800001FFFF0000007FFC0000001FE0000021
+387CB62A>I<00003FC0000001FFF0000007FFFC00000FE03E00003F000700007E001F00
+00F8003F8001F8007F8003F0007F8003E0007F8007E0007F800FC0003F000FC0001E001F
+C00000001F800000003F800000003F800000003F800000007F000000007F000000007F01
+FC00007F07FF8000FF0E07E000FF1801F000FF3000F800FF60007C00FFC0007E00FFC000
+3F00FF80003F00FF80003F80FF80001FC0FF80001FC0FF00001FC0FF00001FE0FF00001F
+E0FF00001FE07F00001FE07F00001FE07F00001FE07F00001FE07F00001FE03F00001FE0
+3F80001FC03F80001FC01F80001FC01F80001F800F80003F800FC0003F0007C0003E0007
+E0007E0003F000FC0001F801F80000FE07F000003FFFC000001FFF80000003FC00002338
+7DB62A>I<300000000038000000003E000000003FFFFFFFE03FFFFFFFE03FFFFFFFE03F
+FFFFFFC07FFFFFFF807FFFFFFF00700000030060000006006000000C006000000C006000
+001800C000003000C000006000C000006000000000C00000000180000000030000000003
+0000000006000000000C000000000C000000001800000000380000000030000000007000
+0000007000000000E000000001E000000001E000000003E000000003C000000007C00000
+0007C000000007C00000000FC00000000FC00000001F800000001F800000001F80000000
+1F800000003F800000003F800000003F800000003F800000003F800000007F800000007F
+800000007F800000007F800000007F800000007F800000007F800000007F800000003F00
+0000001E000000233A7BB82A>I<0003FC0000001FFF0000007FFFC00000FC07E00001E0
+01F00003800078000700003C000700001E000E00001E000E00000F001E00000F001E0000
+0F001E00000F001E00000F001F00000F001F00000E001F80001E000FE0001C000FF0003C
+0007FC00780007FE00700003FF81E00001FFC3C00000FFFF0000007FFC0000001FFE0000
+000FFF8000001FFFC0000079FFF00000F07FF80001C01FFC0007800FFE000F0003FF001E
+0001FF801C00007F803C00003FC07800000FC078000007E070000003E0F0000003E0F000
+0001E0F0000001E0F0000001E0F0000001E0F0000001C078000001C078000003C07C0000
+03803C000007001E00000F000F80001E0007C0007C0003F803F00000FFFFE000003FFF80
+000007FC000023387DB62A>I<0007F80000001FFF0000007FFFC00000FC07E00001F001
+F00003E000F80007C000FC000FC0007C001F80007E003F80003F003F80003F007F00003F
+007F00003F807F00003F80FF00001F80FF00001FC0FF00001FC0FF00001FC0FF00001FC0
+FF00001FE0FF00001FE0FF00001FE0FF00001FE07F00001FE07F00003FE07F00003FE03F
+80003FE01F80003FE01F80007FE00FC0007FE007C000DFE003E0019FE001F0031FE000FC
+0E1FE0003FFC1FC00007F01FC00000001FC00000001FC00000003F800000003F80000000
+3F800000003F000000003F000F00007E001F80007E003FC0007C003FC000FC003FC001F8
+003FC001F0003F8003E0001F0007C0001C001F80000F807F000007FFFC000001FFF80000
+003FC0000023387DB62A>I<1C003E007F00FF80FF80FF807F003E001C00000000000000
+0000000000000000000000000000000000000000000000000000000000001C003E007F00
+FF80FF80FF807F003E001C00092479A317>I<1C003E007F00FF80FF80FF807F003E001C
+000000000000000000000000000000000000000000000000000000000000000000000000
+001C007E007F00FF00FF80FF807F807F801D800180018001800180030003000300030006
+0006000C000C001800300030002000093479A317>I<000003FF00000000001FFFE00000
+0000FC00FC00000001E0001E000000070000038000000E000001C0000018000000600000
+3000000030000060000000180000C00000000C0001800000000600030000000003000600
+01FC000180060007FF0001800C001F03C000C018003C00E00060180078003000601800F8
+001800603001F0000C00303003E0000FE0306003E00007E0186007C00007E0186007C000
+07E018600FC00007E018C00FC00007E00CC00F800007E00CC01F800007E00CC01F800007
+E00CC01F800007E00CC01F800007E00CC01F800007E00CC01F800007E00CC01F800007E0
+0CC01F800007E00CC00F800007E00CC00FC00007E00C600FC00007E00C6007C00007E00C
+6007C00007E00C6003E00007E0183003E0000FE0183001F0000FE0181800F8001FE01818
+00780033E03018003C00E3F0300C001F03C1F0E0060007FF00FFC0060001FC003F000300
+00000000000180000000000000C000000000000060000000000000300000000000001800
+0000007C000E00000003FC00070000001FF00001E00000FF800000FC003FFC0000001FFF
+FF8000000003FFE00000363C7BBA41>64 D<000000380000000000003800000000000038
+0000000000007C0000000000007C0000000000007C000000000000FE000000000000FE00
+0000000001FF000000000001FF000000000001FF000000000003FF8000000000033F8000
+000000033F8000000000073FC000000000061FC000000000061FC0000000000C1FE00000
+00000C0FE0000000000C0FE0000000001807F0000000001807F0000000001807F0000000
+003003F8000000003003F8000000003003F8000000006001FC000000006001FC00000000
+6001FC00000000C000FE00000000C000FE00000000C000FE0000000180007F0000000180
+007F0000000380007F8000000300003F8000000300003F80000007FFFFFFC0000007FFFF
+FFC0000007FFFFFFC000000E00001FE000000C00000FE000000C00000FE000001800000F
+F0000018000007F0000018000007F0000030000003F8000030000003F8000030000003F8
+000060000001FC000060000001FC000060000001FC0000E0000000FE0001E0000000FE00
+03F0000000FF000FFC000003FF80FFFF80007FFFFEFFFF80007FFFFEFFFF80007FFFFE37
+3B7DBA3E>I<FFFFFFFFE00000FFFFFFFFFC0000FFFFFFFFFF000001FF00007FC00000FE
+00001FE00000FE00000FF00000FE000007F80000FE000003FC0000FE000003FC0000FE00
+0001FE0000FE000001FE0000FE000001FF0000FE000001FF0000FE000001FF0000FE0000
+01FF0000FE000001FF0000FE000001FF0000FE000001FF0000FE000001FE0000FE000003
+FE0000FE000003FC0000FE000007F80000FE00000FF00000FE00001FE00000FE00003FC0
+0000FE0000FF000000FFFFFFFC000000FFFFFFFC000000FE0000FF800000FE00001FE000
+00FE000007F00000FE000003F80000FE000003FC0000FE000001FE0000FE000000FF0000
+FE000000FF0000FE000000FF8000FE0000007F8000FE0000007FC000FE0000007FC000FE
+0000007FC000FE0000007FC000FE0000007FC000FE0000007FC000FE0000007FC000FE00
+00007F8000FE000000FF8000FE000000FF8000FE000001FF0000FE000001FE0000FE0000
+03FE0000FE000007FC0000FE00001FF80001FF00007FE000FFFFFFFFFFC000FFFFFFFFFF
+0000FFFFFFFFF8000032397DB83B>I<000001FF80018000000FFFE0018000007FFFF803
+800001FF807E07800003FC000F0F80000FF000038F80001FC00001DF80003F8000007F80
+007F0000003F8000FE0000003F8001FC0000001F8003F80000000F8007F80000000F8007
+F000000007800FF000000007800FE000000003801FE000000003801FE000000003803FC0
+00000003803FC000000001807FC000000001807FC000000001807F8000000001807F8000
+00000000FF800000000000FF800000000000FF800000000000FF800000000000FF800000
+000000FF800000000000FF800000000000FF800000000000FF800000000000FF80000000
+0000FF8000000000007F8000000000007F8000000000007FC000000001807FC000000001
+803FC000000001803FC000000001801FE000000001801FE000000003800FE00000000300
+0FF0000000030007F0000000070007F8000000060003F8000000060001FC0000000C0000
+FE0000001800007F0000003800003F8000007000001FC00000E000000FF00001C0000003
+FC000780000001FF803E000000007FFFFC000000000FFFF00000000001FF800000313B7B
+B93C>I<FFFFFFFFC00000FFFFFFFFF80000FFFFFFFFFE000001FF0001FF800000FE0000
+3FE00000FE00000FF00000FE000003F80000FE000001FC0000FE000000FE0000FE000000
+7F0000FE0000007F0000FE0000003F8000FE0000003FC000FE0000001FC000FE0000001F
+E000FE0000000FE000FE0000000FF000FE0000000FF000FE0000000FF000FE00000007F8
+00FE00000007F800FE00000007F800FE00000007F800FE00000007FC00FE00000007FC00
+FE00000007FC00FE00000007FC00FE00000007FC00FE00000007FC00FE00000007FC00FE
+00000007FC00FE00000007FC00FE00000007FC00FE00000007FC00FE00000007FC00FE00
+000007F800FE00000007F800FE00000007F800FE00000007F800FE0000000FF000FE0000
+000FF000FE0000000FE000FE0000000FE000FE0000001FE000FE0000001FC000FE000000
+3F8000FE0000003F8000FE0000007F0000FE000000FE0000FE000001FC0000FE000003F8
+0000FE00000FF00000FE00003FE00001FF0000FF8000FFFFFFFFFF0000FFFFFFFFF80000
+FFFFFFFFC0000036397DB83F>I<FFFFFFFFFFFC00FFFFFFFFFFFC00FFFFFFFFFFFC0001
+FF00000FFC0000FE000001FC0000FE0000007E0000FE0000003E0000FE0000001E0000FE
+0000000E0000FE0000000E0000FE0000000E0000FE000000060000FE000000060000FE00
+0000060000FE000000070000FE000000030000FE0000C0030000FE0000C0030000FE0000
+C0030000FE0000C0000000FE0000C0000000FE0000C0000000FE0001C0000000FE0001C0
+000000FE0003C0000000FE000FC0000000FFFFFFC0000000FFFFFFC0000000FFFFFFC000
+0000FE000FC0000000FE0003C0000000FE0001C0000000FE0001C0000000FE0000C00000
+00FE0000C0000000FE0000C0006000FE0000C0006000FE0000C0006000FE0000C000E000
+FE00000000C000FE00000000C000FE00000000C000FE00000000C000FE00000001C000FE
+00000001C000FE00000001C000FE000000038000FE000000038000FE000000078000FE00
+0000078000FE0000000F8000FE0000003F8000FE0000007F8001FF000007FF00FFFFFFFF
+FFFF00FFFFFFFFFFFF00FFFFFFFFFFFF0033397DB839>I<FFFFFFFFFFF8FFFFFFFFFFF8
+FFFFFFFFFFF801FF00001FF800FE000001F800FE000000FC00FE0000007C00FE0000003C
+00FE0000001C00FE0000001C00FE0000001C00FE0000000C00FE0000000C00FE0000000C
+00FE0000000E00FE0000000600FE0000000600FE0001800600FE0001800600FE00018000
+00FE0001800000FE0001800000FE0001800000FE0003800000FE0003800000FE00078000
+00FE001F800000FFFFFF800000FFFFFF800000FFFFFF800000FE001F800000FE00078000
+00FE0003800000FE0003800000FE0001800000FE0001800000FE0001800000FE00018000
+00FE0001800000FE0001800000FE0000000000FE0000000000FE0000000000FE00000000
+00FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE00000000
+00FE0000000000FE0000000000FE0000000001FF80000000FFFFFF800000FFFFFF800000
+FFFFFF8000002F397DB836>I<000000FF8000C000000FFFF000C000003FFFFC01C00000
+FF803F03C00003FC000787C0000FF00001C7C0001FC00000EFC0003F8000007FC0007F00
+00003FC000FE0000001FC001FC0000000FC003F800000007C003F800000007C007F00000
+0003C00FF000000003C00FE000000003C01FE000000001C01FE000000001C03FC0000000
+01C03FC000000000C07FC000000000C07FC000000000C07F8000000000C07F8000000000
+00FF800000000000FF800000000000FF800000000000FF800000000000FF800000000000
+FF800000000000FF800000000000FF800000000000FF800000000000FF800000000000FF
+8000007FFFFF7F8000007FFFFF7F8000007FFFFF7FC00000003FE07FC00000001FC03FC0
+0000001FC03FC00000001FC01FE00000001FC01FE00000001FC00FE00000001FC00FF000
+00001FC007F00000001FC003F80000001FC003FC0000001FC001FC0000001FC000FE0000
+001FC0007F0000001FC0003F8000003FC0001FE000007FC0000FF00000E7C00003FE0003
+C3C00000FFC01F83C000003FFFFE01C000000FFFF800C0000000FFC00000383B7CB941>
+I<FFFFFE00FFFFFEFFFFFE00FFFFFEFFFFFE00FFFFFE01FF000001FF0000FE000000FE00
+00FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000
+FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE
+000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE00
+0000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE0000
+00FE0000FFFFFFFFFE0000FFFFFFFFFE0000FFFFFFFFFE0000FE000000FE0000FE000000
+FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE
+0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE00
+00FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000
+FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE000000FE0000FE
+000000FE0000FE000000FE0001FF000001FF00FFFFFE00FFFFFEFFFFFE00FFFFFEFFFFFE
+00FFFFFE37397DB83E>I<FFFFFF80FFFFFF80FFFFFF8000FF8000007F0000007F000000
+7F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F000000
+7F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F000000
+7F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F000000
+7F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F000000
+7F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F000000
+7F0000007F000000FF8000FFFFFF80FFFFFF80FFFFFF8019397EB81E>I<FFFFFE0001FF
+FF00FFFFFE0001FFFF00FFFFFE0001FFFF0001FF0000007FF00000FE0000003F800000FE
+0000001E000000FE00000018000000FE00000030000000FE00000060000000FE000000C0
+000000FE00000180000000FE00000300000000FE00000600000000FE00000C00000000FE
+00001800000000FE00003000000000FE00006000000000FE0000C000000000FE00018000
+000000FE00030000000000FE00060000000000FE000C0000000000FE001C0000000000FE
+003C0000000000FE007E0000000000FE01FF0000000000FE03FF0000000000FE063F8000
+000000FE0C3FC000000000FE181FC000000000FE300FE000000000FE600FF000000000FE
+C007F000000000FF8003F800000000FF0003FC00000000FE0001FC00000000FE0000FE00
+000000FE0000FF00000000FE00007F00000000FE00003F80000000FE00003FC0000000FE
+00001FC0000000FE00000FE0000000FE00000FF0000000FE000007F0000000FE000003F8
+000000FE000003FC000000FE000001FC000000FE000000FE000000FE000000FF000000FE
+0000007F000000FE0000007F800000FE0000007FC00001FF000000FFF000FFFFFE000FFF
+FF80FFFFFE000FFFFF80FFFFFE000FFFFF8039397DB841>75 D<FFFFFFC00000FFFFFFC0
+0000FFFFFFC0000001FF8000000000FE0000000000FE0000000000FE0000000000FE0000
+000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000
+000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000
+000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000
+000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000
+000000FE0000000000FE0000000000FE0000000000FE0000001800FE0000001800FE0000
+001800FE0000001800FE0000001800FE0000003800FE0000003000FE0000003000FE0000
+003000FE0000007000FE0000007000FE0000007000FE000000F000FE000000F000FE0000
+01F000FE000003F000FE00000FF000FE00001FE001FF0001FFE0FFFFFFFFFFE0FFFFFFFF
+FFE0FFFFFFFFFFE02D397DB834>I<FFFE000000000FFFE0FFFF000000001FFFE0FFFF00
+0000001FFFE001FF000000001FF00000DF8000000037E00000DF8000000037E00000DF80
+00000037E00000CFC000000067E00000CFC000000067E00000C7E0000000C7E00000C7E0
+000000C7E00000C7E0000000C7E00000C3F000000187E00000C3F000000187E00000C3F0
+00000187E00000C1F800000307E00000C1F800000307E00000C0FC00000607E00000C0FC
+00000607E00000C0FC00000607E00000C07E00000C07E00000C07E00000C07E00000C07E
+00000C07E00000C03F00001807E00000C03F00001807E00000C01F80003007E00000C01F
+80003007E00000C01F80003007E00000C00FC0006007E00000C00FC0006007E00000C007
+E000C007E00000C007E000C007E00000C007E000C007E00000C003F0018007E00000C003
+F0018007E00000C003F0018007E00000C001F8030007E00000C001F8030007E00000C000
+FC060007E00000C000FC060007E00000C000FC060007E00000C0007E0C0007E00000C000
+7E0C0007E00000C0007E0C0007E00000C0003F180007E00000C0003F180007E00000C000
+1FB00007E00000C0001FB00007E00000C0001FB00007E00000C0000FE00007E00000C000
+0FE00007E00001E0000FE00007E00003F00007C00007E0000FFC0007C0000FF000FFFFC0
+038007FFFFE0FFFFC0038007FFFFE0FFFFC0038007FFFFE043397CB84C>I<FFFE000007
+FFFEFFFF000007FFFEFFFF000007FFFE00FF8000007FE000FFC000001F8000DFC000000F
+0000CFE00000060000CFF00000060000C7F00000060000C3F80000060000C3FC00000600
+00C1FC0000060000C0FE0000060000C0FF0000060000C07F0000060000C03F8000060000
+C03FC000060000C01FC000060000C00FE000060000C00FF000060000C007F000060000C0
+03F800060000C003FC00060000C001FC00060000C000FE00060000C000FF00060000C000
+7F00060000C0003F80060000C0003FC0060000C0001FC0060000C0000FE0060000C00007
+F0060000C00007F0060000C00003F8060000C00001FC060000C00001FC060000C00000FE
+060000C000007F060000C000007F060000C000003F860000C000001FC60000C000001FC6
+0000C000000FE60000C0000007F60000C0000007F60000C0000003FE0000C0000001FE00
+00C0000001FE0000C0000000FE0000C00000007E0000C00000007E0001E00000003E0003
+F00000001E000FFC0000001E00FFFFC000000E00FFFFC000000600FFFFC0000006003739
+7DB83E>I<000003FF00000000001FFFE000000000FE01FC00000003F8007F00000007E0
+001F8000001FC0000FE000003F000003F000007E000001F80000FE000001FC0001FC0000
+00FE0003F80000007F0003F80000007F0007F00000003F800FF00000003FC00FE0000000
+1FC01FE00000001FE01FE00000001FE03FC00000000FF03FC00000000FF03FC00000000F
+F07FC00000000FF87F8000000007F87F8000000007F87F8000000007F8FF8000000007FC
+FF8000000007FCFF8000000007FCFF8000000007FCFF8000000007FCFF8000000007FCFF
+8000000007FCFF8000000007FCFF8000000007FCFF8000000007FCFF8000000007FC7F80
+00000007F87FC00000000FF87FC00000000FF87FC00000000FF83FC00000000FF03FC000
+00000FF03FE00000001FF01FE00000001FE01FE00000001FE00FF00000003FC00FF00000
+003FC007F00000003F8003F80000007F0003FC000000FF0001FC000000FE0000FE000001
+FC00007F000003F800003F800007F000001FC0000FE0000007E0001F80000003F8007F00
+000000FE01FC000000003FFFF00000000003FF000000363B7BB941>I<FFFFFFFFC000FF
+FFFFFFF800FFFFFFFFFE0001FF0001FF8000FE00003FC000FE00000FE000FE000007F000
+FE000003F800FE000003FC00FE000003FE00FE000001FE00FE000001FE00FE000001FF00
+FE000001FF00FE000001FF00FE000001FF00FE000001FF00FE000001FF00FE000001FF00
+FE000001FE00FE000001FE00FE000003FC00FE000003FC00FE000007F800FE000007F000
+FE00000FE000FE00003FC000FE0001FF0000FFFFFFFC0000FFFFFFF00000FE0000000000
+FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000
+FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000
+FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000FE0000000000
+FE0000000000FE0000000000FE0000000000FE0000000001FF00000000FFFFFE000000FF
+FFFE000000FFFFFE00000030397DB839>I<000FF800C0003FFF00C000FFFF81C003F807
+E3C007C000F7C00F80003FC01E00001FC01E00000FC03C000007C07C000007C078000003
+C078000003C0F8000001C0F8000001C0F8000001C0F8000000C0FC000000C0FC000000C0
+FC000000C07E000000007F000000007F800000003FE00000003FFE0000001FFFE000000F
+FFFE000007FFFFC00003FFFFF00001FFFFFC00007FFFFE00000FFFFF000001FFFF800000
+1FFFC0000001FFC00000003FE00000000FF000000007F000000003F000000003F8000000
+01F840000001F8C0000000F8C0000000F8C0000000F8C0000000F8E0000000F8E0000000
+F0E0000000F0F0000001F0F0000001E0F8000001E0FC000003C0FE00000780FF80000F00
+FBE0001E00F0FE00FC00E07FFFF800C00FFFE000C001FF8000253B7CB92E>83
+D<3FFFFFFFFFFFE03FFFFFFFFFFFE03FFFFFFFFFFFE03FC003FE001FE03E0001FC0003E0
+7C0001FC0001F0780001FC0000F0700001FC000070700001FC000070700001FC00007060
+0001FC000030600001FC000030600001FC000030600001FC000030E00001FC000038C000
+01FC000018C00001FC000018C00001FC000018C00001FC000018000001FC000000000001
+FC000000000001FC000000000001FC000000000001FC000000000001FC000000000001FC
+000000000001FC000000000001FC000000000001FC000000000001FC000000000001FC00
+0000000001FC000000000001FC000000000001FC000000000001FC000000000001FC0000
+00000001FC000000000001FC000000000001FC000000000001FC000000000001FC000000
+000001FC000000000001FC000000000001FC000000000001FC000000000001FC00000000
+0001FC000000000001FC000000000001FC000000000001FC000000000001FC0000000000
+01FC000000000001FC000000000007FF000000001FFFFFFFC000001FFFFFFFC000001FFF
+FFFFC00035397DB83C>I<FFFFFE0007FFFEFFFFFE0007FFFEFFFFFE0007FFFE01FF0000
+007FE000FE0000001F8000FE0000000F0000FE000000060000FE000000060000FE000000
+060000FE000000060000FE000000060000FE000000060000FE000000060000FE00000006
+0000FE000000060000FE000000060000FE000000060000FE000000060000FE0000000600
+00FE000000060000FE000000060000FE000000060000FE000000060000FE000000060000
+FE000000060000FE000000060000FE000000060000FE000000060000FE000000060000FE
+000000060000FE000000060000FE000000060000FE000000060000FE000000060000FE00
+0000060000FE000000060000FE000000060000FE000000060000FE000000060000FE0000
+00060000FE000000060000FE0000000600007E0000000E00007E0000000C00007F000000
+0C00003F0000001C00003F0000001800001F8000003800001F8000003000000FC0000060
+000007C00000E0000003E00001C0000001F8000380000000FC000F000000007F807E0000
+00001FFFF80000000007FFE00000000000FF800000373A7DB83E>I<FFFFF803FFFFF001
+FFFFFFFFF803FFFFF001FFFFFFFFF803FFFFF001FFFF07FF00000FFC00001FF803FC0000
+07F8000007E001FC000003F8000003C001FC000003F80000038001FE000003F800000380
+00FE000001FC0000030000FE000001FC0000030000FF000001FC00000300007F000003FE
+00000600007F000003FE00000600007F000003FE00000600003F800007FF00000C00003F
+8000067F00000C00003F8000067F00000C00001FC0000E7F80001800001FC0000C3F8000
+1800001FC0000C3F80001800000FE0001C3FC0003000000FE000181FC0003000000FE000
+181FC00030000007F000181FC00060000007F000300FE00060000007F000300FE0006000
+0007F800300FE000E0000003F8006007F000C0000003F8006007F000C0000003FC006007
+F001C0000001FC00C003F80180000001FC00C003F80180000001FE00C003F80380000000
+FE018001FC0300000000FE018001FC0300000000FE018001FC03000000007F030000FE06
+000000007F030000FE06000000007F030000FE06000000003F870000FF0C000000003F86
+00007F0C000000003F8600007F0C000000001FCE00007F98000000001FCC00003F980000
+00001FCC00003F98000000000FEC00003FB0000000000FF800001FF0000000000FF80000
+1FF00000000007F800001FE00000000007F000000FE00000000007F000000FE000000000
+07F000000FE00000000003E0000007C00000000003E0000007C00000000003E0000007C0
+0000000001C0000003800000000001C0000003800000000001C0000003800000503A7EB8
+55>87 D<7FFFFE001FFFFC007FFFFE001FFFFC007FFFFE001FFFFC0000FFF00007FF8000
+003FC00001FC0000003FC00000F00000001FE00000E00000001FE00000C00000000FF000
+018000000007F800038000000007F800030000000003FC00060000000001FE000E000000
+0001FE000C0000000000FF001800000000007F003800000000007F803000000000003FC0
+6000000000001FC0E000000000001FE0C000000000000FF180000000000007F380000000
+000007FB00000000000003FE00000000000001FE00000000000001FE00000000000000FF
+000000000000007F000000000000007F800000000000007FC0000000000000FFC0000000
+000000DFE00000000000018FF00000000000038FF000000000000307F800000000000603
+FC00000000000E03FC00000000000C01FE00000000001800FE00000000003800FF000000
+000030007F800000000060003F8000000000E0003FC000000000C0001FE0000000018000
+0FE00000000380000FF000000003000007F800000006000003F80000000E000003FC0000
+000C000001FE0000001C000000FE0000003C000000FF000000FE000000FF800007FF0000
+03FFC000FFFFE0001FFFFF80FFFFE0001FFFFF80FFFFE0001FFFFF8039397EB83E>I<FF
+F8FFF8FFF8FFF8F000F000F000F000F000F000F000F000F000F000F000F000F000F000F0
+00F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F0
+00F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F0
+00F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F0
+00F000F000F000F000F000F000FFF8FFF8FFF8FFF80D5378BD17>91
+D<0100010003000300060006000C000C000C000C00180018003000300030003000300030
+00600060006000600060006000C000C000C000C000C000C000C000C000CE00CE00FF80FF
+80FF80FF80FFC0FFC07FC07FC07FC07FC03F803F801F801F800E000E001A1974B92A>I<
+FFF8FFF8FFF8FFF800780078007800780078007800780078007800780078007800780078
+007800780078007800780078007800780078007800780078007800780078007800780078
+007800780078007800780078007800780078007800780078007800780078007800780078
+007800780078007800780078007800780078007800780078007800780078007800780078
+0078007800780078007800780078FFF8FFF8FFF8FFF80D537FBD17>I<001FE0000000FF
+FC000003E03F000007000F80000F8007C0000FC003E0001FE001F0001FE001F8001FE001
+F8001FE000F8000FC000FC00078000FC00000000FC00000000FC00000000FC00000000FC
+0000007FFC000007FFFC00003FE0FC0000FE00FC0003F800FC0007E000FC000FC000FC00
+1F8000FC003F0000FC007F0000FC007F0000FC0CFE0000FC0CFE0000FC0CFE0000FC0CFE
+0001FC0CFE0001FC0C7E0001FC0C7F00037C0C3F00063E181F800C3E180FE0781FF003FF
+F00FE0007F8007C026277DA52A>97 D<03F0000000FFF0000000FFF0000000FFF0000000
+0FF000000003F000000003F000000003F000000003F000000003F000000003F000000003
+F000000003F000000003F000000003F000000003F000000003F000000003F000000003F0
+00000003F000000003F000000003F01FE00003F07FF80003F1E03E0003F3800F0003F600
+078003FC0003C003F80003E003F80001F003F00001F803F00000FC03F00000FC03F00000
+FE03F000007E03F000007E03F000007E03F000007F03F000007F03F000007F03F000007F
+03F000007F03F000007F03F000007F03F000007F03F000007E03F000007E03F00000FE03
+F00000FC03F00000FC03F00000F803F00001F803F80001F003F80003E003EC0007C003C6
+00078003C3001F000381E07E000300FFF80000001FC000283B7EB92E>I<0003FC00001F
+FF80007E03E000F8007001E000F803E001F807C003FC0F8003FC1F8003FC1F8003FC3F00
+01F83F0000F07F0000007E0000007E000000FE000000FE000000FE000000FE000000FE00
+0000FE000000FE000000FE000000FE0000007E0000007E0000007F0000007F0000003F00
+00063F0000061F80000C0F80000C07C0001803E0001801E0003000F800E0007C07C0001F
+FF000007F8001F277DA525>I<0000000FC0000003FFC0000003FFC0000003FFC0000000
+3FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000F
+C00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC0
+0000000FC00000000FC00003F80FC0001FFF0FC0007E078FC000F800CFC001E0006FC003
+E0003FC007C0001FC00F80001FC01F80000FC01F00000FC03F00000FC03F00000FC07F00
+000FC07E00000FC07E00000FC0FE00000FC0FE00000FC0FE00000FC0FE00000FC0FE0000
+0FC0FE00000FC0FE00000FC0FE00000FC07E00000FC07E00000FC07E00000FC07F00000F
+C03F00000FC03F00000FC01F80000FC00F80001FC007C0003FC003C0003FC001E0006FF0
+00F001CFFF007C078FFF001FFE0FFF0007F80FC0283B7DB92E>I<0007F800001FFF0000
+7C0F8000F003C001E001E003C000F007C000F80F80007C1F80007C1F00007E3F00003E3F
+00003E7E00003F7E00003F7E00003FFE00003FFE00003FFFFFFFFFFFFFFFFFFE000000FE
+000000FE000000FE000000FE0000007E0000007E0000007F0000003F0000003F0000031F
+0000031F8000060F80000607C0000C03E0000C01F0003800F80070003E03C0001FFF8000
+03FC0020277EA525>I<00007E000003FF800007C1C0000F07E0001E07F0003E0FF0007C
+0FF000FC0FF000FC07E000F803C001F8000001F8000001F8000001F8000001F8000001F8
+000001F8000001F8000001F8000001F8000001F8000001F8000001F80000FFFFFC00FFFF
+FC00FFFFFC0001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8
+000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8
+000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8
+000001F8000001F8000001F8000003FC00007FFFF8007FFFF8007FFFF8001C3B7FBA19>
+I<000FF003F0003FFC1FF800F81F7C7C01F00FE07C03E007C03807C003E01007C003E000
+0F8001F0000F8001F0001F8001F8001F8001F8001F8001F8001F8001F8001F8001F8001F
+8001F8000F8001F0000F8001F00007C003E00007C003E00003E007C00001F00F800003F8
+1F0000063FFC0000060FF000000E000000000E000000000E000000000E000000000F0000
+00000F00000000078000000007FFFFC00003FFFFF80001FFFFFE0000FFFFFF8003FFFFFF
+C00F80007FE01E00000FE03E000003F07C000001F07C000001F8F8000000F8F8000000F8
+F8000000F8F8000000F8F8000000F87C000001F07C000001F03E000003E01F000007C00F
+80000F8007E0003F0001FC01FC00007FFFF0000007FF000026377EA42A>I<03F0000000
+00FFF000000000FFF000000000FFF0000000000FF00000000003F00000000003F0000000
+0003F00000000003F00000000003F00000000003F00000000003F00000000003F0000000
+0003F00000000003F00000000003F00000000003F00000000003F00000000003F0000000
+0003F00000000003F00000000003F00FF0000003F03FFC000003F0F03E000003F1C01F00
+0003F3000F800003F6000FC00003F60007C00003FC0007E00003F80007E00003F80007E0
+0003F80007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E0
+0003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E0
+0003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E0
+0003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00007F8000FF0
+00FFFFC1FFFF80FFFFC1FFFF80FFFFC1FFFF80293A7EB92E>I<03800007C0000FE0001F
+F0001FF0001FF0000FE00007C00003800000000000000000000000000000000000000000
+000000000000000000000003F000FFF000FFF000FFF00007F00003F00003F00003F00003
+F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003
+F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003
+F00007F800FFFFC0FFFFC0FFFFC012387EB717>I<0001C00003E00007F0000FF8000FF8
+000FF80007F00003E00001C0000000000000000000000000000000000000000000000000
+0000000000000001F800FFF800FFF800FFF80007F80001F80001F80001F80001F80001F8
+0001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F8
+0001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F8
+0001F80001F80001F80001F80001F80001F80001F80001F80001F83C01F87E01F8FF01F0
+FF03F0FF03E0FF03E07E07C07C07803C0F000FFE0003F800154984B719>I<03F0000000
+FFF0000000FFF0000000FFF00000000FF000000003F000000003F000000003F000000003
+F000000003F000000003F000000003F000000003F000000003F000000003F000000003F0
+00000003F000000003F000000003F000000003F000000003F000000003F000000003F001
+FFFC03F001FFFC03F001FFFC03F0007FC003F0003E0003F000380003F000700003F000E0
+0003F001C00003F003000003F006000003F00C000003F018000003F038000003F0F80000
+03F1FC000003F37E000003F63F000003FC1F000003F81F800003F00FC00003F007C00003
+F007E00003F003F00003F001F80003F000F80003F000FC0003F0007E0003F0003E0003F0
+003F0003F0001F8003F0001FC007F8003FF0FFFFC0FFFFFFFFC0FFFFFFFFC0FFFF283A7E
+B92C>I<03F000FFF000FFF000FFF0000FF00003F00003F00003F00003F00003F00003F0
+0003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F0
+0003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F0
+0003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F0
+0003F00003F00003F00003F00003F00003F00003F00007F800FFFFC0FFFFC0FFFFC0123A
+7EB917>I<03F00FF0001FE000FFF03FFC007FF800FFF0F03E01E07C00FFF1C01F03803E
+000FF3000F86001F0003F6000FCC001F8003F60007CC000F8003FC0007F8000FC003F800
+07F0000FC003F80007F0000FC003F80007F0000FC003F00007E0000FC003F00007E0000F
+C003F00007E0000FC003F00007E0000FC003F00007E0000FC003F00007E0000FC003F000
+07E0000FC003F00007E0000FC003F00007E0000FC003F00007E0000FC003F00007E0000F
+C003F00007E0000FC003F00007E0000FC003F00007E0000FC003F00007E0000FC003F000
+07E0000FC003F00007E0000FC003F00007E0000FC003F00007E0000FC003F00007E0000F
+C003F00007E0000FC003F00007E0000FC007F8000FF0001FE0FFFFC1FFFF83FFFFFFFFC1
+FFFF83FFFFFFFFC1FFFF83FFFF40257EA445>I<03F00FF00000FFF03FFC0000FFF0F03E
+0000FFF1C01F00000FF3000F800003F6000FC00003F60007C00003FC0007E00003F80007
+E00003F80007E00003F80007E00003F00007E00003F00007E00003F00007E00003F00007
+E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007
+E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007
+E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007
+E00007F8000FF000FFFFC1FFFF80FFFFC1FFFF80FFFFC1FFFF8029257EA42E>I<0003FE
+0000000FFF8000003E03E00000F800F80001F0007C0003E0003E0007C0001F000F80000F
+801F80000FC01F000007C03F000007E03F000007E07E000003F07E000003F07E000003F0
+7E000003F0FE000003F8FE000003F8FE000003F8FE000003F8FE000003F8FE000003F8FE
+000003F8FE000003F8FE000003F87E000003F07E000003F07F000007F03F000007E03F00
+0007E01F80000FC00F80000F800FC0001F8007E0003F0003F0007E0000F800F800007E03
+F000001FFFC0000003FE000025277EA52A>I<03F01FE000FFF07FF800FFF1E07E00FFF3
+801F0007F6000F8003FC0007C003F80003E003F80003F003F00001F803F00001FC03F000
+00FC03F00000FE03F00000FE03F00000FE03F000007E03F000007F03F000007F03F00000
+7F03F000007F03F000007F03F000007F03F000007F03F000007F03F000007E03F00000FE
+03F00000FE03F00000FC03F00000FC03F00001F803F00001F803F80003F003F80003E003
+FC0007C003F6000F8003F3001F0003F1E07E0003F0FFF80003F01FC00003F000000003F0
+00000003F000000003F000000003F000000003F000000003F000000003F000000003F000
+000003F000000003F000000007F8000000FFFFC00000FFFFC00000FFFFC0000028357EA4
+2E>I<0003F800C0001FFE01C0007E0781C000F801C3C001F00063C003E00067C007C000
+37C00FC0001FC01F80001FC01F80001FC03F00000FC03F00000FC07F00000FC07F00000F
+C07E00000FC0FE00000FC0FE00000FC0FE00000FC0FE00000FC0FE00000FC0FE00000FC0
+FE00000FC0FE00000FC07E00000FC07F00000FC07F00000FC07F00000FC03F00000FC03F
+80000FC01F80001FC00FC0001FC007C0003FC003E0006FC001F000CFC000F8018FC0007E
+070FC0001FFE0FC00007F80FC00000000FC00000000FC00000000FC00000000FC0000000
+0FC00000000FC00000000FC00000000FC00000000FC00000000FC00000000FC00000001F
+E0000003FFFF000003FFFF000003FFFF28357DA42C>I<07E01F00FFE07FC0FFE0E3E0FF
+E183F00FE307F003E607F003E607F003EC03E003EC008003F8000003F8000003F8000003
+F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003
+F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003F0000003
+F0000003F0000003F0000007F80000FFFFF000FFFFF000FFFFF0001C257EA421>I<00FF
+030003FFE7000F80FF001C001F0038000F0078000F0070000700F0000700F0000300F000
+0300F0000300F8000300FC0003007E0000007FE000003FFF00003FFFE0001FFFF00007FF
+FC0003FFFE0000FFFF000007FF0000007F8000001F8040000FC0C00007C0C00007C0E000
+03C0E00003C0E00003C0F00003C0F0000380F8000380F8000700FC000600F6001E00E3C0
+7800C1FFF000C03F80001A277DA521>I<00180000001800000018000000180000001800
+0000380000003800000038000000780000007800000078000000F8000001F8000003F800
+0007F800001FFFFF00FFFFFF00FFFFFF0001F8000001F8000001F8000001F8000001F800
+0001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F800
+0001F8000001F8000001F8000001F8000001F800C001F800C001F800C001F800C001F800
+C001F800C001F800C001F800C001F800C000F8018000FC0180007C0180003E0300001F06
+00000FFC000001F8001A347FB220>I<03F00007E000FFF001FFE000FFF001FFE000FFF0
+01FFE0000FF0001FE00003F00007E00003F00007E00003F00007E00003F00007E00003F0
+0007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F0
+0007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F0
+0007E00003F00007E00003F00007E00003F00007E00003F00007E00003F00007E00003F0
+0007E00003F0000FE00003F0000FE00003F0000FE00001F0001FE00001F00037E00000F8
+0037F800007C00E7FF80003F03C7FF80001FFF07FF800003FC07E00029267EA42E>I<FF
+FF803FFEFFFF803FFEFFFF803FFE07F8000FF003F00003C003F000038003F800038001F8
+00030001F800030000FC00060000FC00060000FE000E00007E000C00007E000C00003F00
+1800003F001800003F803800001F803000001F803000000FC06000000FC06000000FE060
+000007E0C0000007E0C0000003F180000003F180000003F180000001FB00000001FB0000
+0001FF00000000FE00000000FE000000007C000000007C000000007C0000000038000000
+0038000027257EA32C>I<FFFF1FFFE03FFEFFFF1FFFE03FFEFFFF1FFFE03FFE0FF800FF
+0007F807F0007E0003E003F0007E0001C003F0003E00018003F0003E00018001F8003F00
+030001F8003F00030001F8003F00030000FC003F80060000FC006F80060000FC006F8006
+00007E00EFC00C00007E00C7C00C00007E00C7C00C00003F01C7E01800003F0183E01800
+003F8183F03800001F8383F03000001F8301F03000001FC301F87000000FC600F8600000
+0FC600F860000007E600FCC0000007EC007CC0000007EC007CC0000003FC007F80000003
+F8003F80000003F8003F80000001F8003F00000001F0001F00000001F0001F00000000F0
+001E00000000E0000E0000000060000C000037257EA33C>I<FFFF807FFF00FFFF807FFF
+00FFFF807FFF0003FE001FE00000FC001F800000FE000E0000007E001C0000003F001800
+00001F80300000001FC0700000000FC0E000000007E0C000000007F18000000003FB8000
+000001FF0000000000FE0000000000FE00000000007F00000000003F00000000007F8000
+0000007FC000000000CFC000000001C7E00000000383F00000000703F80000000601F800
+00000C00FC0000001C007E00000038007F00000030003F000000F0001F800001F0001FC0
+000FF8003FE000FFFE00FFFF80FFFE00FFFF80FFFE00FFFF8029247FA32C>I<FFFF803F
+FEFFFF803FFEFFFF803FFE07F8000FF003F00003C003F000038001F800038001F8000300
+01FC00030000FC00060000FC000600007E000C00007E000C00007F000C00003F00180000
+3F001800001F803000001F803000001FC07000000FC06000000FC060000007E0C0000007
+E0C0000007F1C0000003F180000003F180000001FB00000001FB00000001FF00000000FE
+00000000FE000000007C000000007C000000007C00000000380000000038000000003000
+0000003000000000700000000060000000006000000000C000000000C000007C01C00000
+FE01800000FE03800000FE03000000FE06000000FC0E000000701C00000038380000001F
+F00000000FC000000027357EA32C>I<3FFFFFFC3FFFFFFC3F8001F83E0003F03C0007F0
+380007E030000FC070001FC070001F8060003F0060007F006000FE006000FC006001F800
+0003F8000003F0000007E000000FE000001FC000001F8000003F0000007F0006007E0006
+00FC000601FC000603F8000603F0000E07E0000E0FE0000C0FC0001C1F80001C3F80003C
+3F00007C7E0003FCFFFFFFFCFFFFFFFC1F247EA325>I<01E0004007F800E00FFE01C01F
+FF87803C3FFF00700FFE00E003FC004000F0001B0879B62A>126
+D E /Fo 28 125 df<FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0FFFF
+FFFFF0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0FFFFFFFFF0240B7F9F2D>45
+D<00000000001F00000000000000000000003F80000000000000000000007FC000000000
+0000000000007FC000000000000000000000FFE000000000000000000000FFE000000000
+000000000000FFE000000000000000000001FFF000000000000000000001FFF000000000
+000000000003FFF800000000000000000003FFF800000000000000000003FFF800000000
+000000000007FFFC00000000000000000007FFFC0000000000000000000FFFFE00000000
+00000000000FFFFE0000000000000000000FFFFE0000000000000000001FFFFF00000000
+00000000001FFFFF0000000000000000003FFFFF8000000000000000003FFFFF80000000
+00000000003F7FFF8000000000000000007F7FFFC000000000000000007E3FFFC0000000
+0000000000FE3FFFE00000000000000000FC3FFFE00000000000000000FC1FFFE0000000
+0000000001FC1FFFF00000000000000001F80FFFF00000000000000003F80FFFF8000000
+0000000003F00FFFF80000000000000003F007FFF80000000000000007F007FFFC000000
+0000000007E003FFFC000000000000000FE003FFFE000000000000000FC003FFFE000000
+000000000FC001FFFE000000000000001FC001FFFF000000000000001F8000FFFF000000
+000000003F8000FFFF800000000000003F0000FFFF800000000000003F00007FFF800000
+000000007F00007FFFC00000000000007E00003FFFC0000000000000FE00003FFFE00000
+00000000FC00003FFFE0000000000000FC00001FFFE0000000000001FC00001FFFF00000
+00000001F800000FFFF0000000000003F800000FFFF8000000000003F000000FFFF80000
+00000003F0000007FFF8000000000007F0000007FFFC000000000007E0000003FFFC0000
+0000000FE0000003FFFE00000000000FFFFFFFFFFFFE00000000000FFFFFFFFFFFFE0000
+0000001FFFFFFFFFFFFF00000000001FFFFFFFFFFFFF00000000003FFFFFFFFFFFFF8000
+0000003F00000000FFFF80000000003F000000007FFF80000000007F000000007FFFC000
+0000007E000000003FFFC000000000FE000000003FFFE000000000FC000000003FFFE000
+000000FC000000001FFFE000000001FC000000001FFFF000000001F8000000000FFFF000
+000003F8000000000FFFF800000003F0000000000FFFF800000003F00000000007FFF800
+000007F00000000007FFFC00000007E00000000003FFFC0000000FE00000000003FFFE00
+00000FC00000000003FFFE0000001FC00000000001FFFE000000FFFC0000000001FFFF00
+00FFFFFFF800000FFFFFFFFFE0FFFFFFF800000FFFFFFFFFE0FFFFFFF800000FFFFFFFFF
+E0FFFFFFF800000FFFFFFFFFE0FFFFFFF800000FFFFFFFFFE05B537BD266>65
+D<0000000001FFF8000001C0000000007FFFFF800003C000000003FFFFFFF00007C00000
+001FFFFFFFFC001FC0000000FFFFFFFFFF003FC0000003FFFFE001FFC07FC000000FFFFC
+00003FF0FFC000003FFFE0000007F9FFC000007FFF80000003FFFFC00000FFFE00000000
+FFFFC00003FFF8000000007FFFC00007FFF0000000003FFFC0000FFFE0000000001FFFC0
+001FFFC0000000000FFFC0003FFF800000000007FFC0007FFF000000000003FFC000FFFE
+000000000001FFC000FFFC000000000001FFC001FFFC000000000000FFC003FFF8000000
+0000007FC003FFF80000000000007FC007FFF00000000000003FC007FFF0000000000000
+3FC00FFFE00000000000003FC00FFFE00000000000001FC01FFFE00000000000001FC01F
+FFE00000000000001FC03FFFC00000000000000FC03FFFC00000000000000FC03FFFC000
+00000000000FC03FFFC00000000000000FC07FFFC00000000000000FC07FFF8000000000
+000000007FFF8000000000000000007FFF800000000000000000FFFF8000000000000000
+00FFFF800000000000000000FFFF800000000000000000FFFF800000000000000000FFFF
+800000000000000000FFFF800000000000000000FFFF800000000000000000FFFF800000
+000000000000FFFF800000000000000000FFFF800000000000000000FFFF800000000000
+000000FFFF800000000000000000FFFF800000000000000000FFFF800000000000000000
+7FFF8000000000000000007FFF8000000000000000007FFF8000000000000000007FFFC0
+00000000000000003FFFC000000000000007C03FFFC000000000000007C03FFFC0000000
+00000007C03FFFC000000000000007C01FFFE000000000000007C01FFFE0000000000000
+07C00FFFE00000000000000FC00FFFE00000000000000F8007FFF00000000000000F8007
+FFF00000000000000F8003FFF80000000000001F0003FFF80000000000001F0001FFFC00
+00000000003E0000FFFC0000000000003E0000FFFE0000000000007C00007FFF00000000
+0000FC00003FFF800000000001F800001FFFC00000000003F000000FFFE00000000007F0
+000007FFF0000000000FE0000003FFF8000000001FC0000000FFFE000000003F80000000
+7FFF80000000FF000000003FFFE0000003FC000000000FFFFC00001FF80000000003FFFF
+E001FFE00000000000FFFFFFFFFF8000000000001FFFFFFFFE00000000000003FFFFFFF8
+000000000000007FFFFFC00000000000000001FFFC00000000525479D261>67
+D<FFFFFFFFFFFFFFFFFF80FFFFFFFFFFFFFFFFFF80FFFFFFFFFFFFFFFFFF80FFFFFFFFFF
+FFFFFFFF80FFFFFFFFFFFFFFFFFF800007FFF8000001FFFFC00007FFF80000001FFFC000
+07FFF800000007FFC00007FFF800000001FFC00007FFF800000000FFC00007FFF8000000
+007FC00007FFF8000000003FC00007FFF8000000001FC00007FFF8000000001FC00007FF
+F8000000000FE00007FFF8000000000FE00007FFF80000000007E00007FFF80000000007
+E00007FFF80000000007E00007FFF80000000003E00007FFF80000000003E00007FFF800
+00000003E00007FFF80000F80003E00007FFF80000F80003F00007FFF80000F80001F000
+07FFF80000F80001F00007FFF80000F80001F00007FFF80000F80001F00007FFF80000F8
+0000000007FFF80001F80000000007FFF80001F80000000007FFF80001F80000000007FF
+F80003F80000000007FFF80007F80000000007FFF8000FF80000000007FFF8007FF80000
+000007FFFFFFFFF80000000007FFFFFFFFF80000000007FFFFFFFFF80000000007FFFFFF
+FFF80000000007FFFFFFFFF80000000007FFF8007FF80000000007FFF8000FF800000000
+07FFF80007F80000000007FFF80003F80000000007FFF80001F80000000007FFF80001F8
+0000000007FFF80001F80000000007FFF80000F80000000007FFF80000F800003E0007FF
+F80000F800003E0007FFF80000F800003E0007FFF80000F800007C0007FFF80000F80000
+7C0007FFF80000F800007C0007FFF800000000007C0007FFF800000000007C0007FFF800
+00000000FC0007FFF80000000000FC0007FFF80000000000F80007FFF80000000000F800
+07FFF80000000001F80007FFF80000000001F80007FFF80000000001F80007FFF8000000
+0003F80007FFF80000000003F00007FFF80000000007F00007FFF8000000000FF00007FF
+F8000000000FF00007FFF8000000001FF00007FFF8000000003FF00007FFF8000000007F
+E00007FFF800000001FFE00007FFF800000007FFE00007FFF80000001FFFE00007FFF800
+0003FFFFE0FFFFFFFFFFFFFFFFFFE0FFFFFFFFFFFFFFFFFFE0FFFFFFFFFFFFFFFFFFC0FF
+FFFFFFFFFFFFFFFFC0FFFFFFFFFFFFFFFFFFC04F517CD058>69 D<FFFFFFFFFFC003FFFF
+FFFFFFFFFFFFFFFFC003FFFFFFFFFFFFFFFFFFFFC003FFFFFFFFFFFFFFFFFFFFC003FFFF
+FFFFFFFFFFFFFFFFC003FFFFFFFFFF0007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFFFFFFFFFFFFFFFE0000007FFFFFFFFFFFFFFFFE0000007FFFFFFFFFFFFFF
+FFE0000007FFFFFFFFFFFFFFFFE0000007FFFFFFFFFFFFFFFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE0000007FFF8000000001FFFE0000007FFF8000000001F
+FFE0000007FFF8000000001FFFE000FFFFFFFFFFC003FFFFFFFFFFFFFFFFFFFFC003FFFF
+FFFFFFFFFFFFFFFFC003FFFFFFFFFFFFFFFFFFFFC003FFFFFFFFFFFFFFFFFFFFC003FFFF
+FFFFFF60527CD169>72 D<FFFFFFFFFFFFFF000000FFFFFFFFFFFFFFF80000FFFFFFFFFF
+FFFFFF0000FFFFFFFFFFFFFFFFE000FFFFFFFFFFFFFFFFF0000007FFF000001FFFFC0000
+07FFF0000001FFFF000007FFF00000007FFF800007FFF00000003FFFC00007FFF0000000
+0FFFE00007FFF00000000FFFF00007FFF000000007FFF00007FFF000000003FFF80007FF
+F000000003FFFC0007FFF000000003FFFC0007FFF000000001FFFE0007FFF000000001FF
+FE0007FFF000000001FFFE0007FFF000000001FFFE0007FFF000000001FFFF0007FFF000
+000001FFFF0007FFF000000001FFFF0007FFF000000001FFFF0007FFF000000001FFFF00
+07FFF000000001FFFF0007FFF000000001FFFF0007FFF000000001FFFF0007FFF0000000
+01FFFE0007FFF000000001FFFE0007FFF000000001FFFE0007FFF000000001FFFC0007FF
+F000000003FFFC0007FFF000000003FFFC0007FFF000000003FFF80007FFF000000007FF
+F00007FFF00000000FFFE00007FFF00000001FFFE00007FFF00000003FFFC00007FFF000
+00007FFF000007FFF0000001FFFE000007FFF000001FFFFC000007FFFFFFFFFFFFF00000
+07FFFFFFFFFFFFC0000007FFFFFFFFFFFE00000007FFFFFFFFFFE000000007FFF8000000
+0000000007FFF80000000000000007FFF80000000000000007FFF80000000000000007FF
+F80000000000000007FFF80000000000000007FFF80000000000000007FFF80000000000
+000007FFF80000000000000007FFF80000000000000007FFF80000000000000007FFF800
+00000000000007FFF80000000000000007FFF80000000000000007FFF800000000000000
+07FFF80000000000000007FFF80000000000000007FFF80000000000000007FFF8000000
+0000000007FFF80000000000000007FFF80000000000000007FFF80000000000000007FF
+F80000000000000007FFF80000000000000007FFF80000000000000007FFF80000000000
+000007FFF80000000000000007FFF80000000000000007FFF80000000000000007FFF800
+00000000000007FFF80000000000000007FFF8000000000000FFFFFFFFFFC000000000FF
+FFFFFFFFC000000000FFFFFFFFFFC000000000FFFFFFFFFFC000000000FFFFFFFFFFC000
+00000050527CD15C>80 D<00000FFF800007000000FFFFF8000F000003FFFFFF001F0000
+0FFFFFFFC03F00003FFFFFFFF07F00007FF800FFF8FF0001FFC00007FDFF0003FF000001
+FFFF0007FE0000007FFF0007FC0000003FFF000FF80000000FFF001FF000000007FF001F
+F000000003FF003FF000000001FF003FE000000001FF007FE000000000FF007FE0000000
+00FF007FE0000000007F007FE0000000007F00FFE0000000003F00FFE0000000003F00FF
+F0000000003F00FFF0000000001F00FFF0000000001F00FFF8000000001F00FFFC000000
+001F00FFFE000000001F00FFFF0000000000007FFFC000000000007FFFF000000000007F
+FFFF00000000003FFFFFF0000000003FFFFFFF800000001FFFFFFFF80000001FFFFFFFFF
+8000000FFFFFFFFFF000000FFFFFFFFFFC000007FFFFFFFFFF000003FFFFFFFFFF800001
+FFFFFFFFFFE00000FFFFFFFFFFF000007FFFFFFFFFF800001FFFFFFFFFFC00000FFFFFFF
+FFFE000003FFFFFFFFFE000000FFFFFFFFFF0000000FFFFFFFFF80000000FFFFFFFF8000
+000007FFFFFFC0000000007FFFFFC00000000003FFFFC000000000007FFFE00000000000
+3FFFE000000000000FFFE0000000000007FFF0000000000003FFF0000000000001FFF078
+0000000001FFF0F80000000000FFF0F80000000000FFF0F80000000000FFF0F800000000
+007FF0F800000000007FF0FC00000000007FF0FC00000000007FE0FC00000000007FE0FC
+00000000007FE0FE00000000007FE0FE00000000007FC0FF0000000000FFC0FF80000000
+00FF80FFC000000000FF80FFE000000001FF00FFF000000003FF00FFF800000003FE00FF
+FE00000007FC00FFFFC000001FF800FFFFF800003FF000FF1FFFC003FFE000FE07FFFFFF
+FFC000FC01FFFFFFFF0000F8007FFFFFFC0000F00007FFFFE00000E000003FFE0000003C
+5479D24B>83 D<3FFFFFFFFFFFFFFFFFFF803FFFFFFFFFFFFFFFFFFF803FFFFFFFFFFFFF
+FFFFFF803FFFFFFFFFFFFFFFFFFF803FFFFFFFFFFFFFFFFFFF803FFFC0003FFFC0007FFF
+803FFE00003FFFC00007FF807FF800003FFFC00001FFC07FE000003FFFC00000FFC07FC0
+00003FFFC000007FC07F8000003FFFC000003FC07F0000003FFFC000001FC07F0000003F
+FFC000001FC07E0000003FFFC000000FC07E0000003FFFC000000FC07E0000003FFFC000
+000FC07C0000003FFFC0000007C07C0000003FFFC0000007C07C0000003FFFC0000007C0
+7C0000003FFFC0000007C07C0000003FFFC0000007C0FC0000003FFFC0000007E0F80000
+003FFFC0000003E0F80000003FFFC0000003E0F80000003FFFC0000003E0F80000003FFF
+C0000003E0F80000003FFFC0000003E0F80000003FFFC0000003E0000000003FFFC00000
+0000000000003FFFC000000000000000003FFFC000000000000000003FFFC00000000000
+0000003FFFC000000000000000003FFFC000000000000000003FFFC00000000000000000
+3FFFC000000000000000003FFFC000000000000000003FFFC000000000000000003FFFC0
+00000000000000003FFFC000000000000000003FFFC000000000000000003FFFC0000000
+00000000003FFFC000000000000000003FFFC000000000000000003FFFC0000000000000
+00003FFFC000000000000000003FFFC000000000000000003FFFC000000000000000003F
+FFC000000000000000003FFFC000000000000000003FFFC000000000000000003FFFC000
+000000000000003FFFC000000000000000003FFFC000000000000000003FFFC000000000
+000000003FFFC000000000000000003FFFC000000000000000003FFFC000000000000000
+003FFFC000000000000000003FFFC000000000000000003FFFC000000000000000003FFF
+C000000000000000003FFFC000000000000000003FFFC000000000000000003FFFC00000
+0000000000003FFFC000000000000000003FFFC000000000000000003FFFC00000000000
+0000003FFFC000000000000000003FFFC000000000000000003FFFC00000000000000000
+3FFFC000000000000000003FFFC000000000000000003FFFC000000000000000003FFFC0
+00000000000000003FFFC0000000000000FFFFFFFFFFFFF000000000FFFFFFFFFFFFF000
+000000FFFFFFFFFFFFF000000000FFFFFFFFFFFFF000000000FFFFFFFFFFFFF000005351
+7BD05E>I<0003FFFF00000000003FFFFFF800000000FFFFFFFE00000001FFFFFFFF8000
+0003FF0007FFE0000007FF8000FFF0000007FF80007FFC00000FFFC0003FFC00000FFFC0
+001FFE00000FFFC0000FFF00000FFFC0000FFF00000FFFC0000FFF800007FF800007FF80
+0007FF800007FFC00003FF000007FFC00000FC000007FFC0000000000007FFC000000000
+0007FFC0000000000007FFC0000000000007FFC0000000000007FFC0000000000007FFC0
+000000007FFFFFC00000000FFFFFFFC0000000FFFFFFFFC0000007FFFF07FFC000001FFF
+C007FFC000007FFE0007FFC00001FFF80007FFC00003FFE00007FFC0000FFFC00007FFC0
+001FFF800007FFC0001FFF000007FFC0003FFE000007FFC0007FFC000007FFC0007FFC00
+0007FFC0007FF8000007FFC000FFF8000007FFC000FFF8000007FFC000FFF8000007FFC0
+00FFF8000007FFC000FFF800000FFFC000FFF800000FFFC0007FFC00001DFFC0007FFC00
+003DFFC0003FFE000079FFC0003FFF0000F9FFE0001FFF8001F1FFF80007FFF00FE0FFFF
+E003FFFFFF807FFFF000FFFFFF003FFFF0001FFFFC001FFFF00001FFE00007FFE03C357C
+B441>97 D<000001FFFE000000001FFFFFF0000000FFFFFFFC000003FFFFFFFE00000FFF
+8003FF00003FFC0007FF80007FF80007FF8000FFF0000FFFC001FFE0000FFFC003FFC000
+0FFFC007FF80000FFFC00FFF00000FFFC00FFF000007FF801FFF000007FF801FFE000003
+FF003FFE000000FC003FFE00000000003FFE00000000007FFC00000000007FFC00000000
+007FFC0000000000FFFC0000000000FFFC0000000000FFFC0000000000FFFC0000000000
+FFFC0000000000FFFC0000000000FFFC0000000000FFFC0000000000FFFC0000000000FF
+FC0000000000FFFC00000000007FFC00000000007FFC00000000007FFE00000000003FFE
+00000000003FFE00000000003FFE00000000001FFF00000003E01FFF00000003E00FFF00
+000003E00FFF80000007C007FFC0000007C003FFC000000F8001FFE000001F8000FFF000
+003F00007FFC0000FE00003FFE0001FC00000FFFC00FF8000003FFFFFFE0000000FFFFFF
+800000001FFFFE0000000001FFE0000033357CB43C>99 D<000000000001FF8000000000
+0007FFFF80000000000007FFFF80000000000007FFFF80000000000007FFFF8000000000
+0007FFFF800000000000001FFF8000000000000007FF8000000000000007FF8000000000
+000007FF8000000000000007FF8000000000000007FF8000000000000007FF8000000000
+000007FF8000000000000007FF8000000000000007FF8000000000000007FF8000000000
+000007FF8000000000000007FF8000000000000007FF8000000000000007FF8000000000
+000007FF8000000000000007FF8000000000000007FF8000000000000007FF8000000000
+000007FF8000000000000007FF8000000000000007FF8000000000000007FF8000000000
+000007FF8000000001FFC007FF800000001FFFFC07FF80000000FFFFFF07FF80000003FF
+FFFFC7FF8000000FFFC01FE7FF8000001FFE0003FFFF8000007FF80000FFFF800000FFF0
+00007FFF800001FFE000003FFF800003FFC000001FFF800007FF8000000FFF800007FF00
+00000FFF80000FFF0000000FFF80001FFF0000000FFF80001FFE0000000FFF80003FFE00
+00000FFF80003FFE0000000FFF80003FFE0000000FFF80007FFC0000000FFF80007FFC00
+00000FFF80007FFC0000000FFF8000FFFC0000000FFF8000FFFC0000000FFF8000FFFC00
+00000FFF8000FFFC0000000FFF8000FFFC0000000FFF8000FFFC0000000FFF8000FFFC00
+00000FFF8000FFFC0000000FFF8000FFFC0000000FFF8000FFFC0000000FFF8000FFFC00
+00000FFF80007FFC0000000FFF80007FFC0000000FFF80007FFC0000000FFF80007FFC00
+00000FFF80003FFE0000000FFF80003FFE0000000FFF80001FFE0000000FFF80001FFE00
+00000FFF80000FFF0000000FFF80000FFF0000000FFF800007FF8000001FFF800003FF80
+00003FFF800001FFC000007FFF800000FFE00000FFFF8000007FF00003FFFF8000003FFC
+0007EFFFE000000FFF803FCFFFFF800007FFFFFF8FFFFF800001FFFFFE0FFFFF8000003F
+FFF00FFFFF80000003FF800FFFFF8041537CD24B>I<000007FFC0000000007FFFFC0000
+0001FFFFFF00000007FFFFFFC000001FFF01FFF000003FFC003FF800007FF0000FFC0000
+FFE00007FE0001FFC00003FE0003FF800003FF0007FF800001FF800FFF000001FF800FFF
+000000FFC01FFE000000FFC03FFE000000FFE03FFE000000FFE03FFE0000007FE07FFC00
+00007FE07FFC0000007FF07FFC0000007FF07FFC0000007FF0FFFC0000007FF0FFFC0000
+007FF0FFFFFFFFFFFFF0FFFFFFFFFFFFF0FFFFFFFFFFFFF0FFFFFFFFFFFFE0FFFC000000
+0000FFFC0000000000FFFC0000000000FFFC0000000000FFFC00000000007FFC00000000
+007FFC00000000007FFC00000000007FFE00000000003FFE00000000003FFE0000000000
+1FFE00000000E01FFF00000001F00FFF00000001F007FF80000003F007FF80000007E003
+FFC0000007C001FFC000000FC000FFE000003F80007FF800007F00003FFE0003FE00000F
+FFC01FFC000003FFFFFFF0000000FFFFFFC00000003FFFFF0000000001FFF0000034357C
+B43D>I<0000001FF800000003FFFF0000000FFFFFC000003FFFFFE00000FFF01FF00001
+FFC03FF80003FF007FF80007FE007FFC000FFC00FFFC001FFC00FFFC001FF800FFFC003F
+F800FFFC003FF8007FF8007FF0007FF8007FF0003FF0007FF0001FE0007FF0000780007F
+F0000000007FF0000000007FF0000000007FF0000000007FF0000000007FF0000000007F
+F0000000007FF0000000007FF0000000007FF0000000007FF0000000007FF0000000007F
+F0000000FFFFFFFFE000FFFFFFFFE000FFFFFFFFE000FFFFFFFFE000FFFFFFFFE000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F8000000007FF8000000007FF8000000007FF8000000007FF8000000007FF8000000007F
+F80000007FFFFFFE00007FFFFFFE00007FFFFFFE00007FFFFFFE00007FFFFFFE00002E53
+7CD229>I<0000000000007E0000001FFF0003FF800001FFFFF00FFFC00007FFFFFC3FFF
+E0001FFFFFFF7F9FE0003FF803FFFC1FF000FFE000FFF01FF001FFC0007FF01FF003FF80
+003FF81FF003FF00001FF81FE007FF00001FFC0FC007FF00001FFC03800FFE00000FFE00
+000FFE00000FFE00001FFE00000FFF00001FFE00000FFF00001FFE00000FFF00001FFE00
+000FFF00001FFE00000FFF00001FFE00000FFF00001FFE00000FFF00001FFE00000FFF00
+000FFE00000FFE00000FFE00000FFE000007FF00001FFC000007FF00001FFC000003FF00
+001FF8000003FF80003FF8000001FFC0007FF0000000FFE000FFE00000007FF803FF8000
+0000FFFFFFFF00000001E7FFFFFC00000001E1FFFFF000000003C01FFF0000000003C000
+000000000007C000000000000007C000000000000007C000000000000007E00000000000
+0007E000000000000007F000000000000007F800000000000007FE00000000000007FFFF
+FFFF00000007FFFFFFFFF8000003FFFFFFFFFE000003FFFFFFFFFF800001FFFFFFFFFFE0
+0001FFFFFFFFFFF80000FFFFFFFFFFFC00007FFFFFFFFFFC00003FFFFFFFFFFE0001FFFF
+FFFFFFFF0007FFFFFFFFFFFF000FFC000001FFFF801FF80000001FFF803FF000000007FF
+807FE000000003FFC07FC000000001FFC0FFC000000000FFC0FFC000000000FFC0FFC000
+000000FFC0FFC000000000FFC0FFC000000000FFC0FFC000000000FFC07FE000000001FF
+807FE000000001FF803FF000000003FF001FF800000007FE001FFC0000000FFE0007FF00
+00003FF80003FFC00000FFF00000FFFC000FFFC000003FFFFFFFFF0000000FFFFFFFFC00
+000001FFFFFFE0000000000FFFFC0000003C4E7CB543>I<003FF0000000000000FFFFF0
+000000000000FFFFF0000000000000FFFFF0000000000000FFFFF0000000000000FFFFF0
+00000000000003FFF000000000000000FFF000000000000000FFF000000000000000FFF0
+00000000000000FFF000000000000000FFF000000000000000FFF000000000000000FFF0
+00000000000000FFF000000000000000FFF000000000000000FFF000000000000000FFF0
+00000000000000FFF000000000000000FFF000000000000000FFF000000000000000FFF0
+00000000000000FFF000000000000000FFF000000000000000FFF000000000000000FFF0
+00000000000000FFF000000000000000FFF000000000000000FFF000000000000000FFF0
+00000000000000FFF0001FFC00000000FFF000FFFF80000000FFF003FFFFE0000000FFF0
+0FFFFFF8000000FFF01FC07FFC000000FFF07E001FFE000000FFF0F8000FFF000000FFF1
+F0000FFF000000FFF1E0000FFF800000FFF3C00007FF800000FFF7800007FF800000FFF7
+000007FFC00000FFFE000007FFC00000FFFE000007FFC00000FFFC000007FFC00000FFFC
+000007FFC00000FFFC000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8
+000007FFC000FFFFFFF807FFFFFFC0FFFFFFF807FFFFFFC0FFFFFFF807FFFFFFC0FFFFFF
+F807FFFFFFC0FFFFFFF807FFFFFFC042537BD24B>I<007F000000FF800001FFC00003FF
+E00007FFF0000FFFF8000FFFF8000FFFF8000FFFF8000FFFF8000FFFF8000FFFF80007FF
+F00003FFE00001FFC00000FF8000007F0000000000000000000000000000000000000000
+000000000000000000000000000000000000000000000000000000000000000000000000
+0000003FF000FFFFF000FFFFF000FFFFF000FFFFF000FFFFF00001FFF00000FFF00000FF
+F00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FF
+F00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FF
+F00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FF
+F00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FF
+F00000FFF00000FFF00000FFF000FFFFFFE0FFFFFFE0FFFFFFE0FFFFFFE0FFFFFFE01B54
+7BD325>I<003FF000FFFFF000FFFFF000FFFFF000FFFFF000FFFFF00001FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF0
+0000FFF00000FFF00000FFF00000FFF00000FFF00000FFF00000FFF000FFFFFFF0FFFFFF
+F0FFFFFFF0FFFFFFF0FFFFFFF01C537BD225>108 D<003FF0001FFC000000FFE00000FF
+FFF000FFFF800007FFFC0000FFFFF003FFFFE0001FFFFF0000FFFFF00FFFFFF8007FFFFF
+C000FFFFF01FC07FFC00FE03FFE000FFFFF07E001FFE03F000FFF00003FFF0F8000FFF07
+C0007FF80000FFF1F0000FFF0F80007FF80000FFF1E0000FFF8F00007FFC0000FFF3C000
+07FF9E00003FFC0000FFF7800007FFBC00003FFC0000FFF7000007FFF800003FFE0000FF
+FE000007FFF000003FFE0000FFFE000007FFF000003FFE0000FFFC000007FFE000003FFE
+0000FFFC000007FFE000003FFE0000FFFC000007FFE000003FFE0000FFF8000007FFC000
+003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007
+FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8
+000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE00
+00FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC00000
+3FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FF
+C000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF800
+0007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000
+FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003F
+FE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC0
+00003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE0000FFF80000
+07FFC000003FFE0000FFF8000007FFC000003FFE0000FFF8000007FFC000003FFE00FFFF
+FFF807FFFFFFC03FFFFFFEFFFFFFF807FFFFFFC03FFFFFFEFFFFFFF807FFFFFFC03FFFFF
+FEFFFFFFF807FFFFFFC03FFFFFFEFFFFFFF807FFFFFFC03FFFFFFE67357BB470>I<003F
+F0001FFC000000FFFFF000FFFF800000FFFFF003FFFFE00000FFFFF00FFFFFF80000FFFF
+F01FC07FFC0000FFFFF07E001FFE000003FFF0F8000FFF000000FFF1F0000FFF000000FF
+F1E0000FFF800000FFF3C00007FF800000FFF7800007FF800000FFF7000007FFC00000FF
+FE000007FFC00000FFFE000007FFC00000FFFC000007FFC00000FFFC000007FFC00000FF
+FC000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FF
+F8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC000FFFF
+FFF807FFFFFFC0FFFFFFF807FFFFFFC0FFFFFFF807FFFFFFC0FFFFFFF807FFFFFFC0FFFF
+FFF807FFFFFFC042357BB44B>I<000001FFE000000000003FFFFF0000000000FFFFFFC0
+00000007FFFFFFF80000000FFF807FFC0000003FFC000FFF0000007FF00003FF800000FF
+E00001FFC00001FFC00000FFE00003FF8000007FF00007FF0000003FF8000FFF0000003F
+FC000FFE0000001FFC001FFE0000001FFE001FFE0000001FFE003FFE0000001FFF003FFC
+0000000FFF007FFC0000000FFF807FFC0000000FFF807FFC0000000FFF807FFC0000000F
+FF80FFFC0000000FFFC0FFFC0000000FFFC0FFFC0000000FFFC0FFFC0000000FFFC0FFFC
+0000000FFFC0FFFC0000000FFFC0FFFC0000000FFFC0FFFC0000000FFFC0FFFC0000000F
+FFC0FFFC0000000FFFC0FFFC0000000FFFC07FFC0000000FFF807FFC0000000FFF807FFC
+0000000FFF807FFC0000000FFF803FFE0000001FFF003FFE0000001FFF003FFE0000001F
+FF001FFE0000001FFE000FFF0000003FFC000FFF0000003FFC0007FF8000007FF80003FF
+8000007FF00003FFC00000FFF00001FFE00001FFE000007FF00003FF8000003FFC000FFF
+0000001FFF807FFE00000007FFFFFFF800000001FFFFFFE0000000003FFFFF0000000000
+01FFE00000003A357CB443>I<003FF000FFE0000000FFFFF00FFFFE000000FFFFF03FFF
+FFC00000FFFFF0FFFFFFF00000FFFFF3FE01FFF80000FFFFF7F0003FFE000001FFFFC000
+0FFF000000FFFF800007FF800000FFFF000003FFC00000FFFE000001FFE00000FFFC0000
+01FFF00000FFF8000000FFF80000FFF8000000FFF80000FFF80000007FFC0000FFF80000
+007FFC0000FFF80000003FFE0000FFF80000003FFE0000FFF80000003FFF0000FFF80000
+003FFF0000FFF80000003FFF0000FFF80000001FFF0000FFF80000001FFF8000FFF80000
+001FFF8000FFF80000001FFF8000FFF80000001FFF8000FFF80000001FFF8000FFF80000
+001FFF8000FFF80000001FFF8000FFF80000001FFF8000FFF80000001FFF8000FFF80000
+001FFF8000FFF80000001FFF8000FFF80000001FFF0000FFF80000003FFF0000FFF80000
+003FFF0000FFF80000003FFE0000FFF80000003FFE0000FFF80000007FFE0000FFF80000
+007FFC0000FFF80000007FFC0000FFF8000000FFF80000FFF8000000FFF00000FFFC0000
+01FFF00000FFFE000003FFE00000FFFF000007FFC00000FFFF80000FFF800000FFFFC000
+1FFF000000FFFFE0007FFC000000FFFBFC03FFF8000000FFF8FFFFFFE0000000FFF87FFF
+FF80000000FFF80FFFFC00000000FFF801FFC000000000FFF800000000000000FFF80000
+0000000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000
+0000000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000
+0000000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000
+0000000000FFF800000000000000FFF800000000000000FFF800000000000000FFF80000
+00000000FFFFFFF80000000000FFFFFFF80000000000FFFFFFF80000000000FFFFFFF800
+00000000FFFFFFF80000000000414C7BB44B>I<007FE001FC00FFFFE00FFF80FFFFE03F
+FFE0FFFFE07FFFF0FFFFE0FE1FF8FFFFE1F03FFC03FFE3E03FFC00FFE3C07FFE00FFE780
+7FFE00FFE7007FFE00FFEF007FFE00FFEE007FFE00FFFE003FFC00FFFC003FFC00FFFC00
+1FF800FFFC0007E000FFF800000000FFF800000000FFF800000000FFF800000000FFF000
+000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000
+000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000
+000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000
+000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000000000FFF000
+000000FFF000000000FFF000000000FFF0000000FFFFFFFC0000FFFFFFFC0000FFFFFFFC
+0000FFFFFFFC0000FFFFFFFC00002F357CB437>114 D<0001FFE00700001FFFFE1F0000
+FFFFFFFF0003FFFFFFFF0007FE001FFF000FF00003FF001FC00001FF003F800000FF003F
+8000007F007F0000003F007F0000003F007F0000001F00FF0000001F00FF0000001F00FF
+8000001F00FFC000001F00FFF000000000FFFE00000000FFFFF00000007FFFFF8000007F
+FFFFFC00003FFFFFFF80003FFFFFFFE0001FFFFFFFF0000FFFFFFFFC0007FFFFFFFE0001
+FFFFFFFF00007FFFFFFF80001FFFFFFFC00003FFFFFFC000003FFFFFE0000000FFFFE000
+00000FFFE000000001FFF0780000007FF0F80000003FF0F80000001FF0FC0000001FF0FC
+0000000FF0FC0000000FF0FE0000000FE0FE0000000FE0FF0000000FE0FF8000001FC0FF
+C000001FC0FFE000003F80FFF000007F80FFFC0000FF00FFFF800FFE00FF7FFFFFF800FC
+1FFFFFE000F807FFFF8000E0007FF800002C357CB435>I<00003E00000000003E000000
+00003E00000000003E00000000003E00000000003E00000000007E00000000007E000000
+00007E00000000007E0000000000FE0000000000FE0000000001FE0000000001FE000000
+0001FE0000000003FE0000000007FE0000000007FE000000000FFE000000001FFE000000
+003FFE00000000FFFE00000001FFFE0000000FFFFFFFFF00FFFFFFFFFF00FFFFFFFFFF00
+FFFFFFFFFF00FFFFFFFFFF00003FFE000000003FFE000000003FFE000000003FFE000000
+003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000
+003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000
+003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000
+003FFE000000003FFE000000003FFE000000003FFE000000003FFE000000003FFE0007C0
+003FFE0007C0003FFE0007C0003FFE0007C0003FFE0007C0003FFE0007C0003FFE0007C0
+003FFE0007C0003FFE0007C0003FFE0007C0003FFE0007C0001FFE000F80001FFF000F80
+000FFF000F00000FFF801F000007FF803E000003FFE07C000001FFFFFC0000007FFFF000
+00001FFFE000000001FF00002A4C7ECB34>I<003FF8000001FFC000FFFFF80007FFFFC0
+00FFFFF80007FFFFC000FFFFF80007FFFFC000FFFFF80007FFFFC000FFFFF80007FFFFC0
+0003FFF800001FFFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC00000FFF8000007FFC0
+0000FFF800000FFFC00000FFF800000FFFC00000FFF800000FFFC00000FFF800001FFFC0
+0000FFF800001FFFC000007FF800003BFFC000007FF800007BFFC000003FF80000F3FFC0
+00003FFC0001F3FFC000001FFE0003E3FFF000000FFF801FC3FFFFC00007FFFFFF03FFFF
+C00001FFFFFE03FFFFC000007FFFF803FFFFC0000007FFC003FFFFC042357BB44B>I<FF
+FFFFF00007FFFFFFFFFFF00007FFFFFFFFFFF00007FFFFFFFFFFF00007FFFFFFFFFFF000
+07FFFF00FFF80000007FC000FFFC0000003F0000FFFC0000003F00007FFE0000003E0000
+7FFE0000007E00003FFE0000007C00003FFF000000FC00001FFF000000F800001FFF8000
+01F800000FFF800001F000000FFFC00003F0000007FFC00003E0000007FFE00003E00000
+07FFE00007E0000003FFF00007C0000003FFF0000FC0000001FFF8000F80000001FFF800
+1F80000000FFF8001F00000000FFFC003F000000007FFC003E000000007FFE007E000000
+003FFE007C000000003FFF00FC000000003FFF00FC000000001FFF80F8000000001FFF81
+F8000000000FFFC1F0000000000FFFC3F00000000007FFC3E00000000007FFE7E0000000
+0003FFE7C00000000003FFFFC00000000001FFFF800000000001FFFF800000000000FFFF
+000000000000FFFF000000000000FFFF0000000000007FFE0000000000007FFE00000000
+00003FFC0000000000003FFC0000000000001FF80000000000001FF80000000000000FF0
+0000000000000FF000000000000007E000000000000003C000000040357DB447>I<FFFF
+FFF00007FFFFFFFFFFF00007FFFFFFFFFFF00007FFFFFFFFFFF00007FFFFFFFFFFF00007
+FFFF00FFF80000007FC000FFFC0000003F0000FFFC0000003F00007FFE0000003E00007F
+FE0000007E00003FFE0000007C00003FFF000000FC00001FFF000000F800001FFF800001
+F800000FFF800001F000000FFFC00003F0000007FFC00003E0000007FFE00003E0000007
+FFE00007E0000003FFF00007C0000003FFF0000FC0000001FFF8000F80000001FFF8001F
+80000000FFF8001F00000000FFFC003F000000007FFC003E000000007FFE007E00000000
+3FFE007C000000003FFF00FC000000003FFF00FC000000001FFF80F8000000001FFF81F8
+000000000FFFC1F0000000000FFFC3F00000000007FFC3E00000000007FFE7E000000000
+03FFE7C00000000003FFFFC00000000001FFFF800000000001FFFF800000000000FFFF00
+0000000000FFFF000000000000FFFF0000000000007FFE0000000000007FFE0000000000
+003FFC0000000000003FFC0000000000001FF80000000000001FF80000000000000FF000
+00000000000FF000000000000007E000000000000007E000000000000007E00000000000
+0007C00000000000000FC00000000000000F800000000000001F800000000000001F0000
+00000000003F000000001FC0003E000000003FE0007E000000007FF0007C00000000FFF8
+00FC00000000FFF800F800000000FFF801F800000000FFF803F000000000FFF803E00000
+0000FFF807E0000000007FF01FC0000000007EE03F80000000003FC1FF00000000001FFF
+FC00000000000FFFF8000000000003FFE0000000000000FF000000000000404C7DB447>
+121 D<FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+F8FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF885
+0480A286>124 D E end
+%%EndProlog
+%%BeginSetup
+%%Feature: *Resolution 600dpi
+TeXDict begin
+%%PaperSize: a4
+
+%%EndSetup
+%%Page: 1 1
+1 0 bop 500 387 a Fo(Store)46 b(|)f(a)g(System)h(for)f(Handling)g
+(Third-P)l(art)l(y)532 527 y(Applications)g(in)g(a)g(Heterogeneous)i
+(Computer)1426 666 y(En)l(vironmen)l(t)1136 957 y Fn(Anders)27
+b(Christensen)1846 926 y Fm(?)1912 957 y Fn(and)g(T)-7
+b(or)27 b(Egge)2406 926 y Fm(??)1395 1131 y Fl(Univ)n(ersit)n(y)e(of)h
+(T)-6 b(rondheim)602 1484 y Fk(Abstract.)42 b Fl(This)c(pap)r(er)f
+(presen)n(ts)g(the)g(Store)h(system)e(administration)i(to)r(ol)602
+1575 y(suite,)28 b(whic)n(h)g(helps)g(administering)g(third)f(part)n(y)
+g(applications)j(in)d(a)i(heteroge-)602 1667 y(neous)e(Unix)g(en)n
+(vironmen)n(t,)f(giving)i(b)r(etter)g(o)n(v)n(erview,)g(more)f
+(consistency)-6 b(,)28 b(and)602 1758 y(less)h(man)n(ual)g(w)n(ork.)g
+(The)g(problems)g(targeted)g(b)n(y)f(Store)h(are)h(listed;)g(the)e
+(basic)602 1849 y(functionalit)n(y)36 b(of)g(Store)g(is)h(describ)r
+(ed,)f(and)g(exp)r(eriences)g(from)g(constructing)602
+1941 y(and)25 b(main)n(taining)g(the)h(system)e(are)j(presen)n(ted.)365
+2233 y Fj(1)112 b(The)38 b(Problem)365 2440 y Fn(F)-7
+b(rom)33 b(exp)r(eriences,)f(w)n(e)g(ha)n(v)n(e)g(found)h(that)g(a)f(n)
+n(um)n(b)r(er)g(of)h(problems)f(arise)g(in)h(the)g(area)365
+2540 y(of)40 b(administering)f(computer)h(systems.)f(These)g(problems)g
+(are)g(often)h(caused)f(b)n(y)h(the)365 2640 y(lo)r(cal,)19
+b(strategic)f(organization)f(of)j(the)f(computers,)g(including)h
+(heterogeneous)d(hardw)n(are,)365 2739 y(m)n(ultiple)23
+b(soft)n(w)n(are)d(v)n(ersions,)g(deviating)i(user)f(needs,)h(m)n
+(ultiple)g(system)g(administrators,)365 2839 y(geographical)j
+(distribution,)j(duplication)g(of)f(data,)g(and)h(organizational)d
+(structure.)490 2940 y(These)32 b(giv)n(e)g(rise)g(to)h(a)g(n)n(um)n(b)
+r(er)f(of)h(sp)r(eci\014c)g(problems,)f(where)g(the)i(more)e(common)365
+3040 y(ones)27 b(are)g(listed)h(b)r(elo)n(w:)365 3212
+y Fi(T)-8 b(raceabilit)m(y)g(.)46 b Fn(As)28 b(the)i(complexit)n(y)e
+(of)h(a)f(computer)g(system)h(rises,)f(the)h(kno)n(wledge)e(of)506
+3312 y(\\who-did-what")f(b)r(ecomes)i(more)f(imp)r(ortan)n(t,)g(as)h
+(do)r(es)f(the)h(\\wh)n(y-did-they-do-it-)506 3412 y(lik)n(e-that")37
+b(information.)g(Ho)n(w)n(ev)n(er,)f(activities)i(lik)n(e)f(logging,)g
+(do)r(cumen)n(ting,)g(and)506 3511 y(registering)29 b(are)g(often)i
+(ignored)e(during)h(particularly)f(hectic)i(p)r(erio)r(ds)f(in)h(the)g
+(daily)506 3611 y(system)i(administering.)g(A)h(lot)f(of)g
+(self-discipline)h(is)f(required)f(to)h(main)n(tain)g(these)506
+3711 y(activities)28 b(in)g(a)f(highly)g(result-orien)n(ted)f(trade.)
+365 3812 y Fi(A\016nit)m(y)-8 b(.)43 b Fn(In)35 b(a)f(traditional)g
+Fh(/usr/local)d Fn(\014le)k(system,)f(a)h(large)e(n)n(um)n(b)r(er)i(of)
+g(\014les)f(are)506 3912 y(mixed)g(fairly)e(unorderly)g(together.)h
+(Files)g(are)f(somewhat)h(group)r(ed)f(in)n(to)h(applica-)506
+4011 y(tions,)19 b(but)h(it)f(is)g(often)g(not)g(ob)n(vious)e(who)i
+(main)n(tains)f(whic)n(h)h(applications.)f(T)n(ypically)-7
+b(,)506 4111 y(whic)n(h)33 b(\014les)f(b)r(elong)g(to)g(whic)n(h)g
+(applications,)g(and)g(whic)n(h)g(applications)g(consist)f(of)506
+4210 y(whic)n(h)d(\014les,)g(are)e(matters)h(of)h(uncertain)n(t)n(y)f
+(and)g(v)-5 b(agueness.)365 4312 y Fi(Arc)m(hitecture)35
+b(dep)s(endency)-8 b(.)41 b Fn(Since)21 b(di\013eren)n(t)h(hardw)n(are)
+d(arc)n(hitectures)i(require)f(dif-)506 4411 y(feren)n(t)39
+b(binary)g(programs,)e(system)i(managemen)n(t)f(tend)h(to)g(administer)
+g(di\013eren)n(t)506 4511 y(hardw)n(are)32 b(platforms)i(separately)-7
+b(.)32 b(This)i(adds)g(unnecessarily)f(to)h(the)g(costs;)f(most)506
+4611 y(applications)22 b(are)g(iden)n(tical)h(across)e(platforms)h
+(except)h(from)g(the)g(di\013ering)g(binaries.)p 365
+4687 473 4 v 381 4740 a Fg(?)442 4772 y Fl(SINTEF)j(R)n(UNIT)e
+(\(email:)i Ff(anders.christensen@runit.sintef.no)5 b
+Fl(\))348 4832 y Fg(??)442 4863 y Fl(Division)26 b(of)h(Computer)e
+(Science)g(and)h(T)-6 b(elematics)26 b(\(email:)g Ff(te)l
+(gge@idt.unit.no)5 b Fl(\))p eop
+%%Page: 2 2
+2 1 bop 681 387 a Fi(Bit)32 b(rot.)41 b Fn(There)25 b(is)g(no)f(go)r(o)
+r(d)h(explanation)f(for)g(it,)i(but)g(it)f(is)g(a)g(w)n(ell-kno)n(wn)e
+(observ)-5 b(ation)822 487 y(that)21 b(unattended)h(applications)e
+(tend)i(to)e(stop)h(w)n(orking)f(after)g(some)h(time,)g(generally)822
+587 y(due)33 b(to)f(of)g(c)n(hanges)f(in)i(the)g(surrounding)e(en)n
+(vironmen)n(t.)g(Therefore,)g(users)h(slo)n(wly)822 686
+y(mo)n(v)n(e)38 b(o)n(v)n(er)f(to)i(the)h(\\safe")e(computers;)g(the)i
+(computers)f(that)g(con)n(tain)f(soft)n(w)n(are)822 786
+y(b)r(eing)24 b(used.)f(This)h(sp)r(eeds)g(up)g(the)g(pro)r(cess)e(of)i
+(bit)g(rot)f(on)g(the)h(less)g(used)f(computers.)681
+886 y Fi(Source)32 b(co)s(de.)41 b Fn(System)34 b(administration)g(do)r
+(es)g(not)h(in)n(v)n(olv)n(e)e(program)f(dev)n(elopmen)n(t,)822
+985 y(except)e(for)f(installation,)g(bug-\014xing,)g(and)h(lo)r(cal)f
+(customization.)h(The)f(c)n(hanges)g(to)822 1085 y(program)19
+b(source)h(co)r(de)h(for)g(these)g(areas)f(are)g(often)h(lost)g(o)n(v)n
+(er)f(time,)h(as)g(source)f(co)r(de)h(is)822 1184 y(often)h(considered)
+f(disk)h(space)f(o)n(v)n(erhead)f(and)h(deleted.)i(This)f(often)g
+(results)f(in)h(minor)822 1284 y(di\013erences)k(b)r(et)n(w)n(een)h(v)n
+(ersions)e(and)i(installations)f(on)g(di\013eren)n(t)h(arc)n
+(hitectures.)e(F)-7 b(or)822 1384 y(the)28 b(users,)f(these)g
+(di\013erences)h(can)f(b)r(e)h(v)n(ery)e(anno)n(ying.)681
+1647 y Fj(2)112 b(The)38 b(Domain)e(of)i(Store)681 1840
+y Fn(Store)32 b(is)h(a)f(system)h(administration)f(utilit)n(y)h(that)g
+(attempts)h(to)e(handle)h(the)h(problems)681 1940 y(listed)28
+b(in)f(the)h(previous)f(section.)805 2040 y(Store)22
+b(limits)g(its)h(scop)r(e)e(to)h(handling)g(third)g(part)n(y)f
+(applications.)h(That)g(is,)g(an)n(y)f(group)681 2139
+y(of)26 b(programs)e(and)j(data)f(\014les)g(that)h(form)f(a)g(logical)f
+(unit)i(and)g(can)f(b)r(e)g(isolated)g(from)g(the)681
+2239 y(op)r(erating)31 b(system.)i(Tw)n(o)f(main)g(sources)g(of)g
+(third)h(part)n(y)f(soft)n(w)n(are)f(are)g(do)n(wnloadable)681
+2338 y(freew)n(are)26 b(from)h(in)n(ternational)f(net)n(w)n(orks)g(and)
+i(pac)n(k)-5 b(ages)26 b(from)h(commercial)f(v)n(endors.)805
+2438 y(F)-7 b(urthermore,)26 b(Store)g(limits)i(its)e(op)r(erations)g
+(on)g(these)h(third)g(part)n(y)f(applications)g(to)681
+2538 y(the)33 b(installation,)f(op)r(eration,)f(main)n(tenance,)h(bug)g
+(\014nding)h(and)f(-\014xing)g(parts)f(of)i(their)681
+2637 y(life)28 b(cycles.)805 2737 y(That)k(is,)g(areas)e(outside)i(the)
+g(domain)f(of)h(Store)f(are:)g(program)f(dev)n(elopmen)n(t;)h(user)681
+2837 y(and)c(net)n(w)n(ork)f(administration;)h(OS)h(main)n(tenance,)f
+(con\014guration,)f(and)h(surv)n(eillance.)805 2936 y(Curren)n(tly)-7
+b(,)28 b(Store)f(is)h(also)f(limited)i(to)f(Unix)h(systems.)e(Initial)i
+(testing)f(is)g(b)r(eing)g(p)r(er-)681 3036 y(formed)f(for)g(one-user,)
+f(p)r(ersonal)h(computers;)g(sp)r(eci\014cally)g(PCs)g(running)g
+(MS-DOS.)681 3299 y Fj(3)112 b(Requiremen)m(ts)681 3492
+y Fn(The)27 b(main)h(requiremen)n(ts)e(w)n(e)i(ha)n(v)n(e)e(placed)h
+(on)h(Store)f(are:)681 3668 y Fi(No)k(OS)h(mo)s(di\014cations.)41
+b Fn(No)31 b(c)n(hanges)e(to)i(the)g(op)r(erating)f(system)h(should)f
+(b)r(e)h(neces-)822 3768 y(sary)c(in)i(order)e(to)i(run)f(Store.)g
+(Neither)h(new)g(device)f(driv)n(ers,)f(k)n(ernel)h(mo)r(di\014cations)
+822 3867 y(nor)f(p)r(ermanen)n(t)g(daemons.)681 3967
+y Fi(OS-supplied)32 b(mapping.)41 b Fn(The)28 b(op)r(erating)f(system)g
+(should)h(pro)n(vide)e(the)i(mec)n(hanism)822 4066 y(to)j(map)g(from)f
+(the)i(view)f(\(linktree\))g(to)g(the)g(rep)r(ository)f(\(store\).)g(A)
+i(space-e\016cien)n(t)822 4166 y(suc)n(h)27 b(mapping)g(for)h(most)f
+(Unix)h(systems)f(is)g(soft-links.)681 4266 y Fi(Source)32
+b(co)s(de)f(a)m(v)-5 b(ailabilit)m(y)d(.)47 b Fn(The)25
+b(source)g(co)r(de)h(for)f(the)h(system)f(should)h(b)r(e)g(a)n(v)-5
+b(ailable)822 4365 y(to)27 b(the)h(users.)681 4465 y
+Fi(P)m(ortabilit)m(y)-8 b(.)45 b Fn(The)28 b(system)f(should)h(b)r(e)g
+(able)g(to)g(run)g(on)f(an)n(y)g(system)h(that)g(follo)n(ws)f(the)822
+4565 y(POSIX.1)g(standard)f(and)i(has)f(sym)n(b)r(olic)g(links.)681
+4664 y Fi(V)-8 b(ersioned)32 b(binary)h(\014les.)41 b
+Fn(The)19 b(system)g(should)g(handle)g(the)h(existence)f(of)g(sev)n
+(eral)e(v)n(er-)822 4764 y(sions)22 b(of)g(binary)g(executables)g(a)n
+(v)-5 b(ailable)21 b(in)i(the)g(rep)r(ository)-7 b(,)21
+b(c)n(ho)r(osing)g(the)i(righ)n(t)f(one)822 4863 y(to)27
+b(b)r(ecome)h(visible)f(in)h(the)g(linktree.)p eop
+%%Page: 3 3
+3 2 bop 365 387 a Fj(4)112 b(Other)38 b(Existing)d(SCM)j(Systems)365
+617 y Fn(Most)j(existing)f(SCM)h(systems)f(do)r(es)h(not)g(meet)g(our)f
+(sp)r(eci\014ed)h(requiremen)n(ts.)e(T)-7 b(o)41 b(a)365
+716 y(large)31 b(exten)n(t)g(they)h(target)f Fe(pr)l(o)l(gr)l(amming)i
+Fn(en)n(vironmen)n(ts,)d(instead)i(of)f Fe(instal)t(lation)i
+Fn(en-)365 816 y(vironmen)n(ts.)c(Also,)h(man)n(y)f(of)h(them)g(can)g
+(only)f(manage)g(textual)h(\014les,)g(are)e(commercial)365
+915 y(pro)r(ducts)d(\(a)n(v)-5 b(ailable)24 b(only)g(for)h(a)f(subset)h
+(of)g(the)h(platforms\),)e(or)g(require)g(c)n(hanges)g(in)h(the)365
+1015 y(op)r(erating)i(system.)490 1121 y(Tw)n(o)d(other)g(existing)g
+(SCM)h(systems)g(that)g(meet)g(our)f(requiremen)n(ts)f(are)h(\\Dep)r
+(ot"[1)o(])365 1220 y(and)k(\\Lude"[3)n(].)490 1326 y(The)g(problems)f
+(describ)r(ed)h(ab)r(o)n(v)n(e)f(ha)n(v)n(e)g(b)r(een)h(targeted)f(b)n
+(y)h(sev)n(eral)e(other)i(systems.)365 1426 y(The)19
+b(initial)h(implemen)n(tation)f(of)g(Store)f(\(spring/summer)g(1991\))g
+(w)n(as)g(hea)n(vily)g(in\015uenced)365 1525 y(b)n(y)j(\\Dep)r(ot")f(.)
+g(Ho)n(w)n(ev)n(er,)f(no)h(implemen)n(tation)h(of)g(\\Dep)r(ot")f(w)n
+(as)f(a)n(v)-5 b(ailable)20 b(and)g(the)h(lo)r(cal)365
+1625 y(implemen)n(tation)34 b(turned)g(out)f(to)h(b)r(e)f(di\013eren)n
+(t)h(from)f(the)h(original)e(in)i(man)n(y)f(w)n(a)n(ys,)f(so)365
+1724 y(another)27 b(name)g(w)n(as)g(giv)n(en.)490 1830
+y(Other)32 b(systems)h(that)h(target)e(the)h(problems)g(in)g(a)g
+(similar)f(w)n(a)n(ys)g(are)g(Ericsson)f([2];)365 1930
+y(and)d(\\Lude")e(.)490 2035 y(In)31 b(addition,)f(Pleasan)n(t)f(and)h
+(Lear)g([4)o(])h(describ)r(es)f(\\T)-7 b(rac)n(k",)28
+b(whic)n(h)j(is)f(a)g(basically)g(a)365 2135 y(transp)r(ort)k(mec)n
+(hanism,)h(and)g(ho)n(w)f(it)i(has)e(b)r(een)i(put)f(in)n(to)g(use)g
+(in)g(order)f(to)h(solv)n(e)f(the)365 2235 y(same)27
+b(problems)g(as)g(Store.)490 2340 y(Man)n(y)41 b(univ)n(ersit)n(y)g(CM)
+h(systems)f(target)g(con\014guration)f(managemen)n(t)h(of)g(source)365
+2440 y(co)r(de.)30 b(Ho)n(w)n(ev)n(er,)f(for)g(a)h(system)g
+(administrator,)f(the)i(one-time)f(e\013ort)g(of)g(compiling)g(an)365
+2539 y(application)38 b(is)g(often)h(manageable)d(and)i(trivial)g
+(compared)f(to)h(the)h(con)n(tin)n(ued)f(e\013ort)365
+2639 y(that)27 b(has)f(to)g(b)r(e)h(put)g(in)n(to)f(con)n(tin)n(ued,)g
+(on-going)f(administration)g(of)i(a)f(complex)g(system)365
+2739 y(in)n(v)n(olving)c(a)h(large)f(n)n(um)n(b)r(er)h(of)g
+(applications,)f(organizations,)f(arc)n(hitectures,)h(and)h(users.)490
+2844 y(F)-7 b(urthermore,)22 b(most)i(large)e(Unix)h(op)r(erating)g
+(systems)g(ha)n(v)n(e)f(a)h(system)g(for)g(distribut-)365
+2944 y(ing)f(soft)n(w)n(are)f(pac)n(k)-5 b(ages.)20 b(But)j
+(unfortunately)-7 b(,)22 b(most)g(of)g(these)g(commercial)f(pro)r
+(ducts)h(are)365 3043 y(a)n(v)-5 b(ailable)31 b(only)h(for)g(a)f
+(single)h(OS)g(and)g(few)g(o\013er)g(more)f(than)i(insu\016cien)n(t,)f
+(elemen)n(tary)365 3143 y(supp)r(ort)37 b(for)g(the)g(system)g
+(administrators.)f(Generally)-7 b(,)36 b(they)i(only)e(o\013er)h(supp)r
+(ort)g(for)365 3243 y(loading)29 b(soft)n(w)n(are)g(in)n(to)h(the)g
+(mac)n(hine,)g(a)g(crude)g(in)n(v)n(en)n(tory)e(list,)j(and)f(p)r
+(erhaps)f(supp)r(ort)365 3342 y(for)e(unloading.)365
+3641 y Fj(5)112 b(The)38 b(Concepts)365 3870 y Fn(The)28
+b(main)g(concepts)f(of)g(Store)g(are:)365 4060 y Fi(Separabilit)m(y)-8
+b(.)45 b Fn(Ev)n(erything)26 b(related)h(to)h(a)f(single)g
+(application,)h(including)g(all)f(v)n(ersions)506 4160
+y(and)j(supp)r(ort)f(for)g(v)-5 b(arious)28 b(hardw)n(are)g(platforms,)
+h(are)f(isolated)h(at)g(one)g(lo)r(cation)g(in)506 4260
+y(the)i(computer)f(\014le)h(system.)f(This)g(\\master)g(lo)r(cation")f
+(of)h(the)h(application)f(can)g(b)r(e)506 4359 y(institution-wide;)f
+(it)f(can)f(also)f(span)h(m)n(ultiple)i(co)r(op)r(erating)d
+(institutions.)365 4465 y Fi(Consistency)-8 b(.)42 b
+Fn(An)21 b(installation)f(of)h(an)g(application)f(should)g(b)r(e)i
+(consisten)n(t)e(throughout)506 4565 y(the)28 b(institution.)h(If)f
+(incorrect)f(or)f(buggy)-7 b(,)27 b(the)h(application)f(should)h(b)r(e)
+g(consisten)n(tly)506 4664 y(incorrect)f(ev)n(erywhere.)f(Only)i(then)g
+(is)g(there)g(a)f(fair)h(c)n(hance)f(of)g(the)i(problem)e(b)r(eing)506
+4764 y(corrected;)i(else)g(users)f(mo)n(v)n(e)h(o)n(v)n(er)e(to)j
+(computers)e(that)i(w)n(ork,)e(allo)n(wing)g(the)i(faults)506
+4863 y(to)e(con)n(tin)n(ue)f(and)g(to)h(accum)n(ulate.)p
+eop
+%%Page: 4 4
+4 3 bop 681 387 a Fi(Automation.)41 b Fn(An)n(y)24 b(kind)h(of)f(man)n
+(ually)f(p)r(erformed)h(routine)g(w)n(ork)f(will)h(ev)n(en)n(tually)f
+(b)r(e)822 487 y(skipp)r(ed)30 b(or)e(p)r(erformed)h(incorrectly)-7
+b(.)28 b(Th)n(us,)h(suc)n(h)h(w)n(ork)e(should)h(b)r(e)g(automated)g
+(as)822 587 y(m)n(uc)n(h)e(as)g(p)r(ossible.)681 693
+y Fi(Do)s(cumen)m(tation.)42 b Fn(Lo)r(cally)32 b(written)i(do)r(cumen)
+n(tation)f(should)h(b)r(e)f(as)g(scarce)f(as)h(p)r(os-)822
+793 y(sible,)d(and)f(preferably)g(b)r(e)h(limited)g(to:)g(a\))f
+(\\gluing")f(together)h(do)r(cumen)n(tation)h(ac-)822
+893 y(compan)n(ying)g(the)h(applications;)f(b\))i(do)r(cumen)n(ting)f
+(lo)r(cal)f(con)n(v)n(en)n(tions)g(and)h(devia-)822 992
+y(tions;)i(and)g(c\))h(\014lling)f(in)g(fatal)h(gaps)e(in)h(accompan)n
+(ying)f(do)r(cumen)n(tation.)h(Lo)r(cally)822 1092 y(written)e(do)r
+(cumen)n(tation)f(tends)h(to)f(get)h(outdated)f(quic)n(kly)-7
+b(,)30 b(so)g(the)h(lesser)e(there)i(is)822 1192 y(to)c(main)n(tain,)h
+(and)f(the)h(more)f(automated)g(is)g(main)n(tenance,)h(the)g(b)r
+(etter.)681 1298 y Fi(Standardization.)44 b Fn(The)25
+b(more)e(need)i(a)f(system)h(administration)e(to)r(ol)i(has)f(for)g(sp)
+r(eci\014c)822 1398 y(and)31 b(non-standard)e(supp)r(ort,)h(the)i(more)
+e(di\016cult)h(and)g(troublesome)e(it)j(is)e(to)h(p)r(ort)822
+1498 y(it)k(to)f(new)g(arc)n(hitectures)f(and)h(organizations.)e(Th)n
+(us,)i(when)h(implemen)n(ting)g(solu-)822 1597 y(tions,)f
+(standardization,)f(p)r(ortabilit)n(y)-7 b(,)33 b(and)h(robustness)f
+(is)h(more)g(imp)r(ortan)n(t)g(than)822 1697 y(simplicit)n(y)28
+b(and)f(elegance.)681 1804 y Fi(Strategy-less)32 b(mec)m(hanisms.)41
+b Fn(In)36 b(constructing)e(Store,)h(the)h(mec)n(hanism)e(has)h(b)r
+(een)822 1903 y(attempted)c(isolated)g(from)f(the)h(strategies)f(that)h
+(it)g(implemen)n(ts.)g(Th)n(us,)g(the)g(Store)822 2003
+y(transp)r(ort)c(mec)n(hanisms)h(can)g(b)r(e)h(emplo)n(y)n(ed)e(for)h
+(v)-5 b(arious)27 b(securit)n(y)h(sc)n(hemes)g(and)g(to)822
+2103 y(mimic)g(v)-5 b(arious)26 b(in)n(tra-)h(and)g(in)n
+(ter-organization)e(relations.)681 2408 y Fj(6)112 b(T)-9
+b(ec)m(hnical)36 b(Description)681 2643 y Fn(Store)30
+b(separates)g(applications)g(from)h(eac)n(h)g(other,)g(in)g(a)g(t)n(w)n
+(o-lev)n(el)f(system:)h(at)g(the)h(top)681 2742 y(there)37
+b(are)f(one)g(or)h(more)f(stores,)g(or)g(\\store)f(serv)n(ers".)g(A)n
+(t)i(the)h(lo)n(w)n(er)d(lev)n(el)i(there)g(are)681 2842
+y(one)32 b(or)g(more)g(applications.)g(Multiple)i(stores)e(enable)g
+(distributing)h(the)g(\014les)g(in)g(Store)681 2942 y(among)f(sev)n
+(eral)g(mac)n(hines)g(and)i(organizations,)d(e.g.)24
+b(duplication)33 b(to)h(coun)n(ter)e(slo)n(w)h(or)681
+3041 y(temp)r(orarily)26 b(brok)n(en)h(net)n(w)n(orks.)805
+3148 y(The)39 b(directory)e(tree)h(sho)n(wn)g(in)h(\014gure)f(1)g
+(indicates)g(the)h(directory)e(structure)h(for)681 3248
+y(a)31 b(Store)h(system)g(con)n(taining)f(t)n(w)n(o)g(serv)n(ers)f(and)
+i(nine)g(applications.)g(The)g(no)r(de)g(named)681 3347
+y(\\/store/")26 b(is)k(the)f(top)h(directory)-7 b(.)28
+b(Th)n(us,)h(path)h(names)f(for)g(the)g(lo)r(cations)g(of)g(the)h
+(appli-)681 3447 y(cations)d(are)f Fh(/store/store/stor)o(li)o(nd/)o
+(zi)o(p)p Fn(,)c Fh(/store/store/kh)o(ym/)o(te)o(x)p
+Fn(,)g(etc.)805 3554 y(The)31 b(store)f(names)g(\(\\storlind")g(and)h
+(\\kh)n(ym"\))e(can)i(b)r(e)g(iden)n(tical)g(to)f(the)h(names)g(of)681
+3654 y(the)e(host)g(on)f(whic)n(h)h(they)g(are)f(lo)r(cated,)g(but)i
+(this)f(is)g(not)g(a)f(requiremen)n(t.)g(Ho)n(w)n(ev)n(er,)f(w)n(e)681
+3753 y(ha)n(v)n(e)36 b(found)h(this)h(naming)f(sc)n(heme)f(to)h(b)r(e)h
+(fairly)e(practical.)h(One)f(mac)n(hine)h(can)g(host)681
+3853 y(m)n(ultiple)28 b(stores.)805 3960 y(No)n(w)40
+b(w)n(e)h(shift)g(the)g(fo)r(cus)g(to)f(a)g(single)g(application.)h
+(The)f(structure)g(of)h(a)f(small)681 4059 y(application)21
+b(is)g(depicted)h(in)g(\014gure)f(2.)g(F)-7 b(or)21 b(suc)n(h)h(a)f
+(pac)n(k)-5 b(age)20 b(there)h(are)g(one)g(or)g(more)g(\\v)n(er-)681
+4159 y(")h(directories,)g(zero)g(or)g(more)g(\\src-")f(directories,)h
+(and)g(a)h(\014le)g(called)g(\\registration".)d(The)681
+4258 y(ro)r(ot)h(of)i(the)g(tree)f(sho)n(wn)f(in)i(\014gure)f(2)g(is)g
+Fh(/store/store/khym)o(/s)o(ha)o(r)p Fn(,)17 b(if)23
+b(the)f(application)681 4358 y(is)27 b(\\shar",)f(and)h(it)h(is)g
+(stored)f(on)g(the)h(store)f(\\kh)n(ym".)805 4465 y(The)f(\\src-")e
+(directories)g(con)n(tain)h(the)i(source)d(co)r(de)i(for)f(the)h
+(application.)f(The)h(origi-)681 4565 y(nal,)19 b(o\016cial)g(source)f
+(co)r(de)i(is)f(stored)g(in)h(directories)e(named)h(\\src-)p
+Fe(version)p Fn(")g(where)g Fe(version)681 4664 y Fn(refers)30
+b(to)h(the)h(release)e(n)n(um)n(b)r(er.)h(In)g(directories)f(named)h
+(\\src-)p Fe(version)p Fn(-)p Fe(ar)l(chite)l(ctur)l(e)p
+Fn(",)f(a)681 4764 y(link-tree)c(\(of)h(symlinks\))g(is)f(used)h(to)g
+(con)n(tain)f(mo)r(di\014cations)g(sp)r(eci\014c)h(to)g(that)g(arc)n
+(hitec-)681 4863 y(ture;)e(this)g(linktree)g(is)g(said)f(to)h(b)r(e)g
+(a)g(\\shado)n(w")e(of)i(the)g(original)e(linktree.)i(The)g(linktrees)p
+eop
+%%Page: 5 5
+5 4 bop 673 1331 a @beginspecial 49 @llx 439 @lly 389
+@urx 593 @ury 2720 @rwi @setspecial
+%%BeginDocument: server.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 11 def
+/arrowWidth 5 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 336 169 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 49.9999 136 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 129 138 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 44.9999 264 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 289 215 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 72.9999 206 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 183 244 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 132 301 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 278 265 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 359 255 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 369 210 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 197 231 ] concat
+%I
+229 460 251 478 Line
+%I 1
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -10.0001 225 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -3.00012 174 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 225 773 ] concat
+%I
+[
+(/store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 280 717 ] concat
+%I
+[
+(store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 380 736 ] concat
+%I
+[
+(zoo/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 381 687 ] concat
+%I
+[
+(storlind/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 461 725 ] concat
+%I
+[
+(zip/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 450 681 ] concat
+%I
+[
+(compress/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 430 641 ] concat
+%I
+[
+(emacs/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 143 736 ] concat
+%I
+[
+(gcc/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 231 609 ] concat
+%I
+[
+(tex/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 147 607 ] concat
+%I
+[
+(idraw/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 97.9999 645 ] concat
+%I
+[
+(xrn/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 77.9999 696 ] concat
+%I
+[
+(gnuplot/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 169 679 ] concat
+%I
+[
+(khym/)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.633041 -0 -0 0.633041 150.031 242.455 ] concat
+%I
+391 720 385 745 Line
+%I 2
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 293.75 623 ] concat
+%I
+557 231 617 224 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 293.75 623 ] concat
+%I
+130 336 301 254 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 293.75 623 ] concat
+%I
+496 174 547 106 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 155 623 ] concat
+%I
+244 209 431 329 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 155 656 ] concat
+%I
+435 391 535 282 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 44 590 ] concat
+%I
+635 271 763 123 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 44 590 ] concat
+%I
+526 394 472 494 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 44 590 ] concat
+%I
+443 359 357 395 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 44 590 ] concat
+%I
+446 295 375 231 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 44 590 ] concat
+%I
+545 260 479 116 Line
+%I 4
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1324 1514 a Fi(Fig.)16 b(1.)27 b Fn(Structure)g(of)h
+(Stores)606 2887 y @beginspecial 30 @llx 417 @lly 390
+@urx 605 @ury 2880 @rwi @setspecial
+%%BeginDocument: applic.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 11 def
+/arrowWidth 5 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 170 231 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 75 180 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -11 154 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 47 109 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 256 185 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 150 109 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 238 108 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 169 174 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 336 657 ] concat
+%I
+[
+(registration)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 250 646 ] concat
+%I
+[
+(src-1-sgi/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 249 581 ] concat
+%I
+[
+(doc/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 90 624 ] concat
+%I
+[
+(doc/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 136 581 ] concat
+%I
+[
+(include/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 328 580 ] concat
+%I
+[
+(include/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 168 651 ] concat
+%I
+[
+(src-1/)
+] Text
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 97 252 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 319 226 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 366 173 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 300 304 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 370 271 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 211 312 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -34 316 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 33.9999 288 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 314 784 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 403 775 ] concat
+%I
+[
+(doc/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 468 742 ] concat
+%I
+[
+(unzip/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 419 698 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 463 644 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 193 723 ] concat
+%I
+[
+(khym/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 131 760 ] concat
+%I
+[
+(store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 60 786 ] concat
+%I
+[
+(/store/)
+] Text
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 250 266 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 346 737 ] concat
+%I
+[
+(ver-1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 269 702 ] concat
+%I
+[
+(shar/)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -151 392 ] concat
+%I
+307 247 283 232 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -151 392 ] concat
+%I
+544 364 535 352 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 590 ] concat
+%I
+218 481 279 460 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 590 ] concat
+%I
+289 387 133 252 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 590 ] concat
+%I
+452 139 597 -8 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 623 ] concat
+%I
+394 228 390 136 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 623 ] concat
+%I
+616 390 512 324 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 623 ] concat
+%I
+510 262 681 172 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 623 ] concat
+%I
+617 560 674 500 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 182.75 623 ] concat
+%I
+802 386 909 328 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 266 672.5 ] concat
+%I
+776 310 690 352 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 321.5 623 ] concat
+%I
+490 216 562 123 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 99.5 524 ] concat
+%I
+693 397 661 272 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 99.5 524 ] concat
+%I
+322 420 261 270 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 99.5 656 ] concat
+%I
+277 345 353 300 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 99.5 656 ] concat
+%I
+22 468 79 433 Line
+%I 4
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1208 3070 a Fi(Fig.)15 b(2.)27 b Fn(Structure)h(of)f
+(Applications)365 3362 y(can)h(b)r(e)h(con\014gured)e(in)i(a)f(w)n(a)n
+(y)f(suitable)h(for)g(the)h(application.)f(F)-7 b(or)27
+b(instance,)i(a)f(linktree)365 3462 y(can)g(b)r(e)g(a)f(shado)n(w)f(of)
+i(another)e(linktree)i(shado)n(w.)490 3564 y(In)f(\014gure)f(3,)h(a)f
+(common)h(situation)f(is)h(sho)n(wn.)f(One)h(directory)f(con)n(tains)g
+(the)h(o\016cial)365 3663 y(source;)34 b(another)h(con)n(tains)f(lo)r
+(cal)h(\\hac)n(ks")e(and)i(con\014gurations,)f(whic)n(h)h(shado)n(ws)f
+(the)365 3763 y(o\016cial)26 b(source;)f(and)i(sev)n(eral)e
+(directories,)g(eac)n(h)g(con)n(taining)h(arc)n(hitecture-sp)r
+(eci\014c)f(con-)365 3863 y(\014guration)33 b(c)n(hanges,)f(whic)n(h)h
+(shado)n(ws)f(the)i(lo)r(cal)f(\\shado)n(w".)e(The)j(arro)n(ws)d(in)j
+(\014gure)f(3)365 3962 y(refers)27 b(to)g(linktree-inheritance,)g(i.e.)
+e(shado)n(wing.)490 4064 y(Eac)n(h)37 b(\\v)n(er-")e(directory)i(con)n
+(tains)g(p)r(ossibly)g(m)n(ultiple)i(hardw)n(are-v)-5
+b(arian)n(ts)34 b(of)k(one)365 4164 y(v)n(ersion)24 b(of)i(the)g
+(application.)f(Belo)n(w)g(the)h(\\v)n(er-")d(directory)-7
+b(,)25 b(the)h(structure)f(of)h(sub)r(direc-)365 4263
+y(tories)e(is)h(similar)f(to)h(the)g(structures)f(usually)h(found)g(in)
+g Fh(/usr/local)c Fn(and)k Fh(/usr)p Fn(.)e(Figure)365
+4363 y(4)k(sho)n(ws)g(in)h(detail)f(the)h(structure)f(under)h(a)f(\\v)n
+(er-")e(tree.)490 4465 y(In)39 b(order)f(to)h(sim)n(ultaneously)f
+(handle)h(supp)r(ort)g(for)g(m)n(ultiple)h(arc)n(hitectures,)e(one)365
+4565 y(need)29 b(a)g(metho)r(d)g(for)g(distinguishing)f(b)r(et)n(w)n
+(een)h(hardw)n(are)e(v)-5 b(arian)n(ts)28 b(of)h(a)f(\014le)i(in)f(the)
+g(\014le)365 4664 y(system)f(name)f(space.)g(This)g(is)g(done)g(b)n(y)h
+(adding)f(an)g(iden)n(ti\014er)g(su\016x)g(to)h(the)g(\014lenames.)365
+4764 y(F)-7 b(or)31 b(instance,)h(the)g(binary)f(\014le)h
+Fh(shar)f Fn(b)r(ecomes)g Fh(shar@sun4os4)c Fn(and)32
+b Fh(shar@hp700ux9)365 4863 y Fn(for)26 b(SunOS)g(4)f(on)h(Sparc)f(and)
+h(HP/UX)g(9.xx)f(on)h(HP-P)-7 b(A,)25 b(resp)r(ectiv)n(ely)-7
+b(.)26 b(In)g(Store)f(this)h(is)p eop
+%%Page: 6 6
+6 5 bop 948 1178 a @beginspecial 60 @llx 415 @lly 412
+@urx 546 @ury 2816 @rwi @setspecial
+%%BeginDocument: sources.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 11 def
+/arrowWidth 5 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1.85469 -0 -0 1.05263 277.053 85.895 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1.85469 -0 -0 1.05263 -61.9471 86.8948 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1.85469 -0 -0 1.05263 115.053 80.8948 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1.85469 -0 -0 1.05263 103.053 158.895 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1.85469 -0 -0 1.05263 206.053 212.895 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 266 655 ] concat
+%I
+[
+(src-1.00-local/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 387 709 ] concat
+%I
+[
+(src-1.00/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 443 581 ] concat
+%I
+[
+(src-1.00-sgi/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 89.9999 583 ] concat
+%I
+[
+(src-1.00-sun3os4/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 268 577 ] concat
+%I
+[
+(src-1.00-sun4os4/)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 524 ] concat
+%I
+246 460 0 258 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 524 ] concat
+%I
+742 649 636 553 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 524 ] concat
+%I
+723 478 1080 276 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 524 ] concat
+%I
+514 416 529 261 Line
+%I 4
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1291 1360 a Fi(Fig.)16 b(3.)27 b Fn(In)n(terrelationship)f
+(of)i(Source)e(Directories)762 2447 y @beginspecial 77
+@llx 275 @lly 485 @urx 418 @ury 3264 @rwi @setspecial
+%%BeginDocument: vertree.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 11 def
+/arrowWidth 5 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 270 68.9999 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 27.9999 -16.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 267 -17.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 497 -18.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 28.9999 -75 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 395 -18.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 148 -15.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 149 -77 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 398 -81 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 355 540 ] concat
+%I
+[
+(ver-1.22/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 129 456 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 125 395 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 237.5 454.75 ] concat
+%I
+[
+(emacs/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 369 454 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 249 397 ] concat
+%I
+[
+(info/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 494 389 ] concat
+%I
+[
+(bison/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 494 453 ] concat
+%I
+[
+(doc/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 602 451 ] concat
+%I
+[
+(lib/)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 127 376 ] concat
+%I
+43 229 43 128 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 127 376 ] concat
+%I
+525 231 526 122 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 376.75 376 ] concat
+%I
+525 220 525 105 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 265.75 409 ] concat
+%I
+386 448 -7 236 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 265.75 409 ] concat
+%I
+536 448 911 219 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 265.75 409 ] concat
+%I
+581 476 1328 220 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 265.75 409 ] concat
+%I
+457 437 456 228 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 265.75 409 ] concat
+%I
+347 472 -440 222 Line
+%I 4
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1511 2630 a Fi(Fig.)16 b(4.)27 b Fn(Structure)h(of)f(a)g
+(\\v)n(er-")f(T)-7 b(ree)681 2935 y(p)r(erhaps)27 b(a)g(bit)h(inelegan)
+n(t,)f(but)h(fairly)f(simple)h(and)f(v)n(ery)g(p)r(ortable)g(and)g
+(standard.)805 3044 y(The)h(names)e(of)i(the)f(arc)n(hitectures)f(are)g
+(de\014ned)i(hierarc)n(hically)-7 b(,)25 b(as)i(sho)n(wn)f(in)h
+(\014gure)681 3143 y(5.)21 b(Although)g(most)g(systems)g(only)g(need)h
+(the)g(name)f(of)g(the)h(OS,)f(some)g(need)g(to)h(b)r(e)f(related)681
+3243 y(to)32 b(the)h(exact)f(OS)g(release)f(lev)n(el,)i(or)e(ev)n(en)h
+(to)h(the)f(sp)r(eci\014c)h(con\014guration)e(of)h(a)h(k)n(ernel.)681
+3343 y(Normally)-7 b(,)26 b(only)h(\014les)g(are)f(giv)n(en)g(a)g
+(\014le)i(name)e(su\016x,)i(but)f(Store)g(also)f(supp)r(orts)g
+(su\016xes)681 3442 y(for)h(directories,)g(in)h(whic)n(h)g(case)f(all)h
+(\014les)g(in)g(that)g(directory)f(subtree)h(implicitly)h(inherit)681
+3542 y(the)f(directory)-7 b(.)805 3650 y(The)28 b(implemen)n(tation)h
+(of)f(Store)f(do)r(es)h(not)g(distinguish)g(b)r(et)n(w)n(een)g(OS-arc)n
+(hitectures)681 3750 y(and)34 b(hardw)n(are)e(arc)n(hitectures.)g
+(Although)i(these)h(are)e(t)n(w)n(o)g(di\013eren)n(t)h(dimensions)g
+(\(one)681 3850 y(OS)24 b(can)h(run)f(on)h(sev)n(eral)e(hardw)n(are)g
+(platforms,)h(and)g(eac)n(h)g(hardw)n(are)f(platform)i(can)f(run)681
+3949 y(man)n(y)33 b(OSes\),)h(w)n(e)g(ha)n(v)n(e)f(found)i(it)f(adv)-5
+b(an)n(tageous)32 b(to)i(collapse)f(these)i(t)n(w)n(o)e(dimensions)681
+4049 y(in)n(to)c(one.)h(The)g(reason)e(is)i(that)g(v)n(ery)e(few)j
+(\014les)e(for)h(one)f(OS)h(are)f(common)g(for)g(m)n(ultiple)681
+4148 y(hardw)n(are)38 b(platforms;)j(lik)n(ewise)f(for)g(\014les)h(sp)r
+(eci\014c)f(for)h(one)f(hardw)n(are)f(platform)h(but)681
+4248 y(common)31 b(for)h(m)n(ultiple)h(OSes.)f(W)-7 b(e)32
+b(migh)n(t)g(ha)n(v)n(e)f(implemen)n(ted)i(this)g(di\013eren)n(tly)f
+(if)h(our)681 4348 y(target)24 b(had)h(b)r(een)h(op)r(erating)e(system)
+h(soft)n(w)n(are)f(rather)g(than)i(third)f(part)n(y)g(applications.)805
+4456 y(W)-7 b(e)23 b(can)f(no)n(w)f(add)i(\014lenames)e(to)i(the)f
+(\014gure)g(sho)n(wing)f(the)i(subtree)e(of)i(a)f(\\v)n(er-")d(direc-)
+681 4556 y(tory)24 b(\(\014gure)g(4\).)h(Ov)-5 b(als)24
+b(denote)h(directories,)f(\014lenames)g(are)g(listed)h(b)r(elo)n(w)g
+(the)g(directory)681 4655 y(in)k(whic)n(h)g(they)g(are)f(lo)r(cated.)h
+(The)g(new,)g(expanded)f(\014gure)h(is)f(sho)n(wn)h(in)g(\014gure)f(6.)
+h(Files)681 4755 y(con)n(taining)d(the)i(\\@")f(c)n(haracter)e(and)j(a)
+f(su\016x,)g(are)g(arc)n(hitecture)f(dep)r(enden)n(t)j(\014les.)805
+4863 y(The)e(last)f(comp)r(onen)n(t)g(in)h(the)f(application)g
+(directory)f(is)i(the)f Fh(registration)c Fn(\014le.)k(It)p
+eop
+%%Page: 7 7
+7 6 bop 640 1911 a @beginspecial 108 @llx 197 @lly 458
+@urx 438 @ury 2800 @rwi @setspecial
+%%BeginDocument: archs.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 11 def
+/arrowWidth 5 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 77 -28 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 261 9 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 343 51 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 70 42 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 164 61 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 69 93 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 277 -58.9999 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 281 95 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 444 91 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 356 -14 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 187 -33 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 435 521 ] concat
+%I
+[
+(bigend)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 261 532 ] concat
+%I
+[
+(litend)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 171 514 ] concat
+%I
+[
+(i386)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 167 563 ] concat
+%I
+[
+(pmax)
+] Text
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 182 -83 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 458 -3 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 461 43 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 547 563 ] concat
+%I
+[
+(hp)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 563 514 ] concat
+%I
+[
+(ibm)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 557 468 ] concat
+%I
+[
+(m88k)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 362 483 ] concat
+%I
+[
+(sun)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 455 457 ] concat
+%I
+[
+(sun3)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 287 439 ] concat
+%I
+[
+(sparc)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 371 417 ] concat
+%I
+[
+(sparc)
+(netbsd)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 269.75 387.75 ] concat
+%I
+[
+(sun4os4)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 165 444 ] concat
+%I
+[
+(sun4os5)
+] Text
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 201 -138 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 106 -139 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 80 -86 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 279 -105 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 281 -173 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 172 -184 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 164 386 ] concat
+%I
+[
+(sun4os40)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 286.5 333 ] concat
+%I
+[
+(sun4os41)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 187.75 331.5 ] concat
+%I
+[
+(sun4os411)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 253.25 287 ] concat
+%I
+[
+(sun4os412)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 361.75 297.75 ] concat
+%I
+[
+(sun4os413)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 371 566 ] concat
+%I
+[
+(allarchs)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 359.5 366 ] concat
+%I
+[
+(sun4os41B)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+300 389 97 292 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+539 354 594 285 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+806 283 968 372 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+833 232 1028 212 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+800 185 1028 49 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+558 201 458 112 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+494 38 613 -4 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 282.5 458 ] concat
+%I
+232 25 146 -48 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 130 458 ] concat
+%I
+450 244 335 207 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 130 458 ] concat
+%I
+469 324 332 397 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+288 594 120 586 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+570 545 677 501 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+433 493 421 437 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+262 369 131 357 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+551 350 671 303 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+448 292 489 219 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+337 154 237 146 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+433 75 409 30 Line
+%I 4
+End
+
+Begin %I Line
+%I b 65535
+2 1 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.25 -0 -0 0.25 191 290.5 ] concat
+%I
+611 109 692 46 Line
+%I 4
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1192 2094 a Fi(Fig.)16 b(5.)27 b Fn(Structure)g(of)h(Arc)n
+(hitectures)370 3296 y @beginspecial 83 @llx 255 @lly
+514 @urx 418 @ury 3448 @rwi @setspecial
+%%BeginDocument: xvertree.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 11 def
+/arrowWidth 5 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 270 68.9999 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 267 -17.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 516 -13.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 393 -17.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 156 -17.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 397 -82.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 270 -80.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 591 428 ] concat
+%I
+[
+(bison@hpux)
+(bison@linux)
+(bison@m88k)
+(bison@sun4os4)
+(bison@sun4os5)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 239 423 ] concat
+%I
+[
+(bison.hairy)
+(bison.simple)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 361 364 ] concat
+%I
+[
+(bison.dvi)
+(bison.ps)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 356 541 ] concat
+%I
+[
+(ver-1.22/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 618 458 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 484 454 ] concat
+%I
+[
+(emacs/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 497 390 ] concat
+%I
+[
+(info/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 366 392 ] concat
+%I
+[
+(bison/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 368 454 ] concat
+%I
+[
+(doc/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 258 453 ] concat
+%I
+[
+(lib/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 487 361 ] concat
+%I
+[
+(bison.info)
+] Text
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 35 -15.0001 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Elli
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 38 -77.0002 ] concat
+%I
+111 466 33 17 Elli
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 134 364 ] concat
+%I
+[
+(bison.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 133 455 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 134 394 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 349.375 491 ] concat
+%I
+140 230 -539 -216 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 349.375 491 ] concat
+%I
+58 262 -1443 -224 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 529.75 449.75 ] concat
+%I
+-958 618 621 135 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 446.5 449.75 ] concat
+%I
+-386 567 403 126 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 321.625 449.75 ] concat
+%I
+471 545 472 129 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 113.5 400.25 ] concat
+%I
+262 272 263 45 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 321.625 400.25 ] concat
+%I
+465 254 464 21 Line
+%I 8
+End
+
+Begin %I Line
+%I b 65535
+2 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.125 -0 -0 0.125 460.375 400.25 ] concat
+%I
+359 254 359 5 Line
+%I 8
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1016 3479 a Fi(Fig.)16 b(6.)27 b Fn(Extended)h(structure)f
+(of)g(a)g(\\v)n(er-")f(T)-7 b(ree)365 3767 y(con)n(tains)23
+b(information)g(ab)r(out)h(the)g(application,)f(suc)n(h)h(as)f(the)h
+(name)g(of)g(the)g(application,)365 3867 y(the)37 b(source,)d(the)j
+(compilation)e(history)-7 b(,)35 b(who)h(is)g(resp)r(onsible)f(for)g
+(lo)r(cal)h(main)n(tenance,)365 3967 y(whic)n(h)29 b(v)n(ersions)d
+(that)j(are)e(a)n(v)-5 b(ailable)27 b(and)i(their)f(stabilit)n(y)-7
+b(,)28 b(etc.)h(It)g(can)f(b)r(e)g(considered)g(a)365
+4066 y(con\014guration)e(\014le)i(for)f(that)h(application.)490
+4166 y(The)h(system)g(as)g(it)h(has)f(b)r(een)g(describ)r(ed)g(so)g
+(far)g(is)g(not)h(v)n(ery)e(useful,)h(since)h(the)f(\014les)365
+4266 y(are)34 b(distributed)i(widely)f(in)h(a)f(large)e(n)n(um)n(b)r
+(er)i(of)g(directories.)f(Therefore,)g(the)i(second)365
+4365 y(part)k(of)g(Store)f(automatically)g(creates)f(a)i(linktree)g
+(under)f Fh(/store)p Fn(,)f(generated)h(from)365 4465
+y(all)29 b(applications)f(on)h(all)g(store)f(serv)n(ers.)f(E\013ectiv)n
+(ely)-7 b(,)29 b(it)h(creates)e(a)g(directory)g(hierarc)n(h)n(y)-7
+b(,)365 4565 y(whic)n(h)38 b(name)g(space)f(is)h(the)g(union)g(of)g
+(all)g(name)g(spaces)f(in)h(the)g(\\v)n(er-")e(trees)h(for)h(all)365
+4664 y(applications.)28 b(Ho)n(w)n(ev)n(er,)g(there)g(are)g(some)h
+(exceptions:)f(if)i(there)f(are)f(m)n(ultiple)h(v)n(ersions)365
+4764 y(of)24 b(an)g(application,)g(only)g(one)f(v)n(ersion)g(is)h(used)
+g(\(e.g.)h(the)g(new)n(est\);)f(if)h(there)f(are)f(m)n(ultiple)365
+4863 y(v)-5 b(arian)n(ts)34 b(of)h(a)g(\014le)g(\(for)g(sev)n(eral)e
+(arc)n(hitectures\),)h(only)h(the)g(\014le)h(most)f(relev)-5
+b(an)n(t)34 b(to)h(the)p eop
+%%Page: 8 8
+8 7 bop 701 368 a Fd(/sto)n(re/bin/bison)397 b Fc(->)q
+Fd(/sto)n(re/sto)n(re/khym/bison/ver-1.22/bin/bison@hpux)701
+460 y(/sto)n(re/lib/bison.hairy)240 b Fc(->)q Fd(/sto)n(re/sto)n
+(re/khym/bison/ver-1.22/lib/bison.hairy)701 551 y(/sto)n
+(re/lib/bison.simple)195 b Fc(->)q Fd(/sto)n(re/sto)n
+(re/khym/bison/ver-1.22/lib/bison.simple)701 642 y(/sto)n
+(re/man/man1/bison.1)85 b Fc(->)q Fd(/sto)n(re/sto)n
+(re/khym/bison/ver-1.22/man/man1/bison.1)701 734 y(/sto)n(re/do)r
+(c/bison/bison.dvi)63 b Fc(->)q Fd(/sto)n(re/sto)n
+(re/khym/bison/ver-1.22/bison/bison.dvi)701 825 y(/sto)n(re/do)r
+(c/bison/bison.ps)88 b Fc(->)q Fd(/sto)n(re/sto)n
+(re/khym/bison/ver-1.22/bison/bison.ps)701 916 y(/sto)n
+(re/emacs/info/bison.info)p Fc(->)s Fd(/sto)n(re/sto)n
+(re/khym/bison/ver-1.22/emacs/info/bison.info)1009 1097
+y Fi(Fig.)16 b(7.)27 b Fn(Symlinks)h(Generated)f(for)g(Application)h
+(in)f(Figure)g(6)h(\(HP\))681 1443 y(linktree)36 b(is)h(used,)g(and)f
+(the)i(su\016x)e(part)h(is)f(remo)n(v)n(ed)g(from)g(the)h(links)g(in)g
+(the)g Fh(/store)681 1542 y Fn(name)25 b(space.)h(The)f(linktree)h(is)g
+(a)f(view)h(in)n(to)f(the)i(\014le)f(rep)r(ository)e(under)i
+Fh(/store/store)p Fn(.)681 1642 y(F)-7 b(or)18 b(the)i(\014lenames)f
+(that)g(are)g(listed)g(in)h(\014gure)e(6,)h(the)h(corresp)r(onding)d
+(symlinks)i(generated)681 1742 y(are)26 b(listed)i(in)g(\014gure)f(7.)
+805 1847 y(Our)22 b(next)g(concerns)e(are)h(consistency)h(and)f(access)
+g(time.)i(Consistency)e(requires)f(that)681 1946 y(an)25
+b(application)f(is)h(only)g(stored)f(at)h(one)f(place)h(in)g(order)f
+(to)h(a)n(v)n(oid)f(t)n(w)n(o)g(div)n(erging)f(copies.)681
+2046 y(Access)29 b(time)g(requires)f(that)i(man)n(y)e(copies)h(are)f
+(distributed)i(among)e(the)i(computers)e(in)681 2146
+y(a)g(net)n(w)n(ork,)f(in)i(order)e(to)h(minimize)h(access)f(time)h
+(and)f(to)g(ensure)g(con)n(tin)n(uous)g(access)f(to)681
+2245 y(the)h(application)f(ev)n(en)g(if)h(parts)f(of)g(the)h(net)n(w)n
+(ork)e(are)h(inaccessible.)805 2350 y(In)39 b(order)f(to)g(satisfy)h
+(these)g(t)n(w)n(o)f(requiremen)n(ts,)f(Store)i(implemen)n(ts)g(\\sla)n
+(v)n(e)e(store)681 2450 y(serv)n(ers".)h(They)i(are)f(normal)g(stores,)
+h(except)g(that)g(applications)g(stored)f(on)h(a)g(sla)n(v)n(e)681
+2550 y(store)d(are)g(automatically)g(copied)g(from)h(the)g(normal)f
+(store)g(\(a.k.a.)24 b(\\master)37 b(store"\).)681 2649
+y(The)22 b(master)g(store)g(holds)g(a)g(rep)r(ository)f(of)h
+(application)g(co)r(de,)h(the)f(sla)n(v)n(e)f(stores)h(con)n(tains)681
+2749 y(replicas)e(of)h(it,)h(and)f(the)h(linktrees)f(pro)n(vides)f(a)g
+(view)i(in)f(to)g(the)h(rep)r(ositories)e(and)h(replicas.)681
+2849 y(Th)n(us,)31 b(consistency)g(is)g(ensured)g(b)n(y)h(uniqueness.)f
+(Ev)n(ery)f(piece)i(of)f(information)g(should)681 2948
+y(b)r(e)26 b(stored)e(at)i(only)f(one)g(lo)r(cation.)g(If)h(further)g
+(copies)e(are)h(required,)g(they)g(are)g(generated)681
+3048 y(from)i(the)h(master)f(cop)n(y)g(and)g(rep)r(eatedly)g(sync)n
+(hronized)f(later.)805 3153 y(All)32 b(main)n(tenance)e(is)g(p)r
+(erformed)h(at)f(the)i(master)e(serv)n(er.)f(The)h(main)h(function)g
+(of)g(a)681 3253 y(sla)n(v)n(e)18 b(store)g(is)i(mostly)f(to)h(cac)n
+(he)e(applications)h(from)g(the)h(master)f(serv)n(er)f(in)h(order)g(to)
+g(serv)n(e)681 3352 y(lo)r(cal)26 b(linktrees.)h(Calling)f(it)h
+(\\master")e(and)i(\\sla)n(v)n(e")e(serv)n(ers)f(is)j(a)g(bit)g
+(imprecise.)g(Stores)681 3452 y(are)33 b(either)h(masters)e(or)i(sla)n
+(v)n(es)e(on)h(a)h(p)r(er-application)f(basis:)g(Giv)n(en)h(t)n(w)n(o)f
+(serv)n(ers)f(and)681 3552 y(t)n(w)n(o)d(applications,)g(the)i(\014rst)
+e(serv)n(er)g(can)g(b)r(e)i(a)e(master)h(store)f(for)g(the)i(\014rst)e
+(application)681 3651 y(and)e(a)g(sla)n(v)n(e)f(store)h(for)g(the)h
+(second,)f(and)h(vice)f(v)n(ersa)f(for)h(the)h(second)f(store.)805
+3756 y(A)21 b(simple)f(directory)f(naming)h(con)n(v)n(en)n(tion)e
+(notes)i(the)g(di\013erence)g(b)r(et)n(w)n(een)h(sla)n(v)n(es)d(and)681
+3856 y(masters.)34 b(The)g(directory)g Fh(/store/store/khy)o(m/)o(tgr)o
+(in)o(d)29 b Fn(is)34 b(the)i(master)e(cop)n(y)-7 b(,)34
+b(while)681 3956 y Fh(/store/store/sto)o(rl)o(ind)o(/.)o(tg)o(rin)o(d)
+20 b Fn(is)26 b(a)f(replica,)g(due)i(to)e(the)i(name)f(starting)f(with)
+h(a)681 4055 y(dot.)f(This)g(con)n(v)n(en)n(tion)f(also)g(ensures)g
+(that)h(the)h(replica)e(directories)g(sta)n(y)g(out)h(of)g(sigh)n(t)f
+(in)681 4155 y(normal)i Fh(ls)p Fn(-listings.)805 4260
+y(Eac)n(h)k(linktree)g(under)g Fh(/store)e Fn(will)j(pic)n(k)f(an)g
+(application)g(from)g(a)g(master)g(or)f(sla)n(v)n(e)681
+4360 y(store)d(for)g(that)i(application,)e(and)h(it)g(p)r(oin)n(ts)g
+(its)h(symlinks)e(to)n(w)n(ards)f(it.)j(Whic)n(h)f(serv)n(er)e(it)681
+4459 y(c)n(ho)r(oses)31 b(dep)r(ends)h(on)h(whic)n(h)f(mac)n(hine)g(is)
+g(closest)g(measured)f(in)i(a)f(distance)g(metric,)g(a)681
+4559 y(metric)27 b(that)h(can)f(b)r(e)h(con\014gured)f(separately)f
+(for)h(eac)n(h)g Fh(/store)e Fn(linktree.)805 4664 y(Store)k(sla)n(v)n
+(e)e(serv)n(ers)g(only)h(cop)n(y)g(the)i(\014les)e(that)h(they)h(need,)
+f(i.e.)c(source)i(co)r(de)i(is)g(not)681 4764 y(copied,)g(are)g(arc)n
+(hitecture-dep)r(enden)n(t)g(\014les)h(for)f(hardw)n(are)f(that)i(none)
+f(of)h(the)g(linktrees)681 4863 y(connecting)d(to)g(that)h(serv)n(er)e
+(can)h(ev)n(er)g(use.)p eop
+%%Page: 9 9
+9 8 bop 365 387 a Fj(7)112 b(A)37 b(F)-9 b(ull-Scale)37
+b(Example)365 596 y Fn(T)-7 b(o)31 b(\015esh)f(out)h(the)g(description)
+g(giv)n(en)f(in)h(the)g(previous)e(section,)i(w)n(e)f(here)h(sho)n(w)f
+(a)g(full-)365 695 y(scale)39 b(example,)h(in)n(v)n(olving)e(t)n(w)n(o)
+h(stores,)f(one)i(application,)f(four)g(linktrees,)g(and)h(four)365
+795 y(arc)n(hitectures.)490 896 y(The)24 b(application)g(in)g(question)
+g(is)g(\\mpage",)e(whic)n(h)i(consists)g(of)g(a)g(binary)f(\014le)h
+Fh(mpage)365 996 y Fn(\(arc)n(hitecture)37 b(dep)r(enden)n(t\),)i(and)e
+(a)h(man)n(ual)e(page)h Fh(mpage.1)e Fn(\(arc)n(hitecture)i(indep)r
+(en-)365 1096 y(den)n(t\).)22 b(Figure)e(8)h(sho)n(ws)e(part)i(of)g
+(the)g(\014le)g(system)g(on)f(four)h(mac)n(hines:)f(kh)n(ym)h(and)g
+(storlind)365 1195 y(are)30 b(serv)n(ers,)e(master)h(and)h(sla)n(v)n(e)
+f(resp)r(ectiv)n(ely;)h(dekk)g(and)g(c)n(h)n(ur)f(are)h(linktree-only)f
+(ma-)365 1295 y(c)n(hines.)f(In)h(this)f(\014gure,)g(dotted,)h(p)r(oin)
+n(ted)f(lines)g(indicate)h(NFS-moun)n(ts;)f(solid,)g(p)r(oin)n(ted)365
+1394 y(lines)20 b(indicate)g(symlinks;)g(fat)g(lines)g(indicate)g
+(directory)f(structure;)h(and)g(thin)g(lines)g(group)365
+1494 y(directories)26 b(and)i(\014les)f(ph)n(ysically)g(b)r(elonging)g
+(on)g(one)g(mac)n(hine.)411 3648 y @beginspecial 2 @llx
+374 @lly 560 @urx 763.062500 @ury 3348 @rwi @setspecial
+%%BeginDocument: clients.eps
+
+/arrowhead {
+0 begin
+transform originalCTM itransform
+/taily exch def
+/tailx exch def
+transform originalCTM itransform
+/tipy exch def
+/tipx exch def
+/dy tipy taily sub def
+/dx tipx tailx sub def
+/angle dx 0 ne dy 0 ne or { dy dx atan } { 90 } ifelse def
+gsave
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+patternNone not {
+originalCTM setmatrix
+/padtip arrowHeight 2 exp 0.25 arrowWidth 2 exp mul add sqrt brushWidth mul
+arrowWidth div def
+/padtail brushWidth 2 div def
+tipx tipy translate
+angle rotate
+padtip 0 translate
+arrowHeight padtip add padtail add arrowHeight div dup scale
+arrowheadpath
+ifill
+} if
+brushNone not {
+originalCTM setmatrix
+tipx tipy translate
+angle rotate
+arrowheadpath
+istroke
+} if
+grestore
+end
+} dup 0 9 dict put def
+
+/arrowheadpath {
+newpath
+arrowHeight neg arrowWidth 2 div moveto
+0 0 lineto
+arrowHeight neg arrowWidth 2 div neg lineto
+} def
+
+/leftarrow {
+0 begin
+y exch get /taily exch def
+x exch get /tailx exch def
+y exch get /tipy exch def
+x exch get /tipx exch def
+brushLeftArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+/rightarrow {
+0 begin
+y exch get /tipy exch def
+x exch get /tipx exch def
+y exch get /taily exch def
+x exch get /tailx exch def
+brushRightArrow { tipx tipy tailx taily arrowhead } if
+end
+} dup 0 4 dict put def
+
+
+/arrowHeight 8 def
+/arrowWidth 4 def
+
+/IdrawDict 51 dict def
+IdrawDict begin
+
+/reencodeISO {
+dup dup findfont dup length dict begin
+{ 1 index /FID ne { def }{ pop pop } ifelse } forall
+/Encoding ISOLatin1Encoding def
+currentdict end definefont
+} def
+
+/ISOLatin1Encoding [
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright
+/parenleft/parenright/asterisk/plus/comma/minus/period/slash
+/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon
+/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N
+/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright
+/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m
+/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/dotlessi/grave/acute/circumflex/tilde/macron/breve
+/dotaccent/dieresis/.notdef/ring/cedilla/.notdef/hungarumlaut
+/ogonek/caron/space/exclamdown/cent/sterling/currency/yen/brokenbar
+/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot
+/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior
+/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine
+/guillemotright/onequarter/onehalf/threequarters/questiondown
+/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla
+/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute
+/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis
+/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave
+/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex
+/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis
+/yacute/thorn/ydieresis
+] def
+/Helvetica reencodeISO def
+
+/none null def
+/numGraphicParameters 17 def
+/stringLimit 65535 def
+
+/Begin {
+save
+numGraphicParameters dict begin
+} def
+
+/End {
+end
+restore
+} def
+
+/SetB {
+dup type /nulltype eq {
+pop
+false /brushRightArrow idef
+false /brushLeftArrow idef
+true /brushNone idef
+} {
+/brushDashOffset idef
+/brushDashArray idef
+0 ne /brushRightArrow idef
+0 ne /brushLeftArrow idef
+/brushWidth idef
+false /brushNone idef
+} ifelse
+} def
+
+/SetCFg {
+/fgblue idef
+/fggreen idef
+/fgred idef
+} def
+
+/SetCBg {
+/bgblue idef
+/bggreen idef
+/bgred idef
+} def
+
+/SetF {
+/printSize idef
+/printFont idef
+} def
+
+/SetP {
+dup type /nulltype eq {
+pop true /patternNone idef
+} {
+dup -1 eq {
+/patternGrayLevel idef
+/patternString idef
+} {
+/patternGrayLevel idef
+} ifelse
+false /patternNone idef
+} ifelse
+} def
+
+/BSpl {
+0 begin
+storexyn
+newpath
+n 1 gt {
+0 0 0 0 0 0 1 1 true subspline
+n 2 gt {
+0 0 0 0 1 1 2 2 false subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 2 copy false subspline
+} if
+n 2 sub dup n 1 sub dup 2 copy 2 copy false subspline
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Circ {
+newpath
+0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/CBSpl {
+0 begin
+dup 2 gt {
+storexyn
+newpath
+n 1 sub dup 0 0 1 1 2 2 true subspline
+1 1 n 3 sub {
+/i exch def
+i 1 sub dup i dup i 1 add dup i 2 add dup false subspline
+} for
+n 3 sub dup n 2 sub dup n 1 sub dup 0 0 false subspline
+n 2 sub dup n 1 sub dup 0 0 1 1 false subspline
+patternNone not { ifill } if
+brushNone not { istroke } if
+} {
+Poly
+} ifelse
+end
+} dup 0 4 dict put def
+
+/Elli {
+0 begin
+newpath
+4 2 roll
+translate
+scale
+0 0 1 0 360 arc
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 1 dict put def
+
+/Line {
+0 begin
+2 storexyn
+newpath
+x 0 get y 0 get moveto
+x 1 get y 1 get lineto
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+0 0 1 1 rightarrow
+end
+} dup 0 4 dict put def
+
+/MLine {
+0 begin
+storexyn
+newpath
+n 1 gt {
+x 0 get y 0 get moveto
+1 1 n 1 sub {
+/i exch def
+x i get y i get lineto
+} for
+patternNone not brushLeftArrow not brushRightArrow not and and { ifill } if
+brushNone not { istroke } if
+0 0 1 1 leftarrow
+n 2 sub dup n 1 sub dup rightarrow
+} if
+end
+} dup 0 4 dict put def
+
+/Poly {
+3 1 roll
+newpath
+moveto
+-1 add
+{ lineto } repeat
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+} def
+
+/Rect {
+0 begin
+/t exch def
+/r exch def
+/b exch def
+/l exch def
+newpath
+l b moveto
+l t lineto
+r t lineto
+r b lineto
+closepath
+patternNone not { ifill } if
+brushNone not { istroke } if
+end
+} dup 0 4 dict put def
+
+/Text {
+ishow
+} def
+
+/idef {
+dup where { pop pop pop } { exch def } ifelse
+} def
+
+/ifill {
+0 begin
+gsave
+patternGrayLevel -1 ne {
+fgred bgred fgred sub patternGrayLevel mul add
+fggreen bggreen fggreen sub patternGrayLevel mul add
+fgblue bgblue fgblue sub patternGrayLevel mul add setrgbcolor
+eofill
+} {
+eoclip
+originalCTM setmatrix
+pathbbox /t exch def /r exch def /b exch def /l exch def
+/w r l sub ceiling cvi def
+/h t b sub ceiling cvi def
+/imageByteWidth w 8 div ceiling cvi def
+/imageHeight h def
+bgred bggreen bgblue setrgbcolor
+eofill
+fgred fggreen fgblue setrgbcolor
+w 0 gt h 0 gt and {
+l w add b translate w neg h scale
+w h true [w 0 0 h neg 0 h] { patternproc } imagemask
+} if
+} ifelse
+grestore
+end
+} dup 0 8 dict put def
+
+/istroke {
+gsave
+brushDashOffset -1 eq {
+[] 0 setdash
+1 setgray
+} {
+brushDashArray brushDashOffset setdash
+fgred fggreen fgblue setrgbcolor
+} ifelse
+brushWidth setlinewidth
+originalCTM setmatrix
+stroke
+grestore
+} def
+
+/ishow {
+0 begin
+gsave
+fgred fggreen fgblue setrgbcolor
+/fontDict printFont printSize scalefont dup setfont def
+/descender fontDict begin 0 [FontBBox] 1 get FontMatrix end
+transform exch pop def
+/vertoffset 1 printSize sub descender sub def {
+0 vertoffset moveto show
+/vertoffset vertoffset printSize sub def
+} forall
+grestore
+end
+} dup 0 3 dict put def
+/patternproc {
+0 begin
+/patternByteLength patternString length def
+/patternHeight patternByteLength 8 mul sqrt cvi def
+/patternWidth patternHeight def
+/patternByteWidth patternWidth 8 idiv def
+/imageByteMaxLength imageByteWidth imageHeight mul
+stringLimit patternByteWidth sub min def
+/imageMaxHeight imageByteMaxLength imageByteWidth idiv patternHeight idiv
+patternHeight mul patternHeight max def
+/imageHeight imageHeight imageMaxHeight sub store
+/imageString imageByteWidth imageMaxHeight mul patternByteWidth add string def
+0 1 imageMaxHeight 1 sub {
+/y exch def
+/patternRow y patternByteWidth mul patternByteLength mod def
+/patternRowString patternString patternRow patternByteWidth getinterval def
+/imageRow y imageByteWidth mul def
+0 patternByteWidth imageByteWidth 1 sub {
+/x exch def
+imageString imageRow x add patternRowString putinterval
+} for
+} for
+imageString
+end
+} dup 0 12 dict put def
+
+/min {
+dup 3 2 roll dup 4 3 roll lt { exch } if pop
+} def
+
+/max {
+dup 3 2 roll dup 4 3 roll gt { exch } if pop
+} def
+
+/midpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 x1 add 2 div
+y0 y1 add 2 div
+end
+} dup 0 4 dict put def
+
+/thirdpoint {
+0 begin
+/y1 exch def
+/x1 exch def
+/y0 exch def
+/x0 exch def
+x0 2 mul x1 add 3 div
+y0 2 mul y1 add 3 div
+end
+} dup 0 4 dict put def
+
+/subspline {
+0 begin
+/movetoNeeded exch def
+y exch get /y3 exch def
+x exch get /x3 exch def
+y exch get /y2 exch def
+x exch get /x2 exch def
+y exch get /y1 exch def
+x exch get /x1 exch def
+y exch get /y0 exch def
+x exch get /x0 exch def
+x1 y1 x2 y2 thirdpoint
+/p1y exch def
+/p1x exch def
+x2 y2 x1 y1 thirdpoint
+/p2y exch def
+/p2x exch def
+x1 y1 x0 y0 thirdpoint
+p1x p1y midpoint
+/p0y exch def
+/p0x exch def
+x2 y2 x3 y3 thirdpoint
+p2x p2y midpoint
+/p3y exch def
+/p3x exch def
+movetoNeeded { p0x p0y moveto } if
+p1x p1y p2x p2y p3x p3y curveto
+end
+} dup 0 17 dict put def
+
+/storexyn {
+/n exch def
+/y n array def
+/x n array def
+n 1 sub -1 0 {
+/i exch def
+y i 3 2 roll put
+x i 3 2 roll put
+} for
+} def
+
+/SSten {
+fgred fggreen fgblue setrgbcolor
+dup true exch 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+/FSten {
+dup 3 -1 roll dup 4 1 roll exch
+newpath
+0 0 moveto
+dup 0 exch lineto
+exch dup 3 1 roll exch lineto
+0 lineto
+closepath
+bgred bggreen bgblue setrgbcolor
+eofill
+SSten
+} def
+
+/Rast {
+exch dup 3 1 roll 1 0 0 -1 0 6 -1 roll matrix astore
+} def
+
+
+%I Idraw 10 Grid 8 8
+
+
+Begin
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 0.754552 0 0 0.754552 0 0 ] concat
+/originalCTM matrix currentmatrix def
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 209 632 ] concat
+%I
+[
+(mpage@sun4os4)
+(mpage@sgi)
+(mpage@linux)
+(mpage@netbsd)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 242 817 ] concat
+%I
+[
+(store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 270 783 ] concat
+%I
+[
+(khym/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 254 749 ] concat
+%I
+[
+(mpage/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 285 705 ] concat
+%I
+[
+(ver-2.13/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 191 857 ] concat
+%I
+[
+(/store)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 277 672 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 332 677 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 328 639 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 325 603 ] concat
+%I
+[
+(mpage.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 192 810 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 137 810 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 129 768 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 123 734 ] concat
+%I
+[
+(mpage.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 199 767 ] concat
+%I
+[
+(mpage)
+] Text
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 58 361 ] concat
+%I 11
+88 355
+84 333
+83 299
+90 268
+104 239
+121 217
+150 203
+184 205
+218 212
+252 225
+263 231
+11 BSpl
+%I 1
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 315 731 ] concat
+%I
+[
+(registration)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 199 712 ] concat
+%I
+[
+(src-2.13)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 192 689 ] concat
+%I
+[
+(src-2.13-sun)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 560 810 ] concat
+%I
+[
+(store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 557 764 ] concat
+%I
+[
+(khym/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 620 689 ] concat
+%I
+[
+(ver-2.13/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 607 648 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 664 650 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 659 608 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 658 579 ] concat
+%I
+[
+(mpage.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 495 800 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 457 799 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 451 756 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 454 713 ] concat
+%I
+[
+(mpage.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 505 746 ] concat
+%I
+[
+(mpage)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 551 700 ] concat
+%I
+[
+(registration)
+] Text
+End
+
+Begin %I BSpl
+%I b 65520
+2 0 1 [12 4] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 30 361 ] concat
+%I 8
+528 413
+505 446
+462 470
+421 481
+357 481
+322 466
+279 442
+269 428
+8 BSpl
+%I 1
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 554 615 ] concat
+%I
+[
+(mpage@sun4os4)
+(mpage@netbsd)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 69 971 ] concat
+%I
+[
+(/store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 25 935 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 15 896 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 74 934 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 125 934 ] concat
+%I
+[
+(store/)
+] Text
+End
+
+Begin %I BSpl
+%I b 65520
+2 0 1 [12 4] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -63 559 ] concat
+%I 7
+221 338
+250 336
+288 322
+322 302
+347 277
+351 257
+352 236
+7 BSpl
+%I 1
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 10 859 ] concat
+%I
+[
+(mpage.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 66 905 ] concat
+%I
+[
+(mpage)
+] Text
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -63 493 ] concat
+%I 16
+99 350
+102 309
+113 249
+122 218
+143 174
+158 151
+176 124
+192 104
+217 82
+249 65
+278 58
+295 57
+310 57
+342 64
+364 74
+393 93
+16 BSpl
+%I 1
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 527 969 ] concat
+%I
+[
+(/store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 583 939 ] concat
+%I
+[
+(store/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 438 912 ] concat
+%I
+[
+(man1/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 461 938 ] concat
+%I
+[
+(man/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 511 939 ] concat
+%I
+[
+(bin/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 614 909 ] concat
+%I
+[
+(storlind/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 399 886 ] concat
+%I
+[
+(mpage.1)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 507 908 ] concat
+%I
+[
+(mpage)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 122 900 ] concat
+%I
+[
+(khym/)
+] Text
+End
+
+Begin %I CBSpl
+%I b 65535
+1 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 10
+63 502
+24 455
+21 399
+18 342
+35 307
+100 323
+201 392
+209 475
+137 508
+96 507
+10 CBSpl
+End
+
+Begin %I CBSpl
+%I b 65535
+1 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 10
+567 507
+480 486
+418 453
+366 380
+432 344
+525 387
+616 395
+728 369
+718 452
+642 491
+10 CBSpl
+End
+
+Begin %I CBSpl
+%I b 65535
+1 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 11
+245 398
+176 358
+120 307
+62 226
+94 88
+209 36
+328 47
+415 99
+419 199
+388 307
+320 375
+11 CBSpl
+End
+
+Begin %I CBSpl
+%I b 65535
+1 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 10
+752 45
+736 152
+703 263
+642 334
+601 367
+511 374
+422 324
+423 207
+441 54
+577 6
+10 CBSpl
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 353 982 ] concat
+%I
+[
+(Linktree-only of )
+(server storlind)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 240 897 ] concat
+%I
+[
+(Masterserver )
+( khym)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 667 792 ] concat
+%I
+[
+(Slaveserver)
+( storlind)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+98 461 97 446 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+78 464 58 449 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+117 464 145 448 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+49 428 45 407 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+41 391 41 370 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+96 429 96 417 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+150 430 150 414 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+536 463 499 449 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+553 461 540 448 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+575 465 603 452 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+478 434 470 423 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+456 409 441 396 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+538 434 536 418 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+625 435 645 421 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+209 351 168 320 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+220 350 216 324 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+230 349 263 331 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+163 305 159 281 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+156 264 155 246 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+216 305 227 280 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+275 312 291 296 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+295 280 290 262 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+271 243 248 224 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+280 241 266 202 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+295 243 316 218 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+312 252 326 241 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+309 202 302 183 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+342 200 353 187 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+354 173 354 151 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+359 136 358 113 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+514 344 486 309 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+525 343 518 313 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+539 345 577 324 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+480 293 479 268 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+481 250 480 229 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+517 292 527 262 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+589 302 584 276 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+602 304 631 283 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+637 267 640 245 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+622 232 600 212 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+643 226 654 203 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+647 183 633 159 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+666 184 685 162 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+688 145 687 122 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I
+688 103 687 90 Line
+%I 1
+End
+
+Begin %I BSpl
+%I b 65520
+2 0 1 [12 4] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 4
+660 403
+667 368
+660 318
+642 282
+4 BSpl
+%I 1
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 7
+537 240
+531 218
+521 194
+513 168
+516 134
+531 112
+561 117
+7 BSpl
+%I 1
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 11
+513 402
+481 369
+455 333
+444 282
+449 226
+456 172
+468 124
+481 91
+516 89
+544 96
+561 104
+11 BSpl
+%I 1
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 8
+95 395
+96 354
+102 270
+108 197
+130 143
+154 122
+180 123
+214 124
+8 BSpl
+%I 1
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -12 493 ] concat
+%I 7
+230 254
+214 234
+195 204
+182 175
+178 146
+184 133
+214 135
+7 BSpl
+%I 1
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 315 871 ] concat
+%I
+[
+(SunOS)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 692 766 ] concat
+%I
+[
+(SunOS)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 369 957 ] concat
+%I
+[
+(netbsd)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 604 770 ] concat
+%I
+[
+(storlind/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 615 734 ] concat
+%I
+[
+(.mpage/)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 496 851 ] concat
+%I
+[
+(/store/)
+] Text
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1 -0 -0 1 -364.664 476.106 ] concat
+%I
+647 183 633 159 Line
+%I 1
+End
+
+Begin %I Line
+%I b 65535
+3 0 0 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 1.05588 -0 -0 1.05588 70.744 460.364 ] concat
+%I
+512 165 498 152 Line
+%I 1
+End
+
+Begin %I Pict
+%I b u
+%I cfg u
+%I cbg u
+%I f u
+%I p u
+%I t
+[ 1 0 0 1 27.4529 -14.7823 ] concat
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 145 1004 ] concat
+%I
+[
+(Linktree-only of )
+( server "khym")
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 186 978 ] concat
+%I
+[
+(SGI)
+] Text
+End
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 140.15 1019.74 ] concat
+%I
+[
+(chur:)
+] Text
+End
+
+End %I eop
+
+Begin %I Text
+%I cfg Black
+0 0 0 SetCFg
+%I f -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-*-*
+Helvetica 12 SetF
+%I t
+[ 1 0 0 1 355.497 996.777 ] concat
+%I
+[
+(dekk:)
+] Text
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.633041 -0 -0 0.633041 46.8451 483.644 ] concat
+%I 9
+585 609
+574 522
+588 411
+602 299
+632 159
+698 84
+793 65
+912 83
+974 128
+9 BSpl
+%I 2
+End
+
+Begin %I BSpl
+%I b 65535
+2 0 1 [] 0 SetB
+%I cfg Black
+0 0 0 SetCFg
+%I cbg White
+1 1 1 SetCBg
+none SetP %I p n
+%I t
+[ 0.633041 -0 -0 0.633041 46.8451 483.644 ] concat
+%I 10
+681 335
+675 301
+673 247
+684 198
+706 152
+733 117
+779 95
+834 93
+890 100
+960 138
+10 BSpl
+%I 2
+End
+
+End %I eop
+
+showpage
+
+
+end
+%%EndDocument
+ @endspecial 1019 3831 a Fi(Fig.)15 b(8.)27 b Fn(F)-7
+b(ull-Scale)28 b(Example)e(of)i(Store)f(System)490 4164
+y(The)e(\014gure)f(sho)n(ws)f(that)i(the)g(sla)n(v)n(e)e(serv)n(er)g
+(only)h(copies)h(the)g(\014les)f(for)g(\\sun4os4")e(and)365
+4264 y(386)e(\\netbsd",)h(the)h(t)n(w)n(o)f(arc)n(hitectures)f(it)i
+(serv)n(es.)e(Names)h(ending)h(with)g(a)f(\\/"-c)n(haracter)365
+4363 y(refer)29 b(to)g(directories.)e(The)j(linktrees)e(generated)g
+(for)h(the)g(four)g(mac)n(hines)g(are)f(sho)n(wn)g(in)365
+4463 y(\014gure)f(9.)490 4565 y(Compared)f(with)i(a)f(traditional)g
+Fh(/usr/local)c Fn(directory)j(structure,)h(there)h(are)e(sev-)365
+4664 y(eral)d(practical)f(adv)-5 b(an)n(tages)22 b(of)h(this)h(sc)n
+(heme:)f(Giv)n(en)g(a)g(\014le)h(in)f(Store,)g(one)g(can)g(determine)
+365 4764 y(whic)n(h)k(application)f(and)g(v)n(ersion)g(it)h(b)r(elongs)
+f(to)g(merely)g(b)n(y)h(lo)r(oking)e(at)i(what)g(the)g(sym-)365
+4863 y(b)r(olic)33 b(link)g(expands)f(to.)g(By)h(follo)n(wing)e(the)i
+(sym)n(b)r(olic)g(link,)g(w)n(e)f(can)g(\014nd)h(an)n(y)f(and)h(all)p
+eop
+%%Page: 10 10
+10 9 bop 1740 368 a Fl(F)-6 b(or)25 b(master)h(store)g(kh)n(ym)680
+460 y Fd(/sto)n(re/bin/mpage)315 b Fc(->)p Fd(/sto)n(re/sto)n
+(re/khym/mpage/ver-2.13/bin/mpage@sun4os4)680 551 y(/sto)n
+(re/man/man1/mpage.1)p Fc(->)s Fd(/sto)n(re/sto)n
+(re/khym/mpage/ver-2.13/man/man1/mpage.)q(1)p 669 615
+2907 4 v 1840 679 a Fl(F)-6 b(or)26 b(linktree)g(c)n(h)n(ur)681
+770 y Fd(/sto)n(re/bin/mpage)314 b Fc(->)p Fd(/sto)n(re/sto)n
+(re/khym/mpage/ver-2.13/bin/mpage@sgi)681 861 y(/sto)n
+(re/man/man1/mpage.1)p Fc(->)r Fd(/sto)n(re/sto)n
+(re/khym/mpage/ver-2.13/man/man1/mpage.)q(1)p 669 925
+V 1737 989 a Fl(F)-6 b(or)26 b(sla)n(v)n(e)g(store)h(storlind)681
+1081 y Fd(/sto)n(re/bin/mpage)314 b Fc(->)p Fd(/sto)n(re/sto)n(re/sto)n
+(rlind/.mpage/ver-2.13/bin/mpage@sun4os4)681 1172 y(/sto)n
+(re/man/man1/mpage.1)p Fc(->)r Fd(/sto)n(re/sto)n
+(re/khym/mpage/ver-2.13/man/man1/mpage.)q(1)p 669 1236
+V 1834 1300 a Fl(F)-6 b(or)26 b(linktree)g(dekk)681 1391
+y Fd(/sto)n(re/bin/mpage)314 b Fc(->)p Fd(/sto)n(re/sto)n(re/sto)n
+(rlind/.mpage/ver-2.13/bin/mpage@netbsd)681 1482 y(/sto)n
+(re/man/man1/mpage.1)p Fc(->)r Fd(/sto)n(re/sto)n
+(re/khym/mpage/ver-2.13/man/man1/mpage.)q(1)1388 1659
+y Fi(Fig.)16 b(9.)27 b Fn(Symlinks)h(Generated)f(for)g(Figure)g(8)681
+1990 y(other)g(\014les)g(related)g(to)h(that)g(particular)e(v)n(ersion)
+g(of)i(the)f(application.)805 2091 y(Users)c(get)f(their)h(traditional)
+f Fh(/usr/local)d Fn(directory)j(structure)g(\(although)h(as)f(sym-)681
+2190 y(links\),)e(while)h(system)f(administrators)e(get)i(eac)n(h)f
+(application)h(separated)f(from)h(the)g(other)681 2290
+y(applications.)j(This)h(means)f(b)r(etter)h(o)n(v)n(erview)e(and)i
+(easier)f(system)g(main)n(tenance.)h(It)g(also)681 2390
+y(helps)j(automatic)g(generation)g(of)g(user)g(do)r(cumen)n(tation.)805
+2490 y(Eac)n(h)22 b(linktree)g(ma)n(y)g(b)r(e)h(con\014gured)f(to)g
+(comply)g(with)i(v)-5 b(arious)21 b(p)r(olicies)h(for)g(up)r(dating)681
+2590 y(to)34 b(new)h(v)n(ersions.)e(\\Progressiv)n(e")e(linktrees)j
+(upgrade)f(to)i(the)g(new)n(est)g(v)n(ersion)e(of)i(an)n(y)681
+2690 y(application,)20 b(ev)n(en)h(if)g(it)g(mark)n(ed)f(as)g
+(alpha-test)h(soft)n(w)n(are.)e(\\Co)n(w)n(ard")f(linktrees)i(only)h
+(use)681 2789 y(v)n(ersions)f(mark)n(ed)g(as)h(stable.)g(Bet)n(w)n(een)
+g(these,)h(sev)n(eral)d(other)i(p)r(olicies)h(exist.)f(In)h(addition)
+681 2889 y(p)r(olicies)h(ma)n(y)f(include)h(the)h(application's)e
+(origin,)g(i.e.)j(whic)n(h)e(stores)f(the)h(linktree)g(trusts.)805
+2989 y(Store)37 b(is)h(main)n(tained)f(b)n(y)g(a)g(n)n(um)n(b)r(er)g
+(of)h(P)n(erl)e(scripts.)h(The)g(scripts)g(p)r(erform)g(the)681
+3089 y(ma)5 b(jorit)n(y)25 b(of)i(the)g(tasks)g(needed,)g(except)g(for)
+f(most)h(of)f(the)i(compilation)e(pro)r(cess,)g(whic)n(h)681
+3189 y(ha)n(v)n(e)g(pro)n(v)n(ed)g(di\016cult)j(to)e(automate)g(on)g(a)
+h(general)e(basis.)681 3462 y Fj(8)112 b(Where)37 b(is)g(it)f(Being)h
+(Used?)681 3666 y Fn(Curren)n(tly)-7 b(,)32 b(Store)g(is)g(b)r(eing)h
+(used)g(at)f(the)h(Univ)n(ersit)n(y)f(of)h(T)-7 b(rondheim,)32
+b(where)g(10-20)f(of)681 3766 y(its)20 b(departmen)n(ts)g(and)g
+(faculties)g(co)r(op)r(erate)f(in)h(administering)g(third-part)n(y)f
+(applications)681 3865 y(through)f(a)h(common)g(Store)f(installation.)h
+(A)g(total)g(of)g(300)f(Unix)h(mac)n(hines)g(emplo)n(y)f(Store,)681
+3965 y(that)28 b(is)f(appro)n(ximately)f(half)i(the)g(n)n(um)n(b)r(er)f
+(of)h(Unix)f(mac)n(hines)g(at)h(the)g(Univ)n(ersit)n(y)-7
+b(.)805 4065 y(More)24 b(than)h(400)e(applications)h(are)g(installed)g
+(in)h(Store.)f(The)h(degree)f(to)g(whic)n(h)h(hard-)681
+4165 y(w)n(are)c(platforms)h(are)f(co)n(v)n(ered)g(v)-5
+b(aries.)21 b(Ho)n(w)n(ev)n(er,)f(most)j(of)f(the)h(common)f(Unix)g
+(platforms)681 4265 y(\(around)31 b(10\))h(are)f(reasonably)f(co)n(v)n
+(ered.)h(When)h(c)n(hec)n(k)n(ed,)f(appro)n(ximately)g(one)h(half)g(to)
+681 4364 y(t)n(w)n(o)27 b(thirds)h(of)h(the)f(most)g(frequen)n(tly)g
+(used)g(user-commands)f(at)h(a)g(t)n(ypical)g(w)n(orkstation)681
+4464 y(w)n(ere)f(loaded)f(from)i(Store.)f(The)h(remaining)e(commands)h
+(t)n(ypically)h(w)n(ere)e(shells)i(\(should)681 4564
+y(alw)n(a)n(ys)d(reside)i(under)h Fh(/bin)p Fn(\))e(and)i(standard)e
+(Unix)i(commands.)805 4664 y(Initial)38 b(installations)e(on)h
+(institutions)h(outside)f(the)h(Univ)n(ersit)n(y)f(of)g(T)-7
+b(rondheim)37 b(is)681 4764 y(b)r(eing)31 b(done,)h(although)e(none)i
+(of)f(these)h(are)e(y)n(et)h(of)h(the)g(same)e(size)i(as)e(the)i
+(installation)681 4863 y(at)27 b(the)h(Univ)n(ersit)n(y)f(of)g(T)-7
+b(rondheim.)p eop
+%%Page: 11 11
+11 10 bop 365 387 a Fj(9)112 b(Exp)s(eriences)365 619
+y Fn(W)-7 b(e)28 b(ha)n(v)n(e)f(learned)f(man)n(y)i(lessons)e(while)i
+(w)n(orking)e(with)i(Store.)365 833 y Fi(Higher)k(comp)s(etence.)41
+b Fn(While)35 b(Store)f(decreased)g(the)h(amoun)n(t)g(of)g(system)g(w)n
+(ork)e(re-)506 933 y(quired,)j(it)h(increased)e(the)h(need)h(for)e
+(those)h(few)n(er)g(p)r(ersons)f(to)h(ha)n(v)n(e)f(b)r(etter)i(skills)
+506 1033 y(regarding)26 b(the)i(applications)f(they)g(manage.)365
+1139 y Fi(Prev)-5 b(alence.)43 b Fn(As)25 b(so)r(on)f(as)g(w)n(e)h
+(reac)n(hed)e(a)i(threshold)f(\(i.e.)i(a)e(large)g(n)n(um)n(b)r(er)g
+(of)h(applica-)506 1238 y(tions)32 b(and)g(a)g(fair)f(n)n(um)n(b)r(er)h
+(of)g(hardw)n(are)e(platforms\),)i(new)g(faculties)g(and)g(depart-)506
+1338 y(men)n(ts)26 b(joining)f(the)h(Store-team)e(got)h(most)g(of)h
+(what)f(they)h(ev)n(er)e(needed)i(of)f(freew)n(are)506
+1438 y(and)e(third-part)n(y)e(applications.)g(Since)h(their)h(only)e
+(cost)h(w)n(as)f(the)i(price)f(of)g(extra)f(disk)506
+1537 y(space,)27 b(this)h(service)f(tended)h(to)f(b)r(ecome)h(v)n(ery)e
+(p)r(opular.)365 1643 y Fi(V)-8 b(ulnerabilit)m(y)g(.)45
+b Fn(After)24 b(ha)n(ving)e(used)i(Store)f(for)g(a)g(while,)g(w)n(e)h
+(ha)n(v)n(e)e(exp)r(erienced)h(higher)506 1743 y(vulnerabilit)n(y)34
+b(to)g(incorrect)f(installations.)h(W)-7 b(e)35 b(are)e(so)h(to)g(sp)r
+(eak)g(putting)h(all)f(the)506 1843 y(eggs)29 b(in)n(to)h(one)f(bask)n
+(et;)h(if)g(someone)f(in)n(tro)r(duces)g(a)h(fault)g(in)n(to)g(an)g
+(application)f(it)h(is)506 1942 y(spread)23 b(throughout)g(the)h(univ)n
+(ersit)n(y)f(within)h(the)g(next)g(da)n(y)-7 b(.)23 b(T)-7
+b(o)24 b(coun)n(ter)e(this,)i(m)n(uc)n(h)506 2042 y(w)n(ork)30
+b(has)h(b)r(een)g(put)h(in)n(to)e(authorization)g(and)h
+(con\014guration)e(mec)n(hanisms.)i(Also,)506 2141 y(Store)21
+b(mak)n(es)e(it)i(equally)f(easy)g(to)h(correct)e(faults)i(throughout)f
+(the)h(univ)n(ersit)n(y)f(within)506 2241 y(a)28 b(da)n(y)-7
+b(.)506 2347 y(A)34 b(metho)r(d)f(for)g(reducing)f(this)h(problem)g(is)
+g(to)g(ha)n(v)n(e)f(an)g(empiric)h(form)g(of)g(qualit)n(y)506
+2447 y(assurance:)j(No)g(automatic)h(up)r(dating)g(of)g(the)g(sla)n(v)n
+(e)e(stores,)h(and)h(only)f(man)n(ually)506 2546 y(initiated)29
+b(up)r(dating)e(of)h(sp)r(eci\014c)g(applications)e(on)i(the)g(sla)n(v)
+n(e)e(store)g(serv)n(ers.)365 2652 y Fi(Num)m(b)s(er)32
+b(of)f(arc)m(hitectures.)44 b Fn(During)25 b(the)i(\014rst)e(p)r(erio)r
+(d)h(of)g(Store,)g(w)n(e)f(exp)r(erienced)h(a)506 2752
+y(strong)g(trend)h(to)n(w)n(ards)f(standardization)f(on)i(a)f(small)h
+(n)n(um)n(b)r(er)g(of)g(OSes)f(supp)r(orted)506 2852
+y(b)n(y)k(Store.)g(Lately)-7 b(,)30 b(w)n(e)g(ha)n(v)n(e)f(exp)r
+(erienced)h(a)g(trend)g(the)h(other)e(w)n(a)n(y;)g(all)h(it)h(tak)n(es)
+e(is)506 2951 y(one)k(OS-bigot)f(willing)g(to)h(recompile)f(all)h
+(Store-applications)e(for)h(\\her")g(OS,)g(and)506 3051
+y(that)c(OS)g(is)g(supp)r(orted)f(throughout)g(the)h(univ)n(ersit)n(y)f
+(on)g(the)h(same)f(basis)g(as)g(ma)5 b(jor)506 3151 y(OSes.)365
+3257 y Fi(Consistency)-8 b(.)42 b Fn(Using)37 b(Store)g(as)g(a)g
+(framew)n(ork)f(for)h(installing)g(applications)g(ensures)506
+3356 y(that)i(one)f(application)f(is)h(installed)g(the)h(same)e(w)n(a)n
+(y)-7 b(,)37 b(indep)r(enden)n(t)i(of)f(hardw)n(are,)506
+3456 y(o)n(wnership,)22 b(and)g(disk-sharing)f(strategies.)g(Only)i
+(the)g(\014rst)f(p)r(erson)g(installing)g(a)g(new)506
+3555 y(application)34 b(decides)g(the)h(strategy)e(for)h(where)f(to)i
+(put)f(the)h(\014les.)f(Other)g(p)r(ersons,)506 3655
+y(recompiling)18 b(for)g(new)h(hardw)n(are)d(arc)n(hitectures)h(or)h
+(upgrading)f(v)n(ersions,)g(can)h(simply)506 3755 y(follo)n(w)23
+b(the)g(initial)g(setup.)h(This)f(often)g(implies)g(less)g(w)n(ork,)e
+(and)i(the)h(w)n(ork)d(remaining)506 3854 y(con)n(tains)27
+b(few)n(er)g(decisions.)365 3960 y Fi(Symlinks.)42 b
+Fn(Store)29 b(dep)r(ends)h(on)f(symlinks,)g(and)g(that)g(has)g(p)r
+(osed)g(some)f(problems,)h(al-)506 4060 y(though)c(not)g(as)f(man)n(y)g
+(as)h(feared)f(b)r(eforehand.)g(F)-7 b(or)25 b(instance,)f(the)i(maxim)
+n(um)e(n)n(um-)506 4160 y(b)r(er)32 b(of)g(links)g(allo)n(w)n(ed)f(b)n
+(y)g(Unix)h(\(normally)g(8,)f(although)g(some)h(OSes)f(ha)n(v)n(e)g
+(more\))506 4259 y(has)e(pro)n(v)n(en)e(to)r(o)h(small)h(in)g(some)f
+(circumstances.)g(When)h(using)f(the)h(automoun)n(ter,)506
+4359 y Fh(/store)f Fn(is)h(itself)i(a)e(symlink,)h(whic)n(h)f(increase)
+g(the)h(problem)f(quite)h(a)f(bit.)i(In)f(addi-)506 4458
+y(tion,)23 b(if)f(the)h(linktree)e(is)h(giv)n(en)g(a)f(partition)h(b)n
+(y)g(itself,)g(it)h(migh)n(t)f(require)f(an)g(increased)506
+4558 y(n)n(um)n(b)r(er)28 b(of)f(ino)r(des,)h(b)r(ecause)f(of)h(the)g
+(large)e(n)n(um)n(b)r(er)h(of)h(small)f(\014les.)365
+4664 y Fi(More)32 b(disk)g(usage.)41 b Fn(A)23 b(side)f(e\013ect)h(of)g
+(using)f(Store)g(is)h(an)f(increased)f(use)i(of)f(disk)h(space.)506
+4764 y(But)31 b(this)f(extra)e(cost)i(is)f(small)h(compared)e(to)i(the)
+g(p)r(erceiv)n(ed)f(reduction)h(of)g(system)506 4863
+y(administration)e(cost.)g(T)-7 b(o)28 b(compute)h(the)f(o)n(v)n
+(erhead)f(in)n(tro)r(duced)h(b)n(y)g(Store,)g(assume)p
+eop
+%%Page: 12 12
+12 11 bop 822 387 a Fn(a)24 b(system)g(consisting)g(of)g(2)h(master)e
+(stores)h(serving)f(4)h(sla)n(v)n(e)f(stores)g(eac)n(h,)h(four)g(arc)n
+(hi-)822 487 y(tectures,)e(10)g(linktrees)g(\(one)h(for)f(eac)n(h)g
+(serv)n(er\),)f(200)g(applications.)h(P)n(er)f(application,)822
+587 y(assume)32 b(3)g(arc)n(hitecture)f(dep)r(enden)n(t)i(\014les)f(of)
+h(an)f(a)n(v)n(erage)e(size)i(of)g(100)f(Kb)h(and)h(12)822
+686 y(arc)n(hitecture)d(indep)r(enden)n(t)j(\014les)f(of)f(an)h(a)n(v)n
+(erage)d(size)i(of)h(20)f(Kb.)g(The)h(extra)f(o)n(v)n(er-)822
+786 y(head)d(in)g(the)h(linktrees)e(is)h(10)f(serv)n(ers)f
+Fb(\002)i Fn(14)f(symlinks)h Fb(\002)g Fn(200)e(applications,)i(giving)
+822 886 y(24,000)18 b(symlinks.)i(If)g(eac)n(h)g(symlink)g(o)r(ccupies)
+g(512)e(b)n(ytes,)i(this)h(means)e(a)h(system)n(wide)822
+985 y(o)n(v)n(erhead)26 b(of)i(12)g(Mb)h(plus)f(some)g(extra,)f
+(minimal)i(space)f(for)f(directories.)g(The)i(\014les)822
+1085 y(in)35 b(a)g Fh(/usr/local)c Fn(tree)k(w)n(ould)g(b)r(e)g(10)f
+(serv)n(ers)f Fb(\002)i Fn(200)f(applications)g Fb(\002)h
+Fn([for)g(eac)n(h)822 1184 y(application)d(12)h(\014les)g(of)g(20)f(Kb)
+h(and)g(3)g(\014les)g(of)g(100)f(Kb],)h(resulting)g(in)g(a)g(total)g
+(of)822 1284 y(1080)28 b(Mb.)j(The)g(extra)e(\014les)h(in)h(Store)f
+(whic)n(h)g(are)g(not)g(directly)g(used)g(are)g(2)g(serv)n(ers)822
+1384 y Fb(\002)j Fn(200)g(applications)f Fb(\002)i Fn(3)f(v)-5
+b(arian)n(ts)32 b Fb(\002)i Fn(3)f(\014les)g Fb(\002)h
+Fn(100)e(Kb,)i(giving)e(360)h(Mb.)h(This)822 1483 y(means)27
+b(a)g(33\045)g(disk-space)f(o)n(v)n(erhead)g(for)h(this)h
+(con\014guration.)681 1594 y Fi(Con)m(tin)m(ued)33 b(main)m(tenance.)42
+b Fn(Con)n(tin)n(ued)d(main)n(tenance)g(is)g(imp)r(ortan)n(t.)g(W)-7
+b(e)40 b(receiv)n(e)822 1693 y(a)35 b(daily)h(mail,)f(rep)r(orting)g
+(the)h(status)g(of)f(the)h(Store)g(installation.)f(The)h(output)g(is)
+822 1793 y(adjustable.)27 b(The)g(rep)r(orts)f(ma)n(y)h(also)f(b)r(e)h
+(cen)n(tralized)g(if)g(one)g(supp)r(ort)g(sta\013)g(handles)822
+1893 y(m)n(ultiple)h(Store)f(installations.)681 2003
+y Fi(Reduced)k(Installation)j(time.)41 b Fn(When)22 b(a)f(new)g
+(computer)g(lab)g(with)h(10)e(mac)n(hines)h(w)n(as)822
+2103 y(installed,)34 b(it)g(to)r(ok)f(only)g(20)g(min)n(utes)h(to)g
+(link)g(up)g(all)f(applications)g(in)h(Store)f(that)822
+2202 y(supp)r(orted)24 b(the)h(giv)n(en)f(arc)n(hitecture.)f(This)h(is)
+h(v)n(ery)e(fast,)i(compared)e(with)i(the)g(alter-)822
+2302 y(nativ)n(e)i(situation:)g(recompilation)g(of)g(all)h(those)f
+(applications.)681 2413 y Fi(The)32 b(\014nal)h(decision)f(is)g(made)g
+(lo)s(cally)-8 b(.)43 b Fn(It)27 b(is)f(p)r(ossible)g(to)g
+Fe(fr)l(e)l(eze)h Fn(a)f(replica,)f(inhibit-)822 2512
+y(ing)32 b(further)g(automatic)g(up)r(dates)g(for)g(applications)f
+(considered)h(critically)f(imp)r(or-)822 2612 y(tan)n(t.)d(If)g(a)f
+(departmen)n(t)g(w)n(an)n(ts)g(to)h(use)f(a)h(sp)r(eci\014c)f(v)n
+(ersion)f(of)i(an)f(application,)h(they)822 2712 y(are)i(free)i(to)f
+(do)g(so.)g(They)h(can)f(ev)n(en)g(set)g(up)h(their)f(o)n(wn)g(master)g
+(for)g(that)h(applica-)822 2811 y(tion.)19 b(The)h Fh(/usr/local/bin)13
+b Fn(directory)18 b(can)h(b)r(e)h(placed)f(in)h(the)f(P)-7
+b(A)g(TH)20 b(en)n(vironmen)n(t)822 2911 y(v)-5 b(ariable)21
+b(b)r(efore)h Fh(/store/bin)p Fn(,)d(in)k(order)e(to)h(let)h(lo)r
+(cally)f(installed)g(applications)f(tak)n(e)822 3010
+y(precedence)27 b(o)n(v)n(er)f(Store-applications.)681
+3121 y Fi(Better)32 b(in)m(terdepartmen)m(tal)i(co)s(op)s(eration.)41
+b Fn(Departmen)n(ts)f(using)f(Store)h(are)f(im-)822 3221
+y(plicitly)e(encouraged)d(to)i(co)r(op)r(erate.)g(This)g(has)g
+(resulted)g(in)g(p)r(ositiv)n(e)g(side-e\013ects)822
+3320 y(at)e(this)h(univ)n(ersit)n(y:)f(a\))g(univ)n(ersit)n(y-wide)g
+(do)r(cumen)n(tation,)g(b\))h(sharing)e(of)i(h)n(uman)822
+3420 y(resources,)26 b(and)h(c\))h(the)g(qualit)n(y)f(p)r(er)g
+(application)g(is)h(maximized.)681 3530 y Fi(Less)j(duplication)j(of)e
+(w)m(ork.)42 b Fn(Store)29 b(has)g(resulted)h(in)g(a)g(reduced)f(w)n
+(orkload,)f(mainly)822 3630 y(due)g(to)f(less)g(duplication)h(of)f(w)n
+(ork)g(b)r(ecause)g(of)g(in)n(terdepartmen)n(tal)g(co)r(op)r(eration.)
+681 3740 y Fi(File)32 b(name)g(space)g(mangling.)42 b
+Fn(The)d(tec)n(hnique)g(of)g(mangling)f(the)i(attributes)f(in)n(to)822
+3840 y(the)28 b(\014le)f(system)g(name)h(space)e(ha)n(v)n(e)h(pro)n(v)n
+(ed)e(su\016cien)n(tly)j(strong.)e(In)i(addition,)f(it)h(is)822
+3940 y(simple,)e(p)r(ortable,)g(and)g(the)h(limit)g(of)f(255)f(c)n
+(haracters)e(in)k(\014le)f(names)g(do)r(es)g(not)g(p)r(ose)822
+4039 y(a)g(problem.)h(It)g(is)g(ev)n(en)g(preceden)n(ted,)f(as)g
+(compilers)g(use)h(the)h(\\\014le)e(t)n(yp)r(e")h(to)g(decide)822
+4139 y(the)h(t)n(yp)r(e)g(of)f(con)n(ten)n(ts)g(of)h(a)f(\014le.)681
+4250 y Fi(Name)k(space)h(dimensions.)41 b Fn(Store)35
+b(only)h(uses)f(t)n(w)n(o)g(dimensions:)h(arc)n(hitecture)f(and)822
+4349 y(domain.)24 b(Ho)n(w)n(ev)n(er,)e(w)n(e)i(en)n(vision)g(at)g
+(least)g(\014v)n(e)g(suc)n(h)g(dimensions:)g(hardw)n(are,)f(op)r(er-)
+822 4449 y(ating)e(system,)h(geographic)e(lo)r(cation,)h
+(organizational)f(a\016liation,)h(and)h(release)f(t)n(yp)r(e)822
+4548 y(\(alpha,)28 b(b)r(eta,)g(etc\).)h(Store)e(uses)h(one)f
+(dimension)h(\(arc)n(hitecture\))g(for)f(the)i(t)n(w)n(o)e(\014rst;)822
+4648 y(and)i(another)f(\(domain\))i(the)g(the)f(t)n(w)n(o)g(next.)h
+(The)f(last)g(dimension)g(is)g(put)h(in)n(to)f(the)822
+4748 y(con\014guration)21 b(\014le)i(for)g(the)g(application,)f(as)g
+(all)h(\014les)g(of)g(a)f(v)n(ersion)g(in)h(an)f(application)822
+4847 y(are)27 b(considered)f(to)i(b)r(e)g(of)f(the)h(same)f(release)f
+(t)n(yp)r(e.)p eop
+%%Page: 13 13
+13 12 bop 365 387 a Fj(10)112 b(F)-9 b(urther)38 b(Dev)m(elopmen)m(ts)
+365 629 y Fn(P)n(ossible)26 b(future)i(dev)n(elopmen)n(ts)f(include:)
+365 828 y Fi(Alternativ)m(e)35 b(transp)s(ort)d(mec)m(hanisms.)41
+b Fn(Curren)n(tly)-7 b(,)33 b(NFS)h(is)f(the)h(only)f(supp)r(orted)506
+928 y(transp)r(ort)f(mec)n(hanism.)h(In)g(the)g(future,)g(supp)r(ort)g
+(for)f(other)h(mec)n(hanisms)f(will)h(b)r(e)506 1027
+y(included:)k(ftp,)f(the)g(alex)f(\014le)h(system,)f(w)n(orld)f(wide)i
+(w)n(eb,)f(etc.)h(Also,)f(supp)r(ort)h(for)506 1127 y(transp)r(ort)27
+b(to)h(other)f(systems)g(than)g(Store)g(will)h(b)r(e)g(implemen)n(ted.)
+365 1235 y Fi(Non-Unix)33 b(platforms.)41 b Fn(Some)k(initial)g(exp)r
+(erimen)n(ts)g(ha)n(v)n(e)e(b)r(een)i(p)r(erformed)g(with)506
+1335 y(PCs)27 b(under)f(DOS,)i(using)e(PC-NFS)h(as)f(the)i(transp)r
+(ort)e(mec)n(hanism.)g(PC-NFS)h(han-)506 1434 y(dles)36
+b(symlinks,)f(and)g(tec)n(hnically)f(it)i(w)n(ork)n(ed)e(fairly)g(w)n
+(ell.)h(Ho)n(w)n(ev)n(er,)f(some)g(ma)5 b(jor)506 1534
+y(conceptual)26 b(problems)g(turned)g(up:)h(most)f(freew)n(are)f
+(applications)h(are)f(either)h(Unix-)506 1633 y(only)d(or)f(DOS-only)-7
+b(.)23 b(Th)n(us,)g(the)g(adv)-5 b(an)n(tage)22 b(of)h(main)n(taining)f
+(a)h(m)n(ulti-platform)g(con-)506 1733 y(\014guration)k(of)g(pac)n(k)-5
+b(ages)26 b(disapp)r(ears.)506 1841 y(Another)31 b(problem)f(is)h(that)
+g(site-sp)r(eci\014c-con\014guration)d(and)j(user-sp)r
+(eci\014c-con\014g-)506 1941 y(uration)d(are)g(often)g(mixed)h
+(together)f(in)g(the)h(same)f(con\014guration)f(\014le)i(under)f(DOS;)
+506 2040 y(under)g(Unix)g(these)f(are)g(generally)f(more)h(separated.)
+506 2148 y(F)-7 b(urthermore,)28 b(under)f(DOS)i(and)f(Windo)n(ws,)g
+(programs)d(p)r(erforming)j(certain)f(tasks)506 2248
+y(during)37 b(program)e(installation)h(that)h(Unix)g(t)n(ypically)g(p)r
+(erforms)f(during)g(program)506 2348 y(startup,)41 b(e.g.)24
+b(mail)40 b(programs)f(under)h(DOS)h(t)n(ypically)e(set)i(the)g(user)e
+(name)i(dur-)506 2447 y(ing)30 b(installation,)f(while)g(under)h(Unix)g
+(the)g(programs)d(read)i(the)g(user)g(name)h(during)506
+2547 y(startup.)g(Th)n(us,)h(DOS-applications)e(are)g(often)i
+(single-user)d(applications)i(that)g(are)506 2646 y(di\016cult)f(to)e
+(incorp)r(orate)f(in)n(to)i(a)f(system)g(lik)n(e)g(Store.)365
+2755 y Fi(Automatic)33 b(do)s(cumen)m(tation)g(for)f(the)f(end-user.)41
+b Fn(W)-7 b(e)31 b(ha)n(v)n(e)e(plans)h(for)g(a)g(WWW)506
+2854 y(gatew)n(a)n(y)38 b(to)h(semi-automatically)f(generated)h(h)n(yp)
+r(ertext)g(do)r(cumen)n(tation)g(ab)r(out)506 2954 y(the)30
+b(applications)e(in)h(Store,)f(where)h(the)g(user)f(can)h(na)n(vigate)e
+(b)r(et)n(w)n(een)i(information)506 3053 y(ab)r(out)k(applications,)f
+(the)g(p)r(ersons)g(that)h(installed)f(those)g(applications,)g(the)h
+(cate-)506 3153 y(gory)g(of)g(an)h(application)f(\(e.g.)g(image)g(pro)r
+(cessing,)f(games\),)h(the)i(licensing)e(condi-)506 3253
+y(tions,)27 b(the)h(man)n(ual)e(pages,)h(info)g(pages,)f(examples,)h
+(release)e(notes,)i(lo)r(cal)g(di\013s,)g(and)506 3352
+y(so)h(on.)g(Added)h(to)f(this,)g(some)g(searc)n(h)e(forms)i(should)g
+(also)f(b)r(e)h(presen)n(t,)g(so)f(that)i(the)506 3452
+y(end)20 b(user)g(can)f(easily)g(\014nd)h(the)g(program)e(needed)i(giv)
+n(en)f(some)g(k)n(eyw)n(ords)f(ab)r(out)h(what)506 3552
+y(the)k(user)e(w)n(an)n(ts)h(to)g(do.)g(This)g(w)n(ould)f(giv)n(e)h
+(one)f(W)-7 b(eb)23 b(\\home-page")d(p)r(er)i(application,)506
+3651 y(through)27 b(whic)n(h)h(all)f(information)g(ab)r(out)h(the)g
+(system)f(is)g(accessible.)365 3759 y Fi(Impro)m(v)m(ed)33
+b(feedbac)m(k.)42 b Fn(F)-7 b(eedbac)n(k)40 b(information)g(should)g
+(go)f(directly)h(b)n(y)g(electronic)506 3859 y(mail)26
+b(to)f(the)h(p)r(erson)f(that)h(installed)f(an)h(application,)f(not)g
+(just)h(to)g(a)f(supp)r(ort)g(team.)365 3967 y Fi(Av)-5
+b(ailabilit)m(y)37 b(monitor.)k Fn(NFS,)30 b(although)f(stateless,)g
+(is)g(v)n(ery)g(vulnerable)f(to)i(a)f(situa-)506 4066
+y(tion)g(where)f(the)h(serv)n(er)e(for)h(a)g(moun)n(ted)h(\014le)g
+(system)f(b)r(ecomes)g(una)n(v)-5 b(ailable.)28 b(If)h(the)506
+4166 y(serv)n(er)e(do)r(es)h(not)h(come)f(up)h(again,)e(programs)g
+(accessing)g(those)h(moun)n(t)h(p)r(oin)n(ts)f(will)506
+4266 y(hang,)h(causing)g(the)h(clien)n(t)g(mac)n(hine)f(to)g(b)r(ecome)
+h(rather)e(un)n(usable.)h(Neither)h(Sun's)506 4365 y(\\automoun)n(ter")
+h(nor)g(\\amd")h(pro)n(vide)f(the)i(needed)f(functionalit)n(y)h(to)f
+(switc)n(h)g(to)h(a)506 4465 y(di\013eren)n(t)c(serv)n(er)d
+(on-the-\015y)-7 b(.)27 b(By)h(ha)n(ving)f(iden)n(tical)h(stores)f
+(with)h(application)g(repli-)506 4565 y(cas)e(only)-7
+b(,)26 b(and)g(an)h(extra)e(lev)n(el)h(of)g(indirection,)h(one)f(can)g
+(switc)n(h)g(to)g(a)g(serv)n(er)f(that)h(is)506 4664
+y(a)n(v)-5 b(ailable)27 b(when)i(the)f(previous)f(one)h(b)r(ecomes)f
+(una)n(v)-5 b(ailable.)27 b(Note)i(that)f(this)g(is)g(also)506
+4764 y(p)r(ossible)f(with)g(the)h(traditional)e(approac)n(h,)f(just)i
+(let)g Fh(/usr/local)c Fn(b)r(e)k(a)g(symlink)f(to)506
+4863 y(e.g.)f Fh(/usr/locals/)p Fe(machine)p Fn(.)p eop
+%%Page: 14 14
+14 13 bop 681 387 a Fi(Virtual)34 b(stores.)40 b Fn(Curren)n(tly)-7
+b(,)34 b(stores)f(are)g(lo)r(cated)h(b)r(elo)n(w)g Fh(/store/store)p
+Fn(.)c(Ho)n(w)n(ev)n(er,)822 487 y(b)n(y)i(adding)g(an)g(extra)g(lev)n
+(el)g(of)g(indirection,)g(the)h(lev)n(el)f(sp)r(ecifying)g(the)h(lo)r
+(cation)f(of)822 587 y(the)i(store)f(can)g(b)r(e)h(remo)n(v)n(ed.)f(If)
+h Fh(/store/store/idt)27 b Fn(is)34 b(a)f(virtual)g(store,)g(then)h(it)
+822 686 y(can)c(dynamically)g(b)r(e)g(replaced)g(b)n(y)g(an)n(y)f(of)i
+(a)f(set)g(of)g(iden)n(tical)h(stores.)e(T)-7 b(o)30
+b(b)r(ecome)822 786 y(e\013ectiv)n(e,)25 b(this)g(feature)g(needs)g
+(the)h(a)n(v)-5 b(ailabilit)n(y)23 b(monitor.)i(Ho)n(w)n(ev)n(er,)e
+(for)i(t)n(w)n(o)f(stores)822 886 y(to)j(b)r(e)h(iden)n(tical,)g(they)g
+(cannot)f(b)r(e)h(master)f(stores)f(for)h(an)n(y)g(application.)681
+985 y Fi(Con\015ict)32 b(handling.)43 b Fn(When)c(con\015icts)f(b)r(et)
+n(w)n(een)g(applications)f(o)r(ccur,)h(they)g(can)g(b)r(e)822
+1085 y(resolv)n(ed,)32 b(based)h(up)r(on)h(metrics)g(describing)f(the)h
+(imp)r(ortance)f(of)h(the)g(application)822 1184 y(and)29
+b(the)h(source)e(of)h(an)h(application)e(\(i.e.)e(whic)n(h)j(master)f
+(store,)h(who)g(installed)g(the)822 1284 y(application\).)681
+1553 y Fj(11)112 b(More)38 b(Information)681 1752 y Fn(More)20
+b(information)g(ab)r(out)g(the)i(Store)e(system)g(can)h(b)r(e)g(found)g
+(at)g(the)g(anon)n(ymous)e(ftp)j(site)681 1852 y(ftp.p)n(vv.unit.no,)35
+b(in)g(the)g(directory)e(\\/pub/store",)f(and)i(through)g(W)-7
+b(orld)34 b(Wide)h(W)-7 b(eb)681 1952 y(from)27 b(h)n(ttp://www.p)n
+(vv.unit.no/~arnej/store/storedo)r(c.h)n(tml.)681 2221
+y Fj(12)112 b(Conclusion)681 2420 y Fn(W)-7 b(e)33 b(think)g(that)g
+(Store)f(pro)n(vides)f(a)h(suitable)g(en)n(vironmen)n(t)g(for)g
+(installing)g(third-part)n(y)681 2519 y(applications,)26
+b(and)h(eases)f(the)h(the)h(daily)f(tasks)f(of)h(the)h(computer)e
+(systems)h(administra-)681 2619 y(tion)34 b(sta\013s.)f(The)h(main)g
+(e\013ects)g(are)f(b)r(etter)h(o)n(v)n(erview;)e(the)i(automation)f(of)
+h(rep)r(etitiv)n(e)681 2719 y(and)23 b(trivial)f(tasks;)g(ensured)g
+(consistency;)h(the)g(considering)e(of)i(man)n(y)g(computers)f(as)g
+(one)681 2818 y(system.)805 2918 y(W)-7 b(e)22 b(ha)n(v)n(e)e(got)g(p)r
+(ositiv)n(e)h(exp)r(eriences)f(from)h(installing)g(Store)g(at)g(v)-5
+b(arious)20 b(installations)681 3018 y(at)f(the)h(Univ)n(ersit)n(y)f
+(of)h(T)-7 b(rondheim,)19 b(where)g(curren)n(tly)-7 b(,)19
+b(around)g(half)g(the)h(Unix-computers)681 3117 y(use)25
+b(Store.)f(The)i(feedbac)n(k)e(from)h(users)f(ha)n(v)n(e)g(b)r(een)i
+(generally)d(pleasan)n(t,)h(although)h(most)681 3217
+y(users)34 b(are)h(not)g(a)n(w)n(are)e(of)i(Store,)g(ev)n(en)g(though)g
+(most)g(of)h(their)f(to)r(ols)g(are)f(installed)h(in)681
+3316 y(Store.)681 3585 y Fj(References)681 3776 y Fl(1.)42
+b(Stephen)29 b(N.)c(Clark)32 b(Kenneth)23 b(Manheimer,)31
+b(Barry)g(A.)f(W)-6 b(arsa)n(w)32 b(and)e(W)-6 b(alter)31
+b(Ro)n(w)n(e.)49 b(The)782 3868 y(dep)r(ot:)23 b(A)f(framew)n(ork)h
+(for)g(sharing)h(soft)n(w)n(are)g(installation)h(across)f
+(organizational)h(and)d(unix)782 3959 y(platform)h(b)r(oundaries.)33
+b(Pro)r(ceedings)24 b(of)g(the)e(F)-6 b(ourth)21 b(Large)j
+(Installation)g(Systems)d(Admin-)782 4050 y(istration)27
+b(IV.)33 b(Colorado)28 b(Springs,)e(Colorado,)i(Octob)r(er)e(1990.)681
+4142 y(2.)42 b(Thomas)25 b(A.)40 b(Lundgren.)78 b(A)40
+b(\014le)h(serv)n(er)f(directory)h(tree)f(hierac)n(h)n(y)-6
+b(.)78 b(T)-6 b(ec)n(hnical)41 b(Rep)r(ort)782 4233 y
+(ETX/TX/DD-91:110,)28 b(Ericsson)f(T)-6 b(elecom,)26
+b(Jan)n(uary)g(1992.)681 4324 y(3.)42 b(S.)25 b(Bouc)n(her,)j(M.)e
+(Dagenais,)k(R.)24 b(G)n(\023)-36 b(erin-La)t(joie,)31
+b(P)-6 b(.)25 b(Laplan)n(te,)j(and)g(P)-6 b(.)25 b(Mailhot.)42
+b(LUDE:)28 b(A)782 4416 y(Distributed)d(Soft)n(w)n(are)i(Library)-6
+b(.)34 b(Univ)n(ersit)n(y)25 b(of)h(Mon)n(treal,)h(June)f(1993.)681
+4507 y(4.)42 b(Melvin)22 b(J.)k(Pleasan)n(t)g(Jr.)d(and)e(Eliot)26
+b(Lear.)34 b(T)-6 b(ranscending)22 b(administrativ)n(e)g(domains)f(b)n
+(y)g(au-)782 4598 y(tomating)e(system)g(managemen)n(t)f(tasks)i(in)f(a)
+h(large)h(heterogeneous)f(en)n(vironmen)n(t.)30 b(USENIX)782
+4690 y(W)-6 b(orkshop)25 b(Pro)r(ceedings.)36 b(New)26
+b(Orleans,)g(Louisiana,)i(April)d(1989.)681 4847 y(This)h(article)h(w)n
+(as)g(pro)r(cessed)f(using)g(the)f(L)1936 4830 y Fa(A)1969
+4847 y Fl(T)2011 4863 y(E)2055 4847 y(X)g(macro)h(pac)n(k)l(age)g(with)
+g(LLNCS)f(st)n(yle)p eop
+%%Trailer
+end
+userdict /end-hook known{end-hook}if
+%%EOF
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Referat, møte i TD's driftsgruppe, Torsdag 9. Februar 1995</TITLE>
+<LINK REV="made" HREF="mailto:runeb@stud.cs.uit.no">
+</HEAD>
+<BODY>
+<H1>Referat, møte i TD's driftsgruppe,
+<BR>9. Februar 1995</H1>
+
+Tilstede: Rune Braathen, Petter Reinholdtsen, Frode Fjeld, Per Harald Myrvang, Hans
+Ole Rafaelsen, mm
+
+<P>Fordeling av arbeidsoppgaver for semesteret, pr. maskin:
+
+<P><table border>
+<th>hostname <th>maskintype <th>Ansvarlig
+<tr><td> <td>PS/2 <td>- Frode
+<tr><td>spurv <td>SPARC <td>- Hans Ole
+<tr><td>dc9 * <td>MicroVAX <td>- Michael
+<tr><td> <td>HP3000 <td>- Per
+<tr><td>minerva <td>386 <td>- Petter
+</table>
+* dc9 er pr. nå ikke operativ
+
+
+<H2>Prioriterte oppgaver:</H2>
+
+<OL>
+<LI>Nameserver for domain td.org.uit.no på spurv
+<LI>eksportering av filsystemet v.h.a. STORE
+<LI>IBM4019 printer i drift
+<LI>w3-server på spurv
+</OL>
+
+
+<H2>Andre oppgaver:</H2>
+
+<P>Rune renskriver og sender Benchmark-resultater for maskiner
+tilhørende Nordix data og Cinet til de respektive.
+
+<P>Frode undersøker muligheter for konfigurert versjon av Doom for
+spilling på videokanon under UKA-95.
+
+<P>Petter undersøker muligheter for større lokaler, samt spørsmål
+rettet til EDB-utvalget angående Ether-kabel til TD-laben.
+
+<HR>
+<ADDRESS><A HREF="mailto:runeb@stud.cs.uit.no">Rune Braathen</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Referat, TD's driftsmøte, Torsdag 30, Mars.</TITLE>
+<LINK REV="made" HREF="mailto:runeb@stud.cs.uit.no">
+</HEAD>
+<BODY>
+<H1>Referat, møte i TD's driftsgruppe,
+<BR> Torsdag 30, Mars. 1995</H1>
+
+Tilstede: Rune Braathen, Hans Ole Rafaelsen, Per Harald Myrvang, mm.
+
+<H2>1. Status for labben/maskinene (Hva er gjort siden sist)</H2>
+
+De driftsansvarlige for spurv avventer ankomst av Solaris 2.4 for å
+enklere installere en fungerende nameserver. Med operativ nameserver,
+vil det være mulig for TD å tilby medlemmer <STRONG>uten</STRONG> nettaccess mail,
+news og UNIX shell-konto. Dette vil åpne for nye medlemmer utenfor
+SfI, og vil føre til en betraktelig økning i medlems-massen, og
+derfor også TD's økonomi.
+
+<H2>2. Utlevering av brukerlista til Informatikk/TK</H2>
+
+Forespørsel fra TK's leder Ørjan Robertsen, om jevnlig rapport over
+hvem som til enhver tid anvender TD's maskiner ble diskutert. Saken
+ble imidlertid ikke avgjort, pga. av at Robertsens begrunnelse for
+hvorfor han ønsket disse opplysningene ikke var tilgjengelige for møtet.
+
+
+<H2>3. Eventuelt</H2>
+
+Rune Braathen vil forespørre Studieadministrasjonen ved fagområdet
+Medisin om å donere noen utrangerte gamle 286-maskiner til TD's
+maskinpark.
+
+<HR>
+<ADDRESS><A HREF="mailto:runeb@stud.cs.uit.no">Rune Braathen</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<!-- Changed by: Petter Reinholdtsen, 23-Oct-1996 -->
+<LINK REV="made" HREF="mailto:pere@td.org.uit.no">
+<BASE HREF="http://www.td.org.uit.no/">
+
+</HEAD>
+<BODY>
+Petter Reinholdtsen
+<BR>1996-10-23
+<HR>
+<H1>Om TD og andre foreninger</H1>
+
+Andre foreninger bør generelt sett få mulighet til å ha sine websider
+på TDs server når det ikke eksisterer andre muligheter. Den eneste
+forutsetningen er at et medlem i TD har sagt seg villig til å vedlike
+holde sidene. Den aktuelle foreningen bør først vurdere om
+EDB-senterets tilbud kan benyttes. Kontakt Webmaster på EDB-senteret
+for å finne ut av dette.
+
+<P>Hvis foreningen ønsker dette, så kan de få en URL på rot-nivå, slik
+<A HREF="/studentsamfunnet/">Studentsamfunnet</A> og
+<A HREF="/hoyre/">Hoyre</A> har fått det.
+
+<P>I tvilstilfeller avgjør TD-drift hva som skal gjøres. Foreningene
+har klagerett til TD-styret som endelig avgjør saken.
+
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:pere@td.org.uit.no">pere@td.org.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<html>
+<body>
+
+
+<title>TDs Bruker-skjema,</title>
+
+<hr>
+
+<IMG align="left" SRC="/~tdadm/bilder/logo.gif">
+
+TD's driftsgruppe tilbyr internet-tilgang til alle medlemmer av
+TD.. Terminalene befinner seg på rom A-0602, innenfor bomberommet i
+kjelleren på IMR. Brukerne av TDs maskinpark må fylle ut følgende
+skjema for å få tilgang til nettet. Bruken av maskinparken er
+underlagt Universitetet i Tromsøs retningslinjer for bruk av
+universitetets edb-anlegg. Kontakt "TD-drift
+<td-drift@cs.uit.no>" hvis du har spørsmål.
+
+<br clear=all>
+<hr>
+<H1>Brukerkontrakt</H3>
+<h2>Brukeropplysninger</h2>
+<ul>
+<TABLE>
+<TR><TH>Fornavn<TD>
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<TR><TH>Etternavn<TD>
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<TR><TH>Telefon<TD>
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<TR><TH>Brukernavn<TD>
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+</TABLE>
+
+<b>NB!</b> Brukernavn skal ideelt bestå av brukerens fornavn + første
+bokstav av etternavnet.Eks: Svenn Høgda = <tt>svennh</tt>, Ali Baba =
+<tt>alib</tt>. Kuriose brukernanvn som <tt>sohot4u</tt>,
+<tt>fantomet</tt> o.l. er ikke tillatt. Brukernavnet kan bli
+annerledes pga. navnekollisjoner.
+
+<p>
+</ul>
+<hr>
+<h2>Oppsett</h2>
+<ul>
+<TABLE>
+<TR><TH>Email-addresse<TD>
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+<IMG WIDTH=21 HEIGHT=25 SRC="letter2.gif">
+</TABLE>
+
+Hvis du vil at elektronisk post til din bruker skal videresendes til
+en annen addresse, fyll den inn her. Hvis ikke, kan du la feltet stå
+åpent. <p> </h4> <p> </ul>
+
+<hr>
+<UL>
+Undertegnede bekrefter herved å ha lest gjennom og forstått gjeldende
+retningslinjer for bruk av universitetets edb-anlegg, og er
+inneforstått med det ansvar som bruk av utstyret medfører.
+</UL>
+<BR><BR>
+<HR align=left width=50%>
+Sted, dato og signatur
+
+</body>
+</html>
+
--- /dev/null
+
+
+Flyreise 2xOslo-Tromsø T/R 5600,-
+Hotell 2x1 natt 1000,-
+Hybel, 4 dager 600,-
+Div. bevertning debatt. 600,-
+
+Div. bevertning arr. 1400,-
+PR-materiell 500,-
+Transport 400,-
+Støtte DND (1 reise og opphold) 4000,-
+Støtte IMR ) 2000,-
+Støtte EDB-senteret 3000,-
+Støtte Trygg Data 500,-
+--------------------------------------------------
+ 9100,- 9500,-
+
+<H2>Penger</H2>
+
+Har søkt penger hos:
+
+Seksjon for Informatikk 2000,- *
+IMR 2000,- *
+IRV 3000,- *
+EDB-Senteret 2000,- *
+
+UniReiser AS 776 73422 (Reise) *
+
+CINET 776 10099 3000,- -
+Comma 776 80874 3000,-
+Datavarehuset 776 75754 3000,-
+EDB Kunnskap AS 776 11755 3000,-
+HøyskoleData 776 82252 3000,-
+ICL Service AS 776 74210 3000,-
+Polar Data 776 86020 3000,-
+Kabel Connection 776 31578 3000,- *
+KSEdb 776 74078 3000,-
+MikroSys 776 15055 3000,-
+Sikker Data ANS 776 89800 3000,-
+Trygg Data 776 74044 3000,-
+NIT 776 21800 3000,-
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Debatt om nett og juss</TITLE>
+<LINK REV="made" HREF="mailto:petterr@cs.uit.no">
+</HEAD>
+<BODY>
+
+<H1>Debatt: Elekronisk informasjonsformidlings forhold i Norge</H1>
+Tid: Tirsdag 25. april kl. 18:15
+<BR>Sted: Store Auditorium, IMR/UiTø
+
+<P>Vi forsøker å få debatten sendt ut over MBONE.
+
+<H2>Tema</H2>
+<BLOCKQUOTE>
+Hvilke forhold skal elektroniske oppslagstavler og elektronisk
+formidling av informasjon ha i Norge.
+
+<P>Hvilke konsekvenser vil eventuell innføring av redaktøransvar for
+formidling av elektroniske konferansesystem få.
+
+<P>Hva innebærer en eventuell konsesjonsordning for videreformidling
+av nett-tjenester for ytringsfriheten og den nasjonale infrastrukturen
+på dette området.
+</BLOCKQUOTE>
+<H2>Paneldeltagere</H2>
+<DL>
+<DT>Gisle Hannemyr
+<DD>Oslonett A/S / <A HREF="http://www.oslonett.no/home/efn/">Elektronisk Forpost Norge</A>s Råd
+<DT>Stein A. J. Møllerhaug
+<DD>DND/Skrivervik Data
+<DT>Ande Somby
+<DD>stipendiat ved Institutt for Rettsvitenskap
+</UL>
+
+<H2>Innleder</H2>
+<UL>
+<LI>Tage Stabell-Kulø
+</UL>
+
+<H2>Ordstyrer</H2>
+<UL>
+<LI>Terje Fallmyr
+</UL>
+
+Dette er et samarbeidsarangement med Den Norske Dataforening/Tromsø
+
+<P>Stein A. J. Møllerhaug lanserte ideen om konsesjonsordning for
+elektroniske oppslagstavler i rapperten
+<A HREF="/~petterr/reports/oppslagstavler.regl.html">"Nytt Media Med
+Nye Muligheter: Elektroniske Oppslagstavler"</A> resultatet fra et
+prosjekt i Den Norske Dataforening.
+
+<HR>
+<ADDRESS>Petter Reinholdtsen - petterr@stud.cs.uit.no</ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<LINK REV="made" HREF="mailto:petterr@cs.uit.no">
+</HEAD>
+<BODY>
+<H1>Gjester ved TDs jubileumsuke</H1>
+
+
+<UL>
+<LI>Stig S. Bakken <ssb@pvv.unit.no>
+ <BR>Programvareverkstedet, Universitetet i Trondheim
+ <BR>Kommer 24. april, trenger overnatting
+</UL>
+<HR>
+<ADDRESS>Petter Reinholdtsen - petterr@stud.cs.uit.no</ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+En del ting som må gjøres før TD jubilerer:
+
+- Kontakt hotell, skaff priser [Vegar]
+- Organiser kaffe til debatt [Vegar]
+
+- Kontakt UniReiser, skaff flypriser og sponsing? [Petter]
+- Søk om penger [Frode/Petter]
+- Sett opp budsjett og presenter det for DND [Petter]
+- Send program til DND [Petter]
+- Få kontakt med Hannemyr/Møllehaug [Petter]
+- Skaff ordstyrer / innleder til debatten [Petter]
+
+- Kontakt Stig Johansen og hør om han er interessert i å forelese [Espen]
+- Organiser kaffe til foredrag [Espen]
+
+- Annonser/PR (edb-kons/plakater/div.) [??]
+- Lage en aktivitetsplan for de 3-4 stykkene som kommer fra sør. [??]
+- Skaff overnatting for 2-3 personer [??]
+- Organiser stereo og drikke til Klassisk forum [?]
+
+Alle må sende mail når de kommer tilbake fra påskeferie.
\ No newline at end of file
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+<H1>Tromsøstudentenes Dataforening fyller 10 år</H1>
+
+<H2>Oppsummering</H2>
+
+<DL>
+<DT>Otto Anshus/SfI - Multimaskiner/distribuerte systemer
+<DD>Rundt 15 stykker var møtt opp til en presentasjon av bakgrunnen
+for seksjonens prosjekt DOPS - Distribuerte og Parallelle System
+
+<DT>Debatt om elekronisk informasjonsformidlings forhold i Norge
+<DD>Nesten 60 stykker deltok på debatten der motsetningene ikke ble så
+store, mens informasjonsverdien var desto høyere. Undertegnede fikk i
+allefall en del ny innsikt i temaet.
+
+<DT>Stig Sæter Bakken/PVV - STORE & Rune Braathen/TD - SATAN
+
+<DD>I overkant av 20 stykker var møtt opp for å få tips om drift av
+UNIX-maskiner.
+
+STORE ble presentert som løsningen på drift av mange skapt av
+frustrasjoner i drift av et heterogent system og mange programpakker.
+
+</DL>
+
+
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:petterr@stud.cs.uit.no">petterr@stud.cs.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Program for TDs Jubileumsuke</TITLE>
+<LINK REV="made" HREF="mailto:petterr@cs.uit.no">
+</HEAD>
+<BODY>
+<H1><A HREF="/~tdadm/">Tromsøstudentenes Dataforening</A> fyller 10 år</H1>
+
+25. april er det 10 år siden Tromsøstudentenes Dataforening ble
+stiftet. TD har bestemt seg for å markere denne hendelsen med en hel
+ukes feiring. Til feiringen er det invitert gjester fra
+dataforeningene over hele Norge,
+
+<H2>Program</H2>
+
+<DL>
+<DT>Lørdag 22. 19:00
+<DD>Prøvekjøring av bilsimulator med alkotest mm. (Begrenset)
+<DT>Mandag 24. 18:15 - 19:00 IMR Lille Aud.
+<DD><A HREF="http://www.cs.uit.no/~otto/">Otto Anshus</A>/<A HREF="/">SfI</A> - <B>Multimaskiner/distribuerte systemer</B>.[1]
+<DT>Tirsdag 25. 18:15 IMR Store Aud.
+<DD><A HREF="jubile.debatt.html"><B>Debatt om elekronisk informasjonsformidlings forhold i Norge</B></A>
+<BR>Med <A HREF="http://www.oslonett.no/html/profiles/gisle.html">Gisle Hannemyr</A>, Stein A. J. Møllerhaug og Ande Somby.
+<DT>Onsdag 26. 18:15 - 19:00, 19:15 - 20:00 IMR Store Aud.
+<DD><A HREF="http://www.pvv.unit.no/~ssb/">Stig Sæter Bakken</A>/<A HREF="http://www.pvv.unit.no/">PVV</A> - <B><A HREF="http://www.pvv.unit.no/~arnej/store/storedoc.html">STORE</A> - Automatisk programvaredistribusjon</B>.[2]
+ <BR><A HREF="http://www.cs.uit.no/~runeb/">Rune Braathen</A>/TD - <B>SATAN - Digitalt dyr i åpenbaringen eller verktøy for økt sikkerhet</B>.[3]
+<DT>Torsdag 27. 18:15 - 19:00, 19:15 - 20:00 IMR Store Aud.
+<DD>Jo Asplin/<A HREF="/">SfI</A> - <B>Volumavbilding av atmosfæriske og molekylære datasett.</B>[4]
+<BR><A HREF="/~stig/">Stig Johansen</A>/SfI - <B>Om
+raytracing</B>
+
+<DT>Fredag 28. 18:15 IMR Undervisningsrom 4
+<DD><B>Klassisk forum</B>.[5]
+</DL>
+
+Arrangementene er i utgangspunktet åpne for alle interesserte.
+
+<HR>
+<B>[1]</B> Dette er en presentasjon av en av de faglige sidene av prosjektet
+Distribuerte og Parallelle System (DOPS) ved Seksjon for Informatikk
+
+<P><B>[2]</B>
+STORE er et system for installasjon, distribusjon og vedlikehold
+av store mengder programvare. Dets hensikter er å forenkle
+installasjon på flere arktitekturer, tillate flere versjoner av samme
+applikasjon, være usynlig for sluttbrukere, ta vare på informasjon om
+lokale modifikasjoner og la administratorer enkelt velge hvilke
+applikasjoner som skal installeres eller ikke
+
+<P><B>[3]</B>
+Presentasjon av Security Administrators Tool for Analyzing
+Networks (SATAN), et brukervennlig brekkjern for systemcrackere.
+
+<P><B>[4]</B>
+Volumavbilding er en metode for visualisering av den indre
+strukturen i volumetriske skalarfelt. I dette foredraget presenteres
+StormView, et volumavbildings-program skrevet i C og med
+bruker-grensesnitt basert på X. Eksempler på visualisering av både
+atmosfæriske og molekylære datasett vil bli gitt. Volumavbilding er
+svært ressurskrevende, og ulike strategier for optimalisering vil bli
+skissert.
+
+<P><B>[5]</B>
+Dette er et gammelt konsept der man setter seg ned over en bok-øl
+med dempet klassisk musikk fra stereoanlegget og et datafaglig
+starttema.
+
+<HR>
+<ADDRESS><A HREF="/~petterr/">Petter Reinholdtsen</A> - petterr@stud.cs.uit.no</ADDRESS>
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 940913</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B>
+Tirsdag 13.september 1994
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 16:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, (Bjørn Stabell,) Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Dag-Frode Olsen, Vegar Næss, Bengt Norbakken, Frode Fjeld
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+
+<OL>
+0. Godkjenning av styremøtereferat
+<LI> Gjennomgang av post [Espen]
+
+<LI> Orienteringer
+<UL>
+<LI> Kvinneandelen på informatikk [Frode & Terje]
+<LI> Oppstart av vaktordningen [Ronny & Dag Frode]
+<LI> Tur til Autosom [Terje]
+</UL>
+<LI> Medlemsmøtet Torsdag 22. september [Frode]
+<UL>
+<LI> Omorganisering i styret?
+</UL>
+
+<LI> ISI-Cupen - 17. september [Petter]<BR>
+Jeg ber om at vi spanderer pizza på laget som takk for innsatsen.
+
+<LI> 10 års Jubileum, tirsdag 25. april 1995
+<UL>
+<LI> Jublieumshefte
+<LI> Ideer?
+</UL>
+
+<LI>Eventuelt
+</OL>
+
+Vedlegg: Tidsplan <A HREF="http://www.cs.uit.no/~tdadm/tidsplan.94h.html">H94</A> /
+<A HREF="http://www.cs.uit.no/~tdadm/tidsplan.95v.html">V95</A>. <P>
+
+
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+12.09.94
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 941003</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B>
+Tirsdag 3.oktober 1994
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 16:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Vegar Næss, (Bengt Norbakken,) Frode Fjeld, Runar Karlsen,
+Heidi Hundåla Villmones
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+Velkommen til de nye styremedlemmene.
+<OL>
+0. Godkjenning av styremøtereferat
+<LI> Gjennomgang av post [Espen]
+
+<LI> Orienteringer
+<UL>
+<LI> Kvinneandelen på informatikk [Frode & Terje]
+<LI> SUN SPARCstation 5 er SUN SPARCclassic [Petter]
+<LI> Tur til Autosom [Terje] <BR>
+Terje orienterer om mulig tur til Autosim
+</UL>
+<LI> Oppsummering fra Medlemsmøtet
+<LI> Publisitet rundt TD <BR>
+Vi må markere oss mer blant studentene og i miljøet.
+<LI> Arrangement for Høsten. <BR>
+Noen gode ideer til hva vi skal ta oss til. :-)
+<LI> Eventuelt
+</OL>
+
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+02.10.94
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 941025</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B> Tirsdag 25.oktober 1994
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 16:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen,
+Heidi Hundåla Villmones
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+Velkommen til de nye styremedlemmene.
+<OL>
+0. Godkjenning av styremøtereferat
+<LI> Gjennomgang av post [Espen]
+
+<LI> Orienteringer
+ <UL>
+ <LI> Pakke fra Skrivervik AS [Petter]
+ <LI> Bedriftsbesøk [Terje]
+ <LI> XPilot-konkurranse [Vegar]
+ <LI> Programmeringskonkurranse [Frode]
+ <LI> Juleavslutning [Espen]
+ <LI> Økonomi [Bengt]
+
+ <LI> Kontakt med Jentegruppa [Frode & Terje]
+ <LI> Nytt nummer av Vinduet [Vegar]
+</UL>
+
+<LI> Samarbeid med fagutvalget [Ronny & Frode]<BR>
+<I>Hvilken arbeidsdeling skal være mellom TD og fagutvalget?
+</I>
+<LI> Eventuelt
+</OL>
+
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+24.10.94
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 941122</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B> Tirsdag 22. november 1994
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 16:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen,
+Heidi Hundåla Villmones
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+<OL>
+0. Godkjenning av styremøtereferat
+<LI> Gjennomgang av post [Espen]
+<LI> Orienteringer
+ <UL>
+ <LI> Programmeringskonkurranse [Frode]
+ <LI> Nytt nummer av Vinduet [Vegar]
+ <LI> Fagutvalget [Ronny & Frode]<BR>
+ <LI> Status for TD-maskinene [Petter]
+</UL>
+
+<LI> Oppsummering fra XPilot-konkurransen
+<LI> Oppsummering fra Jentegruppas info for 1.klasse
+<LI> Bedriftsbesøk [Terje]
+<I> Skal vi ta en tur til Autosim? Hvor sent kan vi arrangere en tur? </I>
+<LI> Juleavslutning [Espen] <BR>
+<I> Hva gikk galt med årets juleavsluttning. Er det for sent å arrangere en?</I>
+<LI> Planer for våren
+<DL> <DT> 3.-5. februar?? (1.uke i feb.)
+ <DD>Skibotntur. [Vegar]
+ <DT> 25. april
+ <DD> 10 års jubileum
+ <DT> ?
+ <DD> Programmeringskonkurranse [Frode]
+ <DT> ?
+ <DD> Auksjon
+ <DT> ?
+ <DD> Forelesninger
+ <DT> ?
+ <DD> Bedriftsbesøk
+ <DT> ??
+ <DD> Hva som helst...
+</DL>
+
+<LI> Eventuelt
+</OL>
+
+BTW: Hvor i svarte er protokollen!
+
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+21.11.94
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 950119</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B> Torsdag 19. Januar 1995
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 12:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+(Ronny H. Arild, Vegar Næss,) Bengt Norbakken, Frode Fjeld, Runar Karlsen,
+Heidi Hundåla Villmones
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+<OL>0. <B>Godkjenning av styremøtereferat</B>
+<LI><B>Gjennomgang av post</B> [Espen]
+<LI><B>Orienteringer</B>
+ <UL> <LI>Status for TD-maskinene [Petter]
+ <LI>Skibotnturen 3.-5. febr. [Frode & Vegar]
+ <BR>Skrivervik Data sender to stykker. Søknad om
+ støtte sendt IMR, SfI og Skrivervik Data.
+ </UL>
+
+
+<LI><B>Vaktordningen</B> [Ronny]
+<BR>Det bør settes opp en ny ansvarlig, da Ronny ville trekke seg
+tilbake på årsmøtet.
+
+<LI><B>Forelesninger</B> [Petter]
+<BR>Jeg har vært å snakket med folk på SfI om forelesninger, og
+interessen var OK. Vi kan klare å kjøre igang 3-4 forelesninger med
+folk fra seksjonen.
+
+<LI><B>10 års jubileum</B> (24.-28. april) [Petter, Espen, Frode & Vegar]
+<BR>Debattarrangement Bing/Hannemyr - planlegging igang
+<BR>Invitasjon av andre dataforeninger
+<BR>Jubileumsaften (Bespisning & taler)
+<BR>...
+
+<LI><B>Forsikring til TD-maskinene</B>
+
+<BR> Forsikringsordningen for TD-maskinene gikk ut ved årsskiftet. Vi
+må organisere en ny. Jeg foreslår å spørre forsikringsselskap om å
+sponse dette mot at vi legger ut litt informasjon om dem på WWW.
+
+<LI><B>Vinduet</B> [Alle]
+<BR>De artiklene som ble avtalt skrevet til vinduet bør være ferdig
+snarest.
+
+<LI><B>Eventuelt</B>
+</OL>
+Vedlegg:
+<UL><LI><A HREF="/~tdadm/tidsplan.95v.html">Arrangementsplaner V95</A>
+<LI><A HREF="saker.950119.vinduet.txt">Huskeliste for vinduet</A>
+</UL>
+
+Beklager at denne kom så sent.
+<HR>
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+18.1.95
+</BODY>
+</HTML>
+
--- /dev/null
+Return-Path: vegarn@stud.cs.uit.no Thu
+Received: from hpserv0.cs.uit.no by lgserv1.cs.uit.no (1.37.109.13.2/Task/HJ-5)
+ id AA298491405; Thu, 24 Nov 1994 22:10:06 +0100
+Received: from lgserv1.cs.uit.no by hpserv0.cs.uit.no (1.37.109.13.2/Task/HJ-5)
+ id AA072111404; Thu, 24 Nov 1994 22:10:04 +0100
+Received: from hpserv0.cs.uit.no by lgserv1.cs.uit.no (1.37.109.13.2/Task/HJ-5)
+ id AA298421402; Thu, 24 Nov 1994 22:10:03 +0100
+Received: from pserv0.cs.uit.no (plab06.cs.UiT.No) by hpserv0.cs.uit.no (1.37.109.13.2/Task/HJ-5)
+ id AA071981400; Thu, 24 Nov 1994 22:10:01 +0100
+Received: by pserv0.cs.uit.no (1.37.109.11/Task/HJ-5)
+ id AA061661399; Thu, 24 Nov 1994 22:09:59 +0100
+Date: Thu, 24 Nov 1994 22:09:59 +0100
+From: vegarn@stud.cs.uit.no (Vegar Naess)
+Message-Id: <199411242109.AA061661399@pserv0.cs.uit.no>
+To: td@cs.uit.no
+Subject: Temaer for neste Vindu
+
+Huskeliste vinduet Våren 95
+
+Internet : vegarn
+Tilbud på internet: Terje
+Skadelige skjermer: vegarn
+Fotball turneringen: petter
+Skibotnturen: vegarn
+Td labben, nettforbindelser: Frode
+Modemforbindelser til lglab: Petter ordner
+Fagutvalget: Ronny
+Derfor programerer ikke Japanerne: vegarn
+Pornobilder på labben: petter
+
+Espen står parat med scanneren til bilder fra skibotn(Se
+pornobilder på labben) og fotballturneringen.
+
+Andre ideer:
+ Markedsføring av systemadministrator Våren 95
+ Revolverint. av Heidi
+
+
+
+
+Hvis det er noen gode ideer så kom med dem......
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 950201</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B> Onsdag 1. Februar 1995
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 16:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen,
+Heidi Hundåla Villmones
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+<OL>0. <B>Godkjenning av styremøtereferat</B>
+<LI><B>Gjennomgang av post</B> [Espen]
+<LI><B>Orienteringer</B>
+ <UL> <LI>Skibotnturen 3.-5. febr. [Frode & Vegar]
+ <LI>Skifte av ansvarlig for vaktordningen [Ronny & Heidi]
+ <LI>Forsikring til TD-maskinenen [Terje]
+ <LI>10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar]
+ <LI>Programmeringskonkurranse [Frode]
+ <LI>Forelesninger [Petter]
+ <LI>Artikler til Vinduet [Alle]
+ <LI>Bedriftsbesøk [Terje & Heidi]
+ </UL>
+
+<LI><B>Vaktordningen</B> [Ronny]
+
+<BR>- Instituttrådet har bedt om en henvendelse der de får presentert
+et forslag fra TD om kompensasjon for gjennomføringen av
+vaktordningen. Tore Larsen nevnte i den forbindelse at vi også burde
+fokusere på brukerkurset som vi har gjennomført i lengre tid. Skal vi
+legge oss på honorering av enkeltvakter, eller en honnorering av TD
+som helhet?
+<BR>- Tom Grydeland (Inst.råds repr) satte opp denne lista som innspill
+til hva henvendelsen burde inneholde.
+
+<UL><LI>Sett opp hvor mye (i kr) som er rimelig honorering for å sitte
+ vakt i 3.5 t. (Det er tenkelig å bruke en "stige" i
+ honoreringen, eks. 1 gang: 150,- 2 ganger: 250,- 3 ganger
+ 350,- osv)
+<LI>Beregn 5 vakter i uka, (18 vår+15 høst) 33 uker pr. år.
+<LI>Foreslå hvordan utgiftene skal fordeles
+
+</UL>
+<LI><B>Saker til Årsmøtet</B>
+<BR>Saker til årsmøtet må planlegges.
+
+<LI><B>Valg av revisor</B>
+<BR>Vi må velge en revisor til å gå gjennom regnskapet sammen med Bengt.
+
+<LI><B>Eventuelt</B>
+</OL>
+Vedlegg:
+<UL><LI><A HREF="/~tdadm/tidsplan.95v.html">Arrangementsplaner V95</A>
+<LI><A HREF="saker.950119.vinduet.txt">Huskeliste for vinduet</A>
+</UL>
+
+<HR>
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+31.1.95
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 950201</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT> <B>Dato:</B> Onsdag 15. Februar 1995
+<DT> <B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT> <B>Når:</B> kl. 16:15
+<DT> <B>Styret:</B>
+<DD> Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen,
+Heidi Villmones Hundåla
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+<OL>0. <B>Godkjenning av styremøtereferat</B>
+<LI><B>Gjennomgang av post</B> [Espen]
+<LI><B>Orienteringer</B>
+ <UL> <LI>"Datapub" i forbindelse med Uka95
+ <LI>Forsikring til TD-maskinenen [Terje]
+ <LI>10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar]
+ <LI>Programmeringskonkurranse [Frode]
+ <LI>Bedriftsbesøk [Terje & Heidi]
+ <LI>Framdrift for Vinduet [Vegar]
+ </UL>
+
+<LI><B>Vaktordningen</B> [Ronny]
+
+<BR>- Brev til Instituttet ang. vaktordningspenger presenteres[Bengt]
+
+<LI><B>Oppsummering Skibotnturen 3.-5. febr.</B> [Frode, Petter & Vegar]
+
+<LI><B>Saker til Årsmøtet</B> [Espen & Ronny]
+<BR>Saksliste til Årsmøtet må gjøres klart og innkalling sendes ut.
+
+<LI><B>Valg av revisor</B> [Bengt]
+<BR>Vil Ole Kristian? være revisor?
+
+<LI><B>Eventuelt</B>
+</OL>
+Vedlegg:
+<UL><LI><A HREF="/~tdadm/tidsplan.95v.html">Arrangementsplaner V95</A>
+<LI><A HREF="saker.950119.vinduet.txt">Huskeliste for vinduet</A>
+</UL>
+
+<HR>
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+13.2.95
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Saksliste til Styremøte i TD 950301</TITLE>
+</HEAD>
+<BODY>
+
+<DL>
+<DT><B>Dato:</B> Onsdag 1. Mars 1995
+<DT><B>Sted:</B> Møterommet utenfor Ekspedisjonen, IMR
+<DT><B>Når:</B> kl. 16:15
+<DT><B>Styret:</B>
+<DD>Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen,
+Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen,
+Heidi Villmones Hundåla
+</DL>
+<HR>
+<H1>Saksliste til Styremøte i TD</H1>
+<OL>0. <B>Godkjenning av styremøtereferat</B>
+<LI><B>Gjennomgang av post</B> [Espen]
+<LI><B>Orienteringer</B>
+ <UL> <LI>10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar]
+ <LI>Programmeringskonkurranse [Frode]
+ <LI>Brev til Instituttet sendt [Petter & Bengt]
+ </UL>
+
+<LI><B>Bedriftsbesøk</B> [Terje & Heidi]
+<BR>Dato for besøk på Autosim og Spacetec skulle nå være klart, og
+alle praktiske ting må fordeles til noen av de som fortsetter i
+styret.
+
+<LI><B>Forsikring til TD-maskinenen</B> [Terje]
+<BR>Terje har undersøkt priser på forsikring, og vi må bestemme oss
+for hvilken vi tar.
+
+<LI><B>Årsmøtet</B> [Espen & Ronny]
+<BR>Alt skulle nå være klart til årsmøtet.
+
+<LI><B>Godkjenning av regnskap for 1994</B>
+<BR>Regnskapet som ble godkjent per mail må refereres i
+styreprotokollen.
+
+<LI><B>Regnskap 1995 fram til nå</B> [Bengt]
+<BR>Bengt legger fram regnskapet før perioden hans er over..
+
+<LI><B>Abonnement på Linux Journal</B>
+<BR>Jeg foreslår at vi gjennomfører abonnement på tidsskrfter til
+utlegging på TD-labben. Som en start foreslår jeg at vi bestiller
+abonnemet på Linux Journal, et tidsskrift for linux-brukere.
+
+<LI><B>Eventuelt</B>
+</OL>
+Vedlegg:
+<UL><LI><A HREF="/~tdadm/tidsplan.95v.html">Arrangementsplaner V95</A>
+</UL>
+
+<HR>
+<ADDRESS>Petter Reinholdtsen - Leder TD</ADDRESS>
+13.2.95
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE>Backup-rutiner på Origo</TITLE>
+<!-- Changed by: Petter Reinholdtsen, 11-Jun-1996 -->
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+Origo drift - 1996-06-11
+<BR>Petter Reinholdtsen <pere@td.org.uit.no>
+<HR>
+
+<H1>Backup-rutiner på Origo</H1>
+
+Backup foretas daglig av den som sitter nærmest DAT-spilleren. Pr.
+1996-06-11 er dette Geir Frierstad.
+
+<P>Tanken er at det for hver maskin skal være 1 tidligere backup på
+tape fra de siste tre ukene. Eneste unntak er kjell, valborg og egon,
+som er prioritert opp og som vil få dobbelt så mange backup.
+
+<P>Backup tas av cron-jobber som kjøres fra valborg hver natt
+vha. <CODE>rsh</CODE>. Hver morgen skal nattens backup tas vare på og
+neste dags backup-tape gjøres klar.
+
+<P>Alle DAT-tapene merkes med maskin, ukedag og nummer og rotes i
+løpet av tre uker.
+
+<H2>Daglig rutine</H2>
+
+<OL>
+<LI>Ta ut DAT-tape og merk med dato. Kontroller at DAT-nummer stemmer
+overens med mail utsendt av cron.
+<LI>Sett i neste DAT-tape (ett nummer større)
+<LI>Frakt tapen merket med dagens dato til safe el.
+</OL>
+
+<H2>Dagsoversikt, backuptaper</H2>
+Det er 11 maskiner - kjell, valborg og egon er viktigst.
+
+<TABLE border>
+<TR><TH>Maskin <TH>Natt til <TH>Dagsnummer
+
+<TR><TD>Kjell <TD>Mandag <TD>1
+<TR><TD>Valborg <TD>Tirsdag <TD>2
+<TR><TD>egon <TD>Onsdag <TD>3
+<TR><TD>gunnar <TD>Torsdag <TD>4
+<TR><TD>Kjell <TD>Fredag <TD>5
+
+<TR><TD>benny <TD>Mandag <TD>6
+<TR><TD>basse <TD>Tirsdag <TD>7
+<TR><TD>cola <TD>Onsdag <TD>8
+<TR><TD>Valborg <TD>Torsdag <TD>9
+<TR><TD>death <TD>Fredag <TD>10
+<TR><TD>eurosong<TD>Mandag <TD>11
+<TR><TD>pcpdy <TD>Tirsdag <TD>12
+<TR><TD>egon <TD>Onsdag <TD>13
+<TR><TD>romeo <TD>Torsdag <TD>14
+<TR><TD>gunnar <TD>Fredag <TD>15
+</TABLE>
+
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:petterr@stud.cs.uit.no">petterr@stud.cs.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<!-- Changed by: Petter Reinholdtsen, 4-Dec-1995 -->
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+<H1>Compilering av perl</H1>
+<PRE>
+./Configure -Dprefix=/store
+
+Use which C compiler?
+ gcc
+Any additional cc flags?
+ none
+Any additional ld flags (NOT including libraries)?
+ -L/store/lib
+Do you wish to use dynamic loading?
+ n (Irix)
+Local directory for additional library files? (~name ok)
+ /store/lib/perl
+Where do the Perl5 library man pages (source) go? (~name ok)
+ /store/man/man3
+</PRE>
+
+<H1>Compiling gcc</H1>
+
+<PRE>
+./configure --prefix=/store --local-prefix=/store --gxx-include-dir=/store/lib/g++-include <hosttype>
+make bootstrap
+</PRE>
+
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:petterr@stud.cs.uit.no">petterr@stud.cs.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
--- /dev/null
+<HTML>
+<HEAD>
+<TITLE></TITLE>
+<!-- Changed by: Petter Reinholdtsen, 4-Dec-1995 -->
+<LINK REV="made" HREF="mailto:petterr@stud.cs.uit.no">
+</HEAD>
+<BODY>
+<H1>Konfigurering av xntpd(8)</H1>
+
+xntp er kompilert i store.
+
+For å starte brukes '/store/etc/init.d/xntpd start'.
+
+<P>Konfigurasjonsfilene ligger på valborg:/local/config (ntp.conf*).
+
+<HR>
+<ADDRESS>Petter Reinholdtsen -
+<A HREF="mailto:petterr@stud.cs.uit.no">petterr@stud.cs.uit.no</A></ADDRESS>
+
+</BODY>
+</HTML>
+
projects / homepage.git / commitdiff
