From 50fd5a5edeec7de7f708076ba72e9f2bbd17573c Mon Sep 17 00:00:00 2001 From: Petter Reinholdtsen Date: Thu, 15 Jan 2004 16:02:43 +0000 Subject: [PATCH] More pages from www.hungry.com. --- hp4000c/XF86Config | 403 + hp4000c/index.html | 20 + hp4000c/index.html.19961018 | 130 + hp4000c/soundconf | 38 + huset/styrem.html | 26 + java/Hello.html | 11 + java/HelloWorld.class | Bin 0 -> 506 bytes mrtg/index.html | 54 + mrtg/mail-day.gif | Bin 0 -> 6861 bytes mrtg/mail-month.gif | Bin 0 -> 6833 bytes mrtg/mail-week.gif | Bin 0 -> 7482 bytes mrtg/mail-year.gif | Bin 0 -> 4574 bytes mrtg/mail.html | 218 + mrtg/mail.log | 2535 ++++ mrtg/mailstats | 94 + mrtg/mq-day.gif | Bin 0 -> 3755 bytes mrtg/mq-month.gif | Bin 0 -> 4436 bytes mrtg/mq-week.gif | Bin 0 -> 3415 bytes mrtg/mq.html | 139 + mrtg/mq.log | 2535 ++++ mrtg/mqueue | 15 + mrtg/mrtg.conf | 37 + mrtg/mrtg.ok | 0 perl/aliases2html-1.0.tar.gz | Bin 0 -> 1194 bytes perl/aliases2html-1.1.tar.gz | Bin 0 -> 1434 bytes reports/rfc/draft-andrews-dns-ascii-01.txt | 109 + .../rfc/draft-gulbrandsen-dns-rr-srvcs-03.txt | 559 + reports/rfc/draft-ietf-dnsind-clarify-01.txt | 334 + reports/rfc/draft-ietf-dnsind-serial-03.txt | 445 + reports/rfc/draft-ietf-drums-smtpupd-02.txt | 3403 +++++ reports/rfc/draft-ietf-html-i18n-04.txt | 2296 +++ reports/rfc/draft-ietf-http-v11-spec-03.txt | 8893 +++++++++++ reports/rfc/draft-ietf-ids-dnsnames-00.txt | 561 + .../draft-ietf-mailext-mail-attributes-04.txt | 1154 ++ reports/rfc/draft-ietf-ssh-handbook-03.txt | 5334 +++++++ .../rfc/draft-ietf-userglos-glossary2-01.txt | 3472 +++++ reports/rfc/draft-newman-datetime-00.txt | 505 + reports/rfc/draft-vixie-ops-stdaddr-00.txt | 317 + reports/rfc/draft-vixie-ops-stdaddr-01.txt | 369 + reports/rfc/rfc1942.txt | 1683 ++ ss/19960831-rekrutering.html | 69 + ss/19960908.net-tjenester.html | 89 + ss/9610.semavg.html | 180 + ss/budsj96.html | 56 + ss/pc-spec.html | 54 + ss/ref97k.html | 275 + ss/regn96.html | 108 + store/doc-espensk/emacs-default.html | 48 + store/doc-espensk/emacs-dir.html | 95 + store/doc-espensk/environ.html | 208 + store/doc-espensk/in-install.html | 102 + store/doc-espensk/index.html | 24 + store/doc-espensk/install.html | 28 + store/doc-espensk/mailcap.html | 91 + store/doc-espensk/post-install.html | 303 + store/doc-espensk/pre-install.html | 128 + store/doc-espensk/spec-config.html | 24 + store/httpstore.html | 16 + store/httpstore/httpstore-0.1.tar.gz | Bin 0 -> 1216 bytes store/httpstore/httpstore-0.2.tar.gz | Bin 0 -> 2164 bytes store/storepaper.ps | 12637 ++++++++++++++++ td-drift/950209.referat.html | 52 + td-drift/950330.referat.html | 40 + td-drift/foreningstilgang.html | 35 + td-drift/letter2.gif | Bin 0 -> 92 bytes td-drift/skjema.html | 133 + td-drift/tddb.gif | Bin 0 -> 9420 bytes td/jubile.budsjett.html | 41 + td/jubile.debatt.html | 59 + td/jubile.gjest.html | 20 + td/jubile.jobb.txt | 21 + td/jubile.oppsum.html | 38 + td/jubile.prog.html | 72 + td/saker.940913.html | 54 + td/saker.941003.html | 43 + td/saker.941025.html | 46 + td/saker.941122.html | 61 + td/saker.950119.html | 66 + td/saker.950119.vinduet.txt | 41 + td/saker.950201.html | 68 + td/saker.950215.html | 53 + td/saker.950301.html | 61 + tm/backuprutine.html | 67 + tm/perl.compile.html | 39 + tm/xntpd.conf.html | 22 + 85 files changed, 51356 insertions(+) create mode 100644 hp4000c/XF86Config create mode 100644 hp4000c/index.html create mode 100644 hp4000c/index.html.19961018 create mode 100644 hp4000c/soundconf create mode 100644 huset/styrem.html create mode 100644 java/Hello.html create mode 100644 java/HelloWorld.class create mode 100644 mrtg/index.html create mode 100644 mrtg/mail-day.gif create mode 100644 mrtg/mail-month.gif create mode 100644 mrtg/mail-week.gif create mode 100644 mrtg/mail-year.gif create mode 100644 mrtg/mail.html create mode 100644 mrtg/mail.log create mode 100755 mrtg/mailstats create mode 100644 mrtg/mq-day.gif create mode 100644 mrtg/mq-month.gif create mode 100644 mrtg/mq-week.gif create mode 100644 mrtg/mq.html create mode 100644 mrtg/mq.log create mode 100755 mrtg/mqueue create mode 100644 mrtg/mrtg.conf create mode 100644 mrtg/mrtg.ok create mode 100644 perl/aliases2html-1.0.tar.gz create mode 100644 perl/aliases2html-1.1.tar.gz create mode 100644 reports/rfc/draft-andrews-dns-ascii-01.txt create mode 100644 reports/rfc/draft-gulbrandsen-dns-rr-srvcs-03.txt create mode 100644 reports/rfc/draft-ietf-dnsind-clarify-01.txt create mode 100644 reports/rfc/draft-ietf-dnsind-serial-03.txt create mode 100644 reports/rfc/draft-ietf-drums-smtpupd-02.txt create mode 100644 reports/rfc/draft-ietf-html-i18n-04.txt create mode 100644 reports/rfc/draft-ietf-http-v11-spec-03.txt create mode 100644 reports/rfc/draft-ietf-ids-dnsnames-00.txt create mode 100644 reports/rfc/draft-ietf-mailext-mail-attributes-04.txt create mode 100644 reports/rfc/draft-ietf-ssh-handbook-03.txt create mode 100644 reports/rfc/draft-ietf-userglos-glossary2-01.txt create mode 100644 reports/rfc/draft-newman-datetime-00.txt create mode 100644 reports/rfc/draft-vixie-ops-stdaddr-00.txt create mode 100644 reports/rfc/draft-vixie-ops-stdaddr-01.txt create mode 100644 reports/rfc/rfc1942.txt create mode 100644 ss/19960831-rekrutering.html create mode 100644 ss/19960908.net-tjenester.html create mode 100644 ss/9610.semavg.html create mode 100644 ss/budsj96.html create mode 100644 ss/pc-spec.html create mode 100644 ss/ref97k.html create mode 100644 ss/regn96.html create mode 100644 store/doc-espensk/emacs-default.html create mode 100644 store/doc-espensk/emacs-dir.html create mode 100644 store/doc-espensk/environ.html create mode 100644 store/doc-espensk/in-install.html create mode 100644 store/doc-espensk/index.html create mode 100644 store/doc-espensk/install.html create mode 100644 store/doc-espensk/mailcap.html create mode 100644 store/doc-espensk/post-install.html create mode 100644 store/doc-espensk/pre-install.html create mode 100644 store/doc-espensk/spec-config.html create mode 100644 store/httpstore.html create mode 100644 store/httpstore/httpstore-0.1.tar.gz create mode 100644 store/httpstore/httpstore-0.2.tar.gz create mode 100644 store/storepaper.ps create mode 100755 td-drift/950209.referat.html create mode 100755 td-drift/950330.referat.html create mode 100644 td-drift/foreningstilgang.html create mode 100644 td-drift/letter2.gif create mode 100644 td-drift/skjema.html create mode 100644 td-drift/tddb.gif create mode 100644 td/jubile.budsjett.html create mode 100644 td/jubile.debatt.html create mode 100644 td/jubile.gjest.html create mode 100644 td/jubile.jobb.txt create mode 100644 td/jubile.oppsum.html create mode 100644 td/jubile.prog.html create mode 100644 td/saker.940913.html create mode 100644 td/saker.941003.html create mode 100644 td/saker.941025.html create mode 100644 td/saker.941122.html create mode 100644 td/saker.950119.html create mode 100644 td/saker.950119.vinduet.txt create mode 100644 td/saker.950201.html create mode 100644 td/saker.950215.html create mode 100644 td/saker.950301.html create mode 100644 tm/backuprutine.html create mode 100644 tm/perl.compile.html create mode 100644 tm/xntpd.conf.html diff --git a/hp4000c/XF86Config b/hp4000c/XF86Config new file mode 100644 index 0000000000..ffb6775126 --- /dev/null +++ b/hp4000c/XF86Config @@ -0,0 +1,403 @@ +# 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 server abort sequence +# This allows clients to receive this key event. + +# DontZap + +# Uncomment this to disable the / 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 diff --git a/hp4000c/index.html b/hp4000c/index.html new file mode 100644 index 0000000000..1c4c08ca8e --- /dev/null +++ b/hp4000c/index.html @@ -0,0 +1,20 @@ + + + +Redirect to new maintainter + + + + +

Redirect to new maintainter

+ +As of 1996-10-18, this page got a new maintainer, Aaron Bond +<abond@mail2.quiknet.com>. Take the jump to the +new site. +
+
Petter Reinholdtsen - +pere@td.org.uit.no
+ + + + diff --git a/hp4000c/index.html.19961018 b/hp4000c/index.html.19961018 new file mode 100644 index 0000000000..c8ce4ad3b9 --- /dev/null +++ b/hp4000c/index.html.19961018 @@ -0,0 +1,130 @@ + + +HP Omnibook 4000C - Linux page + + + + + +
+ +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 +pere@td.org.uit.no if you are +interested. + +
+ +

HP Omnibook 4000C - Linux page

+ +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. + +

4000C contains an 16bit sound-card and an infrared sender/receiver. +The IR-device is /dev/{ttyS1,cua1}. The tracking ball +has an PS/2 busmouse interface. + +

+ +

Kernel configuration

 + +All this is tried on Linux kernel v.1.3.59. + +

The option Pocket and portable adaptors is not needed to +use PCMCIA cards. + +

Advanced Power Management configuration

+ +
+
Ignore USER SUSPEND: N +
Enable PM at boot time: N +
This seems to be important to get a stable system. +
Make CPU Idle calls when idle: Y +
Enable console blanking using APM: N +
Console blanking was not supported on linux 1.3.75 +
+ +

Sound configuration

+ +Windows gives me the following information about the sound facilities: +
+ESS AudioDrive ES688
+  I/O port 220
+  IRQ        7
+  DMA        1 size 32
+ESS AudioDrive MIDI
+
+ +Brian Vinter reported IRQ 5 from Windows 95. This is normal, as the +IRQ and DMA can be changed in the bios setup. + +

It seems to be compatible with Soundblaster Pro. With a simple +configuration file I managed to get stereo +sound. Copy this to /etc/soundconf and run make config in /usr/src/linux/drivers/sound/. + +

XFree86 configuration

+ +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 +sample XF86Config which gives +you resolution 640x480. Copy this file to +/etc/XF86Config or /etc/X11/XF86Config. + + +

My screen is screwed up

 + +Sometime, after leaving X, the screen gets completely screwed up. +This is due to a bug in the chipset. To restore the screen, press +fn F5. + +

Problems with PCMCIA

 + +Dag Brattli has experimented with two different Ethernet-cards and +discovered many problems. + +

"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 +/etc/pcmcia/config, or +/etc/pcmcia/config.opts to get the card to work at +all. 'exclude 0x300-0x30f' in the same file seems to avoid some strange +conflict. + +

IBM CCA Ethernet II works with all the pcmcia-cs versions tried. +This card needs 'mem_speed=600' in /etc/pcmcia/config or +/etc/pcmcia/config.opts if it exists. This improves +transfer speed and prevents filling /usr/adm/messages +with UDP error messages." + +

More information

+ + + +

Acknowledgments

 + +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. + +
+
Petter Reinholdtsen - +pere@td.org.uit.no
+ + + + diff --git a/hp4000c/soundconf b/hp4000c/soundconf new file mode 100644 index 0000000000..51424e4530 --- /dev/null +++ b/hp4000c/soundconf @@ -0,0 +1,38 @@ +/* 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 diff --git a/huset/styrem.html b/huset/styrem.html new file mode 100644 index 0000000000..32d4214a6f --- /dev/null +++ b/huset/styrem.html @@ -0,0 +1,26 @@ + + +Møter i Studenthuset AS + + + +
    +
  • 930626 Generalforsamling +
    +
  • 940126 Styremøte 01.94 sak 01-03/94 +
  • 940325 Styremøte 02.94 sak 04-07/94 +
  • 940426 Styremøte 03.94 sak 08-11/94 +
  • 940511 Styremøte 04.94 sak 12-14/94 +
  • 940603 Styremøte 05.94 sak 15-17/94 +
  • 940901 Styremøte 06.94 sak 18-22/94 +
  • 940922 Ekstraordinært styremøte 07.94 sak 23/94 +
  • 940925 Styremøte 08.94 sak 24-26/94 +
  • 941007 Styremøte 09.94 sak 27-31/94 +
  • 941014 Styremøte 10.94 sak 32-34/94 +
  • 941020 Styremøte 11.94 sak 35-37/94 +
+ + + + + diff --git a/java/Hello.html b/java/Hello.html new file mode 100644 index 0000000000..539450af6e --- /dev/null +++ b/java/Hello.html @@ -0,0 +1,11 @@ + + + A Simple Program + + + + Here is the output of my program: + + + + diff --git a/java/HelloWorld.class b/java/HelloWorld.class new file mode 100644 index 0000000000000000000000000000000000000000..9bb040125ec8007c86b96fec67b64114ae6902bd GIT binary patch literal 506 zcmZWm%Sr<=6g{!F(~hII^;uu|*t8W5xK#uZd_Zwi8P{;(xeNaN!5| zQR2|w#fqK7pf1yp>(%dYYR%%Kq=z;u8mtTQY& zJNM#Ia52pIxfRKsiqgYY$WXE}RnL;4*u1=S!1Sq!(@ex!DD;5v*^Y|k)!^Y)+G}yE z3GusTU?X{^Tr<-#kfRQ^()blx#C<+8KOCiQbNQ4QoAEpIAbBFKHI#^+Xn>UpfwUZ-xmK q{?6nCrgrPBdf)`5zXFehC8E;Tj0FuwvD)wOeyNTC@@J^#=gJT1cW0~s literal 0 HcmV?d00001 diff --git a/mrtg/index.html b/mrtg/index.html new file mode 100644 index 0000000000..4c301b156b --- /dev/null +++ b/mrtg/index.html @@ -0,0 +1,54 @@ + + +Sendmail statistics + + + + + + + +
+ ETH: + + + Swiss Federal Institute of Technology Zurich
+ + Department of Electrical Engineering
+
+ +

Sendmail statistics

+

terror.hungry.com Sendmail MailQueue Statistics

+

+ +
+

terror.hungry.com Sendmail send/receive Statistics

+

+ +
+ + + + + + +
+ + + + + + +
+ 2.0-1997/01/26 + Tobias Oetiker + <oetiker@ee.ethz.ch> + and Dave Rand <dlr@bungi.com> +
+ diff --git a/mrtg/mail-day.gif b/mrtg/mail-day.gif new file mode 100644 index 0000000000000000000000000000000000000000..82da8fbc85883ff3340b016b42712a76ce1aa9ad GIT binary patch literal 6861 zcmV;;8ZzZaNk%v~VORpA0OJ4v_4W0_!op-^Wd8sF0L%aY0001H0RI600093301Olc zJqZthU*H2k02ToN3M)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`jt1cyZnW_S`>b%zP9#-IImNy zc85*QvvD}0yBdgWYR{4M{t+~Kav-%=3i*1Ew{T0qCoh)#7&Px^>f{y|Emy~M#E#dp z4FsQjRrGN|rPW_qy#M}{)&6w~a^tnN4kS?tXqA++?PnJ<7TXSjWAc84+V&0qsAqt!;HHoNRFmno&kWKs{ z5J#DUoCjt@K>}F-0cmL&VS&An79=N}1uCH?k*>1dGfX9lVpNdQRTqqkoqA|HV5lnE zX7ISg--JW_NzbTR{&q&@aC8PzYI;Es*ChZ1WJ`c?+2)jOc%ib0Evd-a8LD&U26^0& zSYa}NiPXZIW{snD3uJZpt_ZG*2#|X2ywU<0a1Z_VyX}tsGDNDj3{#m?P5v4T+a=v% zQt`It*7@*itcmNfn&ql{BrLI}mRg@VC`*NhWubf_gfH9YD}czN`s-jZznZhnG|yb~ z&4u|a^v*yV+TQ?3dy}D&dyS)ygc*^e8(9uEUG+y!521<6Sv&IxIbQ!94A*1Oyco(G zdKd)NW@CLdL0zv6bth`L{5B6NGp+aDeE045HF^In_~3*WZg>-ccavA$o-ls+N<1Jv*^}`?|sqO zhrYdSuj9rO@H|BqCOgL$FFzsie}3B}{@6bVQ|}kz{@(SQp8)AlKf7f?d81%nGx!I- z@oDZbx&V~}8<;)7Oz?WE+Z+ThD834o?}PR^U+C^<1*$zyBGD590~?eGMr}+s{lne- zVkiU}3b24mQ(x>(grgP?%uIJ8m<^{fydhr0h(fI40I|aa11d{u27H5eR`tX0VUQt( zQceDQU^JOtb+CF}S&n;-bww+RZ-W&Ck)p_#K@YYOj9c*>2{m)2Ga=DM8;g@~fVH9^ zUS$qqWTA1KGYuHBp=1Q3&H!<^Bm_RecPH#f3fBgrTMZ&o;Of$FJSMI~{^$yUG}(gM zq{u(Grju|=WSRPy$iC^Ri8;hyLZaw~DS}E~6ojJ|Ga;#(oF_$>fK{t%@g7-xsf+^| zlb!6MMJ3_rm+3+#P5QV-Q*^REV1j0Pl=MPqFf&b>b7S{9S0N^Pq$y5xWIS9oFBaVq zSl8m$wL%6hRJLPcd*q@jqvc2GXbMgDf)ab`35|$Vu??0?B0!l?GGPgfUGfyzmi`F& zNkZ83PRB!MEQi9*Pt6BJto*2#B6=Ja5)`0Qd6As@*-kXYhDZM-&Oo~v(0h?fWKu|1 zKv5~Ii@u{r$g!7+u*9!$p$kg5^l6Lk$wz7lX<9lUnLY=lzuoCjLuatXBuTNbgz@qQ z-|~%m7)CB~jp|?p!&oL3#xQAlCt?`u6j|rWn~Q0yU%xD<#MJW}#Sq}EbNv>x$O_iK z8nm$6s;j?nAXs_&D_fR0SXklURdV%;VhL-A#MC7hZPm-Ntio2OxaBWq6^w_>(rZDz zStfTYQQETAuxX|1ZJY9~zZ$Gz1siNv$JN={R&1>|<*jH<{tKG0p7pea z<>g`v+bOy%wyw|(k*5N2up7*19i$SjP?0vg%2}mDTV06Sn)f}Hq}L?tO$CRhHs7$k zSH85Y>MWudUloSpzJKX2M*6fh0{@r3Y12o2(*WT8rt_*xjIe|!OkpCJx560Cu!d)M z;SGEE!ywjMhuNFev9zMWAx^Q1SBxPD>%nbtE1Q1D0>v8J_{KQSv5t4l;~x9?$3PCU zjt3y*A{+V0NKUenm(1iQJ9)@T#*B-XbtD$k&&pVC0wbj?%bDci%iaxhRlq!EF_Zbs zW=?aN*NkR1tGUf^ezTn2Oy@Y)dCqZ2+MV}o=RV{4&wK{7p94+)=s_D=(1c-yF(;t<`RVC)Fr0Ph>tIBnvI$MbT~ErMp0k7)YXt<`X+4;_GS4F0etm} zx7=b@14^Q@u0yPI9b#G+L1jwGFB^bo>0)~t)u9gIv6IbgPK(poq;58-p>1jr#%GTC z0|P4Cg> z```QyIKBlA@PXf($ObRC!U@jsgg1QQ4v#p*C;sq?OWfiVzqrOTo^OP6oN)s7iaJdw z4Pq~w+Q^pRv!~5+F|T~orZzSQXa4e2OPglaZqllgGUNU_xcVOd)0?=*t>JPf>)hJ- zxjll;w4oCn!$#lE$X6lkH84=-r$ggPR32@V-yC!?KY7ay)Ag}qz3ebYHfm~)?N}&~ z5-Y?8R8raW89p5gQ4hk17wA;E?~_MDxBK0#koTBO{q0&?@VX6nby1pq7+ZYiovLYb zuUpXQ?(;V%Ue|)DW*mj*4)!Xf_x|MY` zw||C5fk{_K1LJ`drGe6dNP_f$bkIYDcZF@jfh=_gr}Ty1r%GNJL{cae5?FdGGX|m% za->j6VkL%uWK{7&fJFjQZlHyDz=a&cfXxtwG(<|P)O}60H?QV}DyC~u?XG_@xe{_4h8yy1zir-@W|iKr+j{bq`&XK<_t2X*6b zqgaWuGK>1wiv4zqu9%7ir-|+Hie4a#o7juISc&R^i5eA*#JG#hxQxyiZ@`F(!l;V{ z*L?ZLiqH3JQ`a^D0f*L?g()I3S5j2GqEyYXFV)glS0Ez`HHbYmeek#jdN_UNs6-D{ zQ_(_&Wq2Bg=ueUsedRJJXUJ5lf=}Z(G36+S4--${ z5S51jGj}J&P@H*{9%+y@6&t#8mkx<1k10wH1v14#n4=Vg=H`UippqV?S+f}|naNtf zAd{kFFd~&#D8dQfqLmqwS3(#~h51!^6d-MxPs5T>vT~Z8C64r$6Hi%`;8~MEOB47SRF_twc_7Yv+v@!WPOgIA-ta4eaiB5wEc2a3F>8Y40xm9kM z3UFnh1t|!?RVoz&UAL()!|#cVF`uF}5~OmZoaDrfiC2MAoKo8mDqP zr*vAUJNBkQMqcEFpo7<^e)^}qsffwJHYnCOPm@4rfjn*_rr}Uxhl)Irgl>t-cqvFW z@-{Ws77~cJg8pH#s818ABsOE9syKYAH!M@A<*=Y^s5_I$Z7QUAr0{&IN@J)us|WTq zwmL#5#$PD5swT#IvupvOE)tayh>tP7HunzmMOVqFsJFyhYVMtf87@M)SBe9F9sguDr z8XK}AO9&jh5wc2kZr5`oyRt0n1SM-Vje4n`ny4*%1lm`#e3OPd$CXSNdf{1>J^O=R z+I~T+{)9sNvqT(Z_BoZ>wb<~w1~^NW(#_1*lKk7w@Zk*wiCF?ve=EA9i-x5et*C&KC8WEd+q=ZWxhZpQ!ixo| zOS^~bypQ{Ji@Un7E4yn;z0ljbTWe~Si>Uix4v1=|a7%W4OLV+zyk7RZfr_k;`U}DS zma=xEboEfa+Hk(;YY)g9x5^8x2GJqz3$pQBxYbLxTo=99Yas)iy|eqg3~a!O`#sb9 zkEf@yQbfG*z;s4pzxPWI`FjI-ldHR7!R&y+*P+213_t37bQH+HjL^Idti35wz%V?+ zcALO2yuc1Dxe9#1#}L6AB@COY2=Yr0B%B;3e8Mv1wZI#ya3{jrP{gxw#7KM%9ehA1 z$*6YFcs3lpGK|ACymmLt!(05t4_wANY(D-cxK|v+i4b>3)JjXGfWAYClRhwO4;Y{t}^$dDYnW30Go+`0aO`o6!@ zcW+#q_UOmK1IR2U$SaJ;bD+nC^mjj1wR60?DJ*rR{JEq-$>0D%>`^Z>HdbbO|xf_m0gd_Dhf>A7ZbxX?93c@h5aX#LkQb*W5SI zjI8nNG@Gi)iZjd1e6;A-Ao=+gi#*A!W4-WvoDJ*_xeUyfw#!%RV3vxqG7C3ebDQ7% zBiRhP9K*_gj8ME5&b!*Ic`SX9c}dl$&0pEf^5cPK8MU{=&{!*d_}$ z2vecdanyLnhkVR5K*33hZYTgo%z%xD36To(~vDW9Nld!$R(Jm+eBh5C1r!) z7;b&N&5w=Oef*HcZH8St*guT5E!f;J?auVE+kAB#!X%zw{&dl@ofxO zNj*iFe}oC!WE~$Uy~Ng_gIBiSeU-;Nf9jt?%jocNC|-W1cJ!j!L2v_=xzHP zJ8&4_893m;L?fIO*{Ye~QLx~BIN?tLQxJZRpzDQGjo?U-+$)oMhHA`s=6n|3 zNYUOLj_e|zjVVy&+tYXgf-KJBr6k}#6^JU%Q_y1E+c%Py-GtKW1TyZZAj{~f(hayqEZj}U5GtO3%KSR-sUN8Qh$k5*9qeOOGoEyN!ZH$JNSo7INm6&`Pp&k zJSo=iEV+``)=K#h2ZEE@HJP+`*ZTc1{vFXyYjuF|!kxX$x<8IZiW7tML<~qWoILZF*w(e4nPEtV+RY>HM?U?fswSgi(B`>-l z842xTCD3sm=y(bB*IftU&g__eU@W`{9rg3pjwkViobpncVyKrq@0t8m^#3GL-A7KX$uebU`^KY8IuJm@jwam$$600c@bhx zx0RO`^gdb_D3rUzT(fDE-Q?umi7CXiM@_jSwUQvAEm4rdN76~2uZv3TG_)WA>^5K2 znU9AV4fT?lk999nmbp*8l$LwMPhx-hnYoz}Sul7%C3^WLHyT5TM1z*3qWE}JgqVh>BU80g5P$%Za$ak}=A8CP`??V{PgDa{vMo0;GzXJC#{$(kK?s6fP&gzOa}`cO zgxnlo$qS5>+fgZ38FiJ6c>r3B6kOAeDhOrOD{F>q-!*9LMbNOZbf$ESh6{ubB#Sw@ zpt2LbyNfxdL`1_a9Jj}?voA}*%c>`wmqtjnw+TXxJQj&W8yXT7uq(-;j-H>`THD(~ zCMg)*D6AE;7NS7R8{xh%y4@5uwhUw)vzT6EXy&@fX(ruFsVjm?Yuw}0aM5RP577<4 z>qrg)@CootVz=(~NxJUz{_&cWH!3U%JEQ8|KVEHa%>v@j;X^s?1gb+e(HACpzk=K; zwlQ9mc<7Q*0}zti8j?4K`gG)G4+Daa^>#b~)^k}pe$EmmYgVIO%N2k= z#tTVrq>KtC?|pTRbQsfJJ*73yx<^PH9!j{fRV7!r50qp#FN-;};l zK`LVKi)MqE$ss1s17-pt{nEx8(;uJhR9Ak9ddB;ktc0&t3};T zysFCbM*QPM*A9Edt}5;OU`zOFGZ95IZLHBP0VSxd%#hgp@(Rd6k}%9UIkRg|I`bSM z!7Sx71;)U_JnTvdRU9+Vl2XglB*;ucPtW!gjr35aBDL|#Iol&Z(>*iwbhjy2R0_*1 z0g-b=Iwk%+lQZ5_RFzLf(eSfRFJ-b#O-CygFb{gZjLAm+Y(;Z|Ba=ylin_9eWM(GTMl&Yng-Zw#l{n+{@FQJM*U@Qk-*} z@kWd3$odJjionFvOm$~!TVaJZ^#%s6zcHDEZ`Z@dhD~;etYh__x^kE!xw*i^2;~>eDu>-e|`4bcmI9(M)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`jt1cyZnW_uQ zm!PFgq(iGek*TbKu!x?swzp8HxPz@euReQXt6^r3VPiSRl(M^Z2er-7(m=Y?bG<#k zm;l11*i+TX)5buF<3H;=@i*Gm^G)sVQijm_{GB9=C&{?lB1{ zkO{wr5K}RX_=MmVcxj4h3}y^X5rzIs0)n*CZ&M)vB|nYyHccc&gi0*>8Q12(otrms z0?^4br_Y@}2lNC=bbz6uNPi|Rsx;@(rc9$QMf!AS)u~NwLd7a|tJAJvx%Si=7Nya$ zXsM?4y0)xPwmh%Go!eF{-J5dD%9OON49jztP7VSr$CKe&&r<#%97i#dlKm17F`VP! zVrY^1Y1UlGu{qB;CgL~@1vDJSv5*v$rpELU$GV{HvHaOcO4OruP!?=(vbowQbGt?v zxe4J+xGU=}{#!ZX+?}8Y2Q0fe>Cv1?KliblyX#9OXDfG-9F7>ow8e`MK@EjsDj|d6gCS9{>mhI9-AF-ACJlk9n3JaSLLH-fx%%h#6=A zqIVmHz%i#Gh1@|0S#v)KLZFBMN{8KN!;y3$YKc{++C}Q6GT#%pd2&j6Cu*13i``k* zV1_SxC!vB10){|>Hz1Ile+`bPVUf$>hoWv?giv{+1)}~LEWPkxcKzZ$~K5z;Ew%;OPz?0{$%N5ACv-+%`$xITRkZusGdC$9J#g~y~dLRh1{ z_~evVZh0gAjob1w5iU`*IU}Dd5_%k+M>Nv1?~G2(<@>Sj`VmFH{x}hZo1G9dvh$kz z?moo+I_leWBcC{sb0YaDxc6ncZRiLsP3aJwz8;R_sGcJ4_F=DmXxjrbJ)i~&zw;cv zFHT_hte4L^@TiFIbMmNoe$umlSWk%kYe3(S^fK%5tMHK%8}i79J~^S!b?Unu`=-$v z(&6HKSAfti=+_v*sgHuu``*lSK#aH{;yf5k0`x){1qgnG2;HF)^RB=N5=O{3W$KN) zPBfkCpfCvE$&rParLxrUfqM2ZpcP^>AR6&#KwP4q3$2u&bxmf8uX&bZXlSI?wds8R z5>@_<*5#%(T}B8+>(dbjb0r@_0*L;bo7{TiLGMY*IK6vS5{ES$Bms#|o$AbEMwB2Y z`l@xHS^^d!W5XF1vO?@aB8vQ|JIZXaiU)GntFVN}AgE|b&|0A+=`bVR5$}iK;~?D{ zu_N-(@JH1V<6-2KAxEb0R%mkAsgwsP&YTQLkgAdjP3XnP#VI?Msv(%Jw4oK{5k|GB z)UDFA8ATpSmzLb2IQk(a;23gElr+ztyj02A4Iy*0D5XPi`4dPMOO=`7<~e)Rrf4a0 zineU0$)scmg@p)~uVf^b^i?cf1yh({`cgmT*h3?>)0C2mXP8X2IxF?FT>7!o6aJyN z$60o1l;1=nYdFQr5{Yp{MzKsah3K7Fx`t&VLm3l2Nhar{L|_nW7&!+z%j~ezVEnWW zHH*+kfbGj-`03~zF_tTSC97IdTII!(Wzheu@+>*1SGr!-E+b@$qJn|xy)KrR1+q|p zqFiGdu0;TfDS=)@y%x60C5UT@>#YbV0KE`UR=B$Lt>Y3`S;M7PiqR{ta3w%r0ZUhq z88)eE-4?j|rPu=)pa5&lYhUMzuF2;0Tj(O!S}7*k%-WRzb;T>lFl*R~X_j1&#nxaG zl-ax9^{xTYSB2!Y~Hd$Ntr=t#$2Sf!kWU&J|?9#j9{7{#!29qH6%F zB`jorYuRxjD6ywSE?J3dSgdx!5OPJXb}LKSClO79>cFTBf#DJSDGwXHxSM-r2wz8_ zp^a7`nd^C7tG)WJ2)E}eXxWlOkwmXxWX9Du!aS9 zVFTZHzyjW|h(}CfDs*^wWP2JY*7lJOy7J_=Q^hU*0*gl-Gg3pY)PA8cs!z>oQ@eWAuWmK0 zXD#bmlNwR9jtYMr*kVxiv6oG3W+VIA!nRrwYUd6>pHR^8 zTOJB8{Z;vK86)0y+@{;-P0@jQcS6N9qBYHE9%7q!=~nkH_&hm3yNxC94y(2&s<}fq zBhmj@^ch1bjz^R7+_@vEysbg+#o4=g`A#@Z7k=gk+uL^g9Rr9l;oodK5ZwC)WWU4x zZ!{}f6X$7r_9Q$2HM+uYUQg?7zlwR8TR`~2oV?>W$iF7%!&yXZkr zI?<6WZ6^~P%G`d_1f4N)im%(^DGyZDr2z0h#2e%yf8%Sg&_X?J+moMUL=M58$tzbi zWf)qPH$*- zlGrNjlecI>U1`nz1m5sxhy2|WpY;MKL^6Q^I~Cu6dMA{_OCD0VEdP6X%A-A@Td!iH zWY|Re97v(x<iI7ghOXC zDCSpE1*L!e(M6M_E@H<`P6bI4^iFMuesAX@6vcR@K_s_VZb1M}9Tz+=mo@9aG(4wt zCwOW{hZ1Y!1v!Un-0%$Np=&Z&2H=%*F^DKQm?*dggEI(gHF#>ERy8|_AUrsOFPMTj z2RS=fgu<3{Ll}fVsDn&cg-7TYRH%ebNQ4LBgElCHQ^<2Q*n>aVg=KhaG8$52J2^laWs3CBqS%*MENv<1(-cwWG3fePl3dJ z`Sgd2h(tpoL5>7VBl3vO)FC&8NZ+?f{usDP*`x!PR7CsKd)*gFq8A;~VIVdVchw__ zhqq6tlt`)weC@<}4)sr(SbIg(N+hB%F{FP?w1AX{i@H}v+W~tI!hps!d69&HqezM8 zl#8yib#Q`9B|%TR@+r!=iPIP<*dOs? zE{!OCzodK3WIz$s9F-6!;)qYL^j*<6Owp)J#m8^#I4P;pP$>k11JhH>#CfRqQP)5w z5hxw-hctU982d;R=JX*(vW)gPCcFZS(RhmLr*}(*kM+co&jfxU;xD^mj}4ef&G?YP zaa8R>lCT0D$)ZPjG9khucso%36Y8>!6hj^ENPw&8O!yZ_9mx_DsRYfWcTWL<=cq4A zwSH5?RsN)pQkhLKWm@BRPgBW(g10Hd=q6X0Ew<#7Dx*XjQ&bnzk{9`sbo7vSd?4D7?}R4QtruGF}0hOm6wWTGJvI=(fLzU)kixJS(_PCuZftj)i7{{ zFz4AVwPIE$6D6;OnAde(-D#oyc`&MlmWD8%XeS7Gb)bH=pA}P{#YI$TWuVPDP7=CV zC^|8)>489SVw*660#t%bc4J7EqdeN9KKi3T8l*xxq&qsKM!IA~b6(T-WLDRtPWq&J z*l31UYVrqQ#G_(;s9#aDG#Dj0d0018x^Y(OC!$tAWLl+N3RW`OZN(#|X(~5k`UYBx zrh7xBFwuuhK%<8+r*2xOO`~sI6Q&x+hx0e6W+teAdZ&e&sBMF&UPGuWW(;`1r-mA* zjM`*4bEbV-ZvI<}r%j-zP#UVDs%KhIs-}9XsG6#(x~i<&s;>H~uo|nfI;*r=tG0Tp zxSFfFx~sg}tG@cHz#6Q=I;_O1sxxq`$eOImx~$CFtj_wZ&>F4MI;|l9s-t?X*t%iX znyuX0tqr!V-Wsmrx;x-HuI75KlT)t$qc@gnsp$Hy@cIYp3Lj0=f}hqk@tUvtS_kv0 zs3~@)>q==Kx3BuzaEh~-<5OvDcXA|`W>-gigeGp($v_B4u;yy8iG#536LA(ht{96r z8aoNr)^+Y?ds7;6^Ja1ZhjQaau^cNqhS{;8=U^dwa4-8hF)OnTMYE;H8WroO{;&=? z>w5l{{;~_ZvT8Q5K6|sSGqgG@by(N3ORKPM_OyfWv4>NRYr3aDyR|NBvL1=DxInUO zCb0u2rPb!OX3Dgz#!atsT$_$Iahp|U~C zvPxTUTRW!WV?63*xLBaKFX6U$TTTtew;}jA_UgC>XJB31w3S;2k}Eivi>Y#_sCEje zet5HeOLjyVPDMMmkXyD%ptblavY&f78W_4m6Sqschm4xA1FJo|%e#vZwTWvptvkCz z#JpPfL=Z=~wm`PAn6z^1J)LWAY->5iYrIA*U0KN^;z23_?zUy>oyK1-o z!@99Mi6SBz*V`8bY`||o zz0ZqzVN1V83&BWhw)u+@*_#L>TR;h{z_7EvQ98GSJG}lI!XjJ*=KD8%3%l^!u+c%e zwHv?FOTJTE!&0lb4}7|A(8B+~d@Edc47|bc&~e3(wtniaINW?yOT%vq#5VkaOj@sI z#HF2!aej-!VRi^ul@3DuK~oG168yC~oV*(M4FJ}-V8z7t8@W@*Nh&wl5W(UPqE5$Ng!fckaW$bs(iH_zt3u)5B->b5I3<&tkzV1fI4@9{WcnkiIEWa;t zL31|1P{+lk@W0H%fd9vO;YffTCAHl81%C&W zX@``_SjxK$w+k!Fc~B~@EXnc1$lGAd*CV)`zA z_rh~W$8&?46)OQ3$u~WXpFkCOwQCNi&W6htY|~62ffx@&ea%? zh3QU{C@SO!P$CV{{(PEqJj^3KJo;>?rx(*BEVvnX&%z9V)-;ZuXa3GTUDBaKETEav zmFP#?jEM&cwbX}I04;uS*T6x9(~XRO;*p4icYDZK&w%>THObU2ZG6bVOkuf}^L$LZ z7gn&BM8JfRDQS?iOnksxQO9?Sb*s$Pn`ifTfinfok0O&KEzn~b#s=jOnv8$*oKCHX z$|i+Lht$wE3E6UO&)a9!4qZWb^nRYa3k|dnFFjCyz0uNSebcvpJ}rI&SlN2q(oOx7 z%wa?fRnHOycskWF->ApaEQoBN&YsDl?N`*EThmSOuS@*6AZLG}{faa7cfBOl;KOCsDJl+b8wibMlV{{(vUM(Xah{ z1>Sj1snETclW3Bfhy>y;zI~L`)mfI=EE3O(=;2SzO5q{mk2<*CMIb4Tg&S#`EG|th z9^R5z9u=J>4`9<7Bx=i~&Lwxry?udAK;y<%Aob?d6B< zkWLN{-j|j@OU1zJ##{^G-`pHmE-1`+e#CT$5zc-7y#1c!hf>h^lxM!wzgSY~WQogk zP@~OK5lKZ4e$vl)=cnD<4oyuU{o@4=#e?pE$n6SMJmvgb<)>unuChv<=!v)uP-1d` z^2`bmMxy&f$HD$>hl| zM&%{6>+mQm-wk}If+a_eCvZ;b2ysVqi7c{R+QHP;L2V@gc~KUgi2@jk?abrySnjia z?a#gAXb!b;!tP>O;c7xmiarqDrzNx@&S9(T>G;kKndLtn%pi`Cl^*bM?UnWPGWnP) zO=W%7o;|0o)(*v$YWdrgp6~EY@Xg8aWq$rg5Dq5*zb}`r+A9sxdC*b{RqpzH?zvt< z$qpVT`7iC*VbLn*Io5p=;eZ$R9(-D0e{}(xOzB= z%t4=1t@q+C-6OFL1{nzNGc+lj-Yew(I1u%f-2|0ogY7}D_u6aK>eMLd2TVC>iBVth z$R6{nKJMG-GL6_O*Vl}J1oB<-@(amM?yZ%LADTtkfkq#pw&D5kRQU}8m@NI0)s*(z z7U=DqD+a>)9!&2HDd)ifnB=Y~UjB(pH?R7rY2$mRO6ZC2D#eQBMlX+urupY? zsVeAMmro5G5P-m>K+;?5Ig@vQ3oRt`K+w~)ZWzxMvt~-%(wJ3qzV~a)#gywD3cs8{ z5C|ZhPiXWgu|(Pk`zg z+@FHXzE!|I-Nt$jDY%FhHC^I=;G~3S=ItG-%kX zP%AU%ayB(fHWctXwe9;x{=ia=a}xq$%0*C+t|w{otP40p1g$5wnjoY|krxecPPXlc z^G}2UMll*vGjNWc41pLx=Ce~`B)@TJSm3*sEl)~r&yrQ+gDGUIK-bI}B(dq{ym)=U zjZ}1_=E7e2GO(O?kj7LPj?CQi;6i1?fjaArb#zHchKv>#Mk|QJa+nev=X1pU;w!e3=1;~2a zj|HYMFvU2RN~%h-w|bkdKa)sUY`*6#lTNfCsQLsf2Q##=G5{^B?y~qG%fzG+H3<#6 z`%+5K#KV@;&$AFsjZ}3|TG_mETPwEYQaADnF)!S2>&nu*a?|zUTy@iBx7}~wh4-#?=d~BzRkppd zTk!7n_g{bm7IW`Q?qlz1L-uRgU@Qd1=mp-I7tZIOB_Z_D<;Yz6_IPyM*4D=$)6= z0BN<94%2Cz!8N)7tV0f0>X?hB8ee<4W*W?{v-Vf)t--dsY_l~6+TyI^etPbzIYtHQ zsDQnkTJ4pa9@^)2Z`Z@dhD~;etYhJj{pEWkco(d literal 0 HcmV?d00001 diff --git a/mrtg/mail-week.gif b/mrtg/mail-week.gif new file mode 100644 index 0000000000000000000000000000000000000000..89a8f2488d6bc220f172a2401c9c45a03449b400 GIT binary patch literal 7482 zcmV-A9mV2DNk%v~VORpA0OJ4v_4W0_!op-^Wd8sF0L%aY0001H0RI60009303knSe zQU*()MF0d~0T2TK3={@EEC2ui09XQ}06+x(Fvv-(y*TU5yZ>M)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`jt1cyZo>PJH`<%||j8I+z{~ z>$rSQuiK~XyZ)y(YHfQ`d4o5E0EUQ#iieAdjE{)}j+2dzaFmdhnVXoMnx34WqM@Xq zrlY5&sH>{2sjsYUlCb~>u&%VYxP3)`T!CFhymom=a653vLc?{;bk1|oa?)|sYsEru zQr1{x+&sR(!Qw>NMcO&ZwaVn}?(gt==0NE2P2W4=K5AmrVP#>wp+N)S9};}z=KWBX z>=?UR_98xvNU`D&g+1QXCPiA)+H|Iu*+?(0+`I3va@Dc5EnO&ImxKj060Dhk0&^HlBa9{6Cu-Y9O?M0~ z+`x+M`UG5-FXx_l4n3-dDf%SKho57XNm3MV=ChNRCfxy7C4%2?H6s(w z7ijB@qK``^zFfKO=W$TGoOpRS-_}mEu}dwOw%C1OOp?wxUCH)h*`rbqUKvMqpFfYM zcI%ipefW|CS9T7)e--IIy#BXVadklyn_p|8b&z+2`G?Rq+a*!YCC!x=mu2qdAmDIs zkbxaf78Y30R(r*^kw(kGRKSMTQ88Y3fxM`MbiLhRnPn5f0bGh9&X%8NCAL_gHw^wV z+8O-xv6vCO@He0`2zX>bZVaJ#%m7-cQ_qbV*63beO$lkDN|-@uWqg!9hM!gOp zn(Vu3zS&l2&f;3Yl=+gWuB1Pu>#4)*7(l?gu=c5^0l*F5r)37f{8r79)~s`II`<5- z&cFSfu)XZy3!Kk5|6Fs>kQ!^_&hm13DV&nN%rpWu6QHuvK!@tCr%)~p$E8l^YIYIm z`3u0#k~WMr**#N@v6rx}EjBvlV*U2pKI;uBimy7{aWn%dNstu`RCzP!TD?fiB48Q2954w=%@QQ(`{o^1JFRSgYNn`t>-Rz z=i!x3N9LLbFZ}St7jJwoi5{=~^2|5yyi~x$IB)K;qyGH$*k`XjbkXDWATXC3(J1SU zLvF|JvQd7T_^kNWJm3X05~H~Et5VU2XU)5)hfH{kDjCjOc zVI_{5sZtdkwI=ByN`=sooDG|BIgP2RGCPvb9*tw3LCOh_%;}?l0Q47=4ah)xj8+w& zI0nSz5G5{L!g-je9#Flf@D8$t`Z0Td)Mmo)ocTMZ<(9 zN0qqFesRj3x!j1C9J(AaM6^7(tY9y{ctOcL43>O4nYsYAOBrhPUPIL-MBaCVW;&5F z25d>*K-o65P-|On>DIo)njwph%cZQ!(^2i`GMb_aD3N3(-9T9~UP+a#7j2cuEICm* z?21b>6%d|OdH{EY>LJA{=#Orss%rj;d?_4hB8@pvGcr+D?CPw6oEA~MMQLe|pe$s2 zFtwaz=l~$oM!Q~1)-AcmW*Ae}V?!IP%K8;Us7)Bo_JlFKb;@FcqHAGI{(=p5g-f03 zv?yXli&%(71y-?w8C-1kHIFiJo``cJNyW<~?J^Cv+SP~wJ|;B0;g)YgTbg+3hB39Y~ojxdCy#9#yzc)bkXnt6L> z;R0Lu!xEM-ecwg^_Rd$nSHtg7mB2!2F;yP?>e+z*``-p$RL3kGP~~V0Ie5YsQmN+J(}!cy{-MvNX`wWV0-D4W@L5SC>oXGMo9# z@Jk+=*UaWNyZHuVezTnCOy}#xS(#^`aw)G|=RW&+&Ud!p=c26s7_PPUB0&55*%0_RBBKf8KH_XDqO z_$zXZ3PnE8Xn9h39Xe1L1aghS zVpDh1M5r7`-BW&sz<=%Ts>2(T;auXqi(PM|+hcy;CgEkBzTBw~9Ee!o48T8f@Kk#R z+Cr#dz!qtC%_a5hSomYKgrm(xwLLRlPde4>683^WWt|~3wv+2#?sosu+-YihAeDH= zW&gc*^LB?1;U0ttM@u7K~g0;V@$GZa|d~|fnFqMZ((T{!(rAPde zT#w22iPV9a-$&u}o#o0mUaP$K0qmz`+}T6XIkyIRKD)?yWn2B&OJ9@jZ92Y`eB02O zRTRNkM|_0`rs_P$7LEyqMnErQM=@j|2Urpi=zv4FZ$J=e0rYms*8|IkS9Jt2l2mYWA#k>rOScDk zW2Ygj@gr_fD%H1cM1X;8Cu{{$cv{69lVL8g1c0-oG3Qn=CFl~obbU^yc(`XBodkL; z7!(LaNPJ~5vIcc5_I5AGKj_3i{=!?a)P!occC2=TsdR&kcY<+;gzK?=TNs2GwSmFs z12Sk*xKV{v(p=JXAvGmcA5u$j6;=v09ed=3X|iHuI6^{#gJ_r>epn{RB!~58e&9BE zcjZARk~aRd9@XJk_HloCh*Y2CD7U1C{(DCrD>8=S_ioq+Y@G;DN_bM^C3(m(EO!Tf zF=%wN7KiQhg*`!u!=j44MO)-ihubuFoA^yBC?=A1UG_1E-8LM1WiGV>FRa8P@8n(G z#BZ~RNU8^eg(eiw^d%rQM!9Gq+#yVVg-rzIg9-H{nN%eyWkjWdju5qiqDsuA}@giCWH6d^rZHFaS zbO|hNm0V(ZRjkoid^wfPa(Rv@MUht+$Z=h6NmgsqL{tS^X(e0Q$C_&Mm2ZWaonll@ zXDW92jXCI3f)t#T*L=sd9aLddwUQn|XpN^xghyza#05*8`IUmQF>O^gWVDycf|wE| zi$w>OzP5zQ`Gnr75;*?T5KbYT+#*|-X`Ve$F95ZNfkRFm^(ds-i<9{&9JN;(5m8Yi zHB}-110s+o%y*h7UNM`A)ynBjNSEG4AU?S zdKp4WGw(qi#>Fcbb(}qyX6z|H;DVm=m!u{GqitaV(pGkJrcwnd$OtkLBUjFqCqgDQUGp^Q)gI_lqZ&GuZ)A!^*i<=sGa$o@ zdO9@^<5xaHGyX7RKaDx3K!d1hQZ#R&o9~NI1 zhBQ`FWWpIZ{^h4iigs5TtT+RzL6%@$!(*7btTMJE@W-HmL!)LTn8ME1_ja;_0g(f;d%R5g?v|PosNV2uRBaj&TwP1^DS}?X` zTefC4IZ!2Bq}eMZ9H`;`3}Iw)*> ziPygO%Zb=YzuH;77TgWMgo`c9!46!z9<03>bfPRwXD(cA4jghbXvF7s9oLz}g|);3 z+{81S!|aQS;`48}2t_@7Bw;MS^_#&Wh`%|}bpS~_q%&o#OT!i6y&DCH2o%EOYQ+p> z!or6S!(cf76TjL>5n>miS!zyptfY9nQ`!4_e2}tWd^f65*CQclMKpYNSuz^il00UubjWPd<|i!ZLI;#fE*HDOTwrC!dW!UbQ`S3 zGM&jGEz$dgMTNLLwI|Z1tI{1RL=mwJa01vrKPX)N9>`NWj?o=-5ULhI0{0cqG|)rx&PqdWv1y zrJ>b(rrC$%42KQDO5KGvy&LF;rLqBioUy&X{nHmb#{Uu5|Hyp|9dFU7IBi|bE(U&V zOxV=T&vIRvdNr1%E!YGk-2SZEXNMXs9VpG|-PH)ZFx<${{;kg%c-_HtppqHNy?5Fm zoOba%(q_mTD;S~Ui=tB~+qH<>g4IG3or53fTTJ+egtes-JV!(LymwvP?Mp`hYK+T$ z##RD_O}xkDND9-Hd8Hja_|64h-@JX__#I4VXyF=Mn?Ev28{WTh=-yL_;KWtp z{A}W)48nN`-UG);Eq+oVcucD);{aaW#2v^iz1!UFTk%;;py=1HK@I#7%tGklG`r+{ z&BeuNj;tseHKB&cWI+0Ry-<1P5dCcRyh=nqF0bU<$!y)86~){QQa`TZI>1Q^bBM!h z(7!+J!V&|2^n?oV;3$ z-PzU_%~gpw80VJ`A|8@<7hP0M4aA5zid;^{27Lur_?Tf{ZsR?hgT)_ee$QRn*~aYM zl8ESdX@{3MQ`w}@;P_9Vn2fXJp4K6V@qFv5=;w`IC~K(caE<0M%(X?_;pPnE>!6D! zXiYXM%UI5$I+akw2#hXHP}JVb)}Bt-j)g7-%#xLS9bD*kt(?U!8Rkxn-TDisO{Dvrh3|j_kd1?}ieXjuLymp3ecGFX?#62$PHoT#q{XpnI8BydM5fs__!~Xxi1SzQ%pO0UwS?+R`d-@8?+Z z`>ob#eR_5NQ7c{Z6A!>RKcFtynw!3gU`6oH9(DUG^7r7o?5o+w3`6tIcTbTApk)^c zLpSs85UVcqB@KoR-y)CR^K^AAI3f;sIP;OG4Q?Ok9_TO0sq-e7@C$w78m-*qEyXc~_=33Zq+5@^LfVkDn7l41 z)d}{1F81Co;fFHamS6HIRpB~-mD0EuTN&uKg^3ml;}4J4rT>j4W1XYg> zd?yz}S+Za7d)WN9uh6*<^5C$$>;BE&mv6m}BqdZ*Auk0~3gVTT`X&4A8i=RwK&AFx zB>g=)o7I2p5Ks_0z+O;K#od3`Z zsGFHKA}9k4jINd95F?*y1BQd!zM;lnmW@zPynqJDyx!$+RWP) zx5Sk&xl#)=Kw&itwv1KMxSQ2IJ5WcP8c5U+K_N-dI=F4>CCODoL^{YIUEFi@boG+W zw41okJNHGt^5<6SK={Fs{=V*@K2zl2Sxm zWHi~v{_7KBGILtM|8LBM7MvXG*jfzuOGky?@v@u+n&gTtsW zcT+|}(rgSK9=`Va^M}>&VZ;}L@{#k7C{&J*96{q~;LBykkwH##MU{kAf(8#JR-tg$ z32w^@0edL~Dp|9UCm#LC)<(s*bX>K}t+}6{eV6q%xu(}Iy~2Wt6W&eQ`SVPReRz88 z=qQDaf%*cI$!I$M$8wwjc@6;@x+R6p|M5HH^iyH5*V-R}{RFSjAGJUHU0o-|-!vS0 zDw>oAnP4Tm^829><2dSs7#(ODtP%CLAa9)u)yXg&>4x%c0_*eu5hG@nSc)~uh!I5_ z3boo`sx8brkCOCGJBgU@?%=?(dcsoTfcjJ+WC`0kDsl|I?waEv9K&hM69P}N56T4h z0guUOhjoitKNcw7@P2e4S_am5{ou#=h%JCKn~7!b5c zF1yfhuP8+<^9IndCNRsf)JRyeBf`#X>(Fv=cybZ8tfSH#zm^108BiMo^g*r;<&95N zQw0hYQTP7i@=*}?ktQ%t;!Fg){E7k&vlnBmVjxvnSjoOS*ZXs`c=*bI$4}t^(EtN- zFoviviUfcx5bA`;(*HCHDLVwBy;L&*8#IE&PtqlqwJw8G@;^6|>W;?e@;t|0T+F1y z+PK(SrjuAja7-FjM$FYpz!E8-0(>plGguQA4#m_X3UiCv0GX}w*=ScC>Qmn$iVRv2 zfn?XxMOz$)zea-G^44sMa@ko#J- zWmVTf(4%#;-N)&^c7mgE-R>`~AI2PooOR$iDT!_O=PysAk=pD_DY*IW8U{EHa@*tf zo9gA&c06%W3JCpcJ^XHb`NmmCfB@_&xI1SFZXnC?MbzH@UuYY@-fvICl|H!YO?R9} z^y;wv2PrmlWv5sZZ`ySOaFg_-HuWi@Mp17W-w2{P)YdpyULDthJ<~dDj z&;pXlp69HN{f~I!Bi;xV2RZQ>uYe_FUGo^1GXlg=hA|8m_gFYS=dI3mcH7rG*smFW>^3k&X9F)yrdIHsmV|h z0F|&TB`8TLNL=RfUxd_UFMavT0|8T*!`vk?jVa7XqOX#c^dSk1qa~OMa0i8Wb$3}H>p^S1g z3KlFUMX_Shkp7WR5tXR04pPCF-fKNDg;7aI>c^300;V%H=`GNS({$>zAR?$~P;oI- z6!g@mF@*wCeah3O7WJqU1!_u9z|xkUV5d!0Dn0eMRio;Zs$pH~IgRR3vEDSDR_!T3 z*t(Odb`_pnr7KzQ`BkXe)vI7N3|6!HSHK2Vu!9wvUkQ6y#3oj;i=~8N8T(ksMpm+c zl?4?nds)n8RM)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`pQ>cyZnW_{ZvZTo+0)wQy5ildmii|jJ`Ef3q&1u%6 zT}#L>%E+Dm`qdNKBqTF^Lwg2Y`6J-VMo^83gSjiH4w-)>8ol%Lq}Q(|VKTKCwPn;i z0;wj#Y6&4bU0dyR1xvRsx3Oha=7j|dEz78p*pkc?_v)0nLkgEcT9h#-$B&g-{Rg#} z7`{L-r~NCn*f_O9I)QeJM&V3QVbx_`3X!2>vz^Y;us-+<^!>0n2>!IlbZkL%D_ zQ;=rt_}W`C4hck)N)ibrle-8>WqC95fK7~4MhRq*H?k+Bm&lDl2ANX4nBbahw&~`Z zMyLtroOIS{r(JS(w-_~Ca>CpY1NxP*aUuIQ+WCqkNHh>uE&B83B` zCkjt}oTim>g@!7s6fO;8p_WC01nQ`)wu(fl!kp@nlL%Sqr(x7oRhptoFk0rNz*1VN zLF*CAD?O8vwF9il{sM(-r^i9GAsoKCYAu`#(}!+8@B&JH!sWV4MD zf8ND$>#l$j$vD+SxUON{HQRh|-+T+~_t^j#fPnM}RBwIt(IZg6^*Ky`z4Y^W55V=< zOEsPKwSzx9gV}Rm0E5+^k3J6JPd`5T25gW00WG@tHjKkFNXm#u6DvInOSDo$@bWdS zxsfI`3*18lF)_g{1yF($)Z4)Zn7}Eh4t8~t9P0v;LA!zQ5+6LF3RlQNJ*2ROFpQxL z)AYZAt;S5uDB%ou$U{55uuNyll{0+g4kFefHAqaN5|_xtCOVOc19+kor%1&rTJefl z%%c7lx5&jVdhv^33}Y9gD8@1}QDXz*SP$2DmrR+ecWLB?>)1%gH!v$XZi^N}5|y`> zX{ve7OWw^iNI>B+Pms$?!W{!yBh(GyhpLie9VaP_MP@8cH6)rEDalFOxG`36RL8ee zcECdx!FYX4?SzJDb8|+^PJ>Fr#aKf&ULy| zo$zdDJl`qLYdXT4ZkVS&>)A~MrY@7p9Hq$|xymG<@|CdM8zP^lJXNx?m5m%G#r}$E zN(2%NlX@(TKo>DWx(V~6bjTL09A}4PzEP4OO(`5Ma;~w#C6uVz=s-&e(IFhPq7g-C zqjVZHoLZEpsLBm|^wUzIJ~WZHWLG4&0Zf(B(LXFLmF^5-Qc$AQsaTb$N}}qw-Jgi|CTiC`b*0GFztYjlgS;$&;vgy1hI5m5K%M{?A`3%ryE89=A`T&xb6h>3C zszQ+cO*1~j*h}+husss=sA{dHT<5w_y88CFfZS_vwYn#}itKiJ#VsI*{?^gBW`niR zb?H=I+q2tYCbj>}s3xx(U995ex=q>3;i5)TIrJ5+RK2Z3{peh{rgFH-1#WNQE8pFM zgDICWYJJ3OU9-iPuP~L?Cc7(4wJ~ipYU53HK<8E5`Sb>;6>E;p#7i9pm8k@Fs@MXC zVE09OWGRC*s_3SY>r3EV;Dp8#y%Dz zj%y5A&Z@@9+U#tAG^+{FD!Iv>WpX@oJPykG^N|3((rhuDVUVumBDuM4es&|ZzC>q2 zAsaDGv8>(54Y; zeveSab~?amhbq4b9BntoU1|5Q&p){KL}gPto{5+x&&H#l-wK4A(tD>5c5lA%z3&Gy zFC4a;ce-mAp(j*GM7$ff?<#zdKto}*<`&h0*vEwFJm}g8*ugvkE+5(@F5X39<{8kt zOf#AsiDW#v%2&?vmb?7rFps$yQ!aBX_OE{>j=0WuZj$~8eV_3SOi;RPF&_NL?g@Q$xL%E~S! zwJ%;0Hzd5|HD7qt@xACuh&#_mPx?V<;q<6az3Nxb`qsPt^{|h<>}OB=+S~s2xX-=r zchCFY`~LU955Dk+PyFH=pY=0HzVesP{N_9V`OuHP^ruh#>W4t|rO&?h;eh?^d;j}U z=sx(zPkuC(|NQ9pV3y&b^)4;G^XZR2CA)7VT>jcW#Z{NT{%1&k#!YEQIB|LU_DlOG zZ4gHVActKJ614i!4-&d1Y0W=yp2PegN2h&9i_H$B8ruh+G(fq&SUv z*l*7$jp%|dclc1}b%^N|gupmMB87@fh>IuYaH;rQ;kZWQXp8cuhPjB2%UFjnNRNR? zh|!pi_lS+v=!u^=irI)UkbrJs$c>JeCGuE`h#-sWNGR<%j0E`xRh5tmc?b;Ikb=Th zUKo*V&{q^GOU(EL+o+HG=!bvEkERHXCy9~>1XXmlk=7`1tN4*A$qN^Wk<8(eL^V?H z_-Ac4hm}}{IQca?SzRy*iDLNvB{T_!At`9ic!~J9k|ZgWCOL&HnUA_sl$9Y>5qUgM zcv^tQi$NKQLzy)FqLF#kV0v&&B3F)VSe6iTmM@u>9Ek;NNsO6Tl?A7Puo#tAd6j=T zl~h@gSP2w%g_b1Km60-&NC^x#372(om~)w!J(-k-XGrx|kgs@+y6~8g`7v_&6aYe* zjVT1Gb7iokR7}^4e$$lW@swW)kTnUIeMy_Osh6C&DUvCg$fcII31H@Ej0p69NaBCE zDHop^F^4%im63tISyBh-cuQHBi{P2bc@lc|5^6)5aA=wyh?fQFmp?F)#~GW{IGg49 zkFr^k$C)#-6aqN}<}u4%vyI7Xx0lxn|52o^C0W1Ue}D2_LZ4Uy3tR z#VDcQ_?9P1C*PGh`}H&*>R*`XlX7TzbjX+W7NG*Ck{X(!xp|=^N}s=(8SV+9+<~LC z^fXE;qS3jTU-gSKiXb-Xq&MneQL3XQ%A*oinU0yIce17WRW?uxFjBfU2qk`qz(;zB z2SSRWMhcZ7YM$rGo_C6;TLl>T)uQgEU|-stM@3Q#6P!*6j%LaxgabVt#$O9I75^z+ zfC;CE(4h6$sQ%<4XLZIMhWcS?qo5n=mze5)1e2&7ctNh|33ZyJQ>v%^NTfx&r-PZH z8}?b23aMp=Hld?toA8{f3XeI|kE$6{s|u@;V4a-m94@tCpz5iU%A0G$kpcQEnHgio zxtEIB0gDM0%Q_cL#DBlN$G`$x5BGN~=f8t@4VVRhg^Mx?kf8 zJ%}@1=PGcX>Q>!Ynl|aJZUSa_bsMBpIK65NXZ8x{YO3qkcQISgEgEL)GGiOAVrWC^$hwGvktGIMgsr1vdzcy6b*{h(dV4I7G zatpVo1g|g4vTZxJbi2CuYPYg8v(aO5>qZ$O^<+t*xkUSco$I+?0dP@3aQ-SGpldFv z8>d)Gyx*`O(E|nS!*P+jJ6G@-&6}xpTf0I)o-&KO-aEeHOTOiMz7(1g6j!gIyT0%K zYH-S$hX<#qRp5$tO1p-@tk8Qo6DK`4ka5%NxHtg7JYYW;M;`!8z>omI^zpbo;J-QW zAl*a2cGf+iOThe-ST9~uW+)&N6$1k;-dWR*%8NZ~ZluT8J zHC%^QUZTk;_IEZCzn}cYHDV-w3?#}pST4qkk9T%fnyrnDkf^%Jom|P)2+FJs%Zg0D zULnh!Y{?w*4#3>VlW@#=S + + +terror.hungry.com Sendmail send/receive Statistics + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +terror.hungry.com Sendmail Statistics

+

+The statistics were last updated Wednesday, 11 March 1998 at 2:00 +,
+at which time 'localhost' had been up for Thu Jan 1 09:00:10 1998. + +
+`Daily' Graph (5 Minute Average)
+ + + + + + + + + + + + + + + + + + + + + + + +
Max Incoming:28.0 messages + Average Incoming:3.0 messages + Current Incoming:0.0 messages +
Max Outgoing:154.0 messages + Average Outgoing:16.0 messages + Current Outgoing:0.0 messages +
+ +
+`Weekly' Graph (30 Minute Average)
+ + + + + + + + + + + + + + + + + + + + + + + +
Max Incoming:41.0 messages + Average Incoming:2.0 messages + Current Incoming:2.0 messages +
Max Outgoing:164.0 messages + Average Outgoing:12.0 messages + Current Outgoing:7.0 messages +
+ +
+`Monthly' Graph (2 Hour Average)
+ + + + + + + + + + + + + + + + + + + + + + + +
Max Incoming:41.0 messages + Average Incoming:2.0 messages + Current Incoming:0.0 messages +
Max Outgoing:332.0 messages + Average Outgoing:9.0 messages + Current Outgoing:6.0 messages +
+ +
+`Yearly' Graph (1 Day Average)
+ + + + + + + + + + + + + + + + + + + + + + + +
Max Incoming:243.0 messages + Average Incoming:1.0 messages + Current Incoming:1.0 messages +
Max Outgoing:974.0 messages + Average Outgoing:8.0 messages + Current Outgoing:13.0 messages +
+ +

+ + + + + + + + +
+ GREEN ###Incoming Traffic in Bytes per Second
+ BLUE ###Outgoing Traffic in Bytes per Second
+ DARK GREEN###Maximal 5 Minute Incoming Traffic
+ MAGENTA###Maximal 5 Minute Outgoing Traffic

+ + + + + + + +
+ + + + + + +
+ 2.5.1-1997/10/24 + Tobias Oetiker + <oetiker@ee.ethz.ch> + and Dave Rand <dlr@bungi.com> +
+ + diff --git a/mrtg/mail.log b/mrtg/mail.log new file mode 100644 index 0000000000..7df86b4993 --- /dev/null +++ b/mrtg/mail.log @@ -0,0 +1,2535 @@ +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 diff --git a/mrtg/mailstats b/mrtg/mailstats new file mode 100755 index 0000000000..0860985a21 --- /dev/null +++ b/mrtg/mailstats @@ -0,0 +1,94 @@ +#!/usr/local/bin/perl -w +# +# Author: Petter Reinholdtsen +# Date: 1997-07-09 +# The original was written by Rachel Polanskis +# +# 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) = ; + 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 () { + 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"; +} diff --git a/mrtg/mq-day.gif b/mrtg/mq-day.gif new file mode 100644 index 0000000000000000000000000000000000000000..648c5cae2b81af286b79037cfa909ac0750a00d1 GIT binary patch literal 3755 zcmV;c4pi|+Nk%v~VORpA0OJ4v_4W0_!op-^Wd8sF0L%aY0001H0RI6000930W&le7 zJ^*KcPv8JR05AY%089WlEC2ui09XQ}06+x(Fvv-(y*TU5yZ>M)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`k&X;0oYx_%pW>Jf^ zP@y%4+MYf9vM*XhixPbd+;uS_#*h9ULo%F*E2Bw}BRi%%DH0;fl_*`3YxpI}L4-1K zeoHlKNvk3og&^Yj69>_rwJHuFnzZQBqvCETC3J|VQK;cQF@kE9kWQdX3i7!5RqWTZ zQ63>h%Qn(fgh6QnAsbd+8hU2t0m6F()-shjVYaMElH<$3hzSE$++*Y4!;E7_9$Zp# zWy*#vXU6z=v0x9=;oA=~bA z*00>nf|Dn{tbB5F=F5>s*X8*5=jYO$Pq)s!@b&H9yVrgr-bm^^@zU$HmmB);_d9~a zpHDxBe9Z1{7q8FXe*gafUj7r7P5PDPS$PMBr{H+sY3JY#)h#GocJ5V3;e`!am?4G; zf+nG65ssH1aRvrR-+d;gh!%>`jkpOLe4W9U6C2jpA$B%?=plnQg2$tdIQIA;hd}x` zVUCLppd^7LzPH|mGOec9jK|DFgq0RTG=^E2}?d5e3K|^NbWj#ni0*IhDIvsr2HZ3k8wo~ ziR6(&YS<}xnR*&3kw2Eo>8P6~Xew{35@BgRVbT#*98SSS>8<9lSf)V*>J)1awF#Z##s>g{nMPUs?A zzw$XNILaa`uN2CL`D!}t5=yKc@y_dS6ZJCrVu|3AYw)-TbF1o5o|J|Z9&c^d%C`<3 zg-W@iVod76Ayq`NxrL>x*}7ds`>eE%_Vw>S{jMBoS4r^@F@!$Z+blx)y6i^FI`4#~BwbuF_L4?cb;*@8@%_TX%iOfI;7!2Vr4M`zWsvPxQUAAx7tP*vT5fYC%Ox#83_I zvK9Uf*=EBb?#|*dFr!ETNi+*I)F9ZvAc-xx}^*Bd9 zG7*m&gJPYSmAOk`Pky=JUK9BC4ZEg$#9F4)hMFH@C>^Ye$7RAX;dNNv{>?9~h zDaulY@|2`Rr72U%%2m3O6cSXWEL%CtSJLv9w#;QMcZo}0>av%>{G~8``G#T2Pmwp6 zq$K3{M>_7&D@#lwb)4BpBR;c^)NJOc1i33hiZE^~Q^Xbhu*OHKD3ZhZ=Ha$BPCAs+ zoF+nN`fv!VYudA#y}h3dy729%%@y{9&@RRLD;DvIIS<%?ioF!ZP8Vo}JHOy_wk1CIPgj{mp2* zM^Ahyma<93=WB`R*xJsvvPFfhWixA4(h4@Ut^uyRR*Ra}PS2;v1qL#^{wZ7>ptiZP zA#M(onUYE}hpX2s8!7sCC+=?7l-}Jcc*lFn@G6SDsWh)vJE`9GnzFC#MQ?n|D_>8# zm%jK-Z+$^|U;XBHzWxm`fCp^f{dV`g1{PCps0)b}V)VJtg^hG^z~DwW7@iQ0Fl#29 zOyiy-sJhK9W@F1l&F+@Oi?yw6S6t%WvX-+s)bP(_JSh%m!NcabusJhKW;8LkevFo3vS}dyuY^#AP>^Wog&d5%-9JIjfW;^@Y(2lmWr%ml@Tl?DB z&bGF<&FyY```h3Sx46em?sA*^+~`iXy4M};8Myo1@Q$~<=S}Z=+xy=5&bPipkY{E4 z``?n}GQbB;@Eg*(;0RCnJP)q$hC4jZT>W#kbnNho&#S`h-Kxf?@n?&BynOw(q{Itt zX-F#@%O4NKmKmO7B^SBLL(U`2aXa%R$GqmdH8JLn-P!(sqdevOO0)`DJ`Rez1*91j zEzngfbc6Fe#*J01A})57q&Tc82PKxxd28gYd;R4qjyh&^-svgkgDF{5LfU1xblGkx-+O3e%Vzs?DZ!fLbmnIGpM-=QJ0z8Y8Ja{L&+{k1%HoL^h6+hqlZt^bJ zxnITdtbid?s3M8Sf8*zp-&xbWDDZCx85B@u&>0E;oV=#->pw{R;c?z|!SCIuP@Zn- zyJ7U*d?FyA4?P6RgC4vc)M;&=-J7<1w~( zHQ6VCx3_%>cyroETcGn&>r{UEfPVPr2 z1?XHU$bbmQdM>DdFX(`(1Azh2d;PJ2qUV7t0)jLMIbCCZanOM}*fu*n(NQj?Oh0S+`yk}ag_ZH&RQJ#l+ zH>G*qFcjdhdQ~Tj{s4#($cm~kP!OXOu4sqCMU0fdi!~^PPl$vocw}k_iTc!xNvMpZ zGcnRwRfOYP#dmTQI8aY86*w4sMW~JYCx7O6U4xd6!X<>jHHYpzM-lK>h1J1dEl1SyaQ$bH$^lNp$79~qQhIFyQagxqMA0D+7? z$dXC9l!EAzFlm%B8Iw-=WKp@1Q;BR<$(2Oll|AQgZwZ$|AeT^wmSSm^IhU4AxtC=b zm`7=VN7RFJxs`UAQ}yU{ZFy&PnV90Zm{#bM?uQEyDQNwumru!*P)L@8$(MlnnSvRR zYk88C2|w?bkIgWD$ODv+X?K#DilV=iIw))n0EG<&Z&^zuyc(`oTKTNPPVz1 z8l_M=rAHd1_L+ilb|3v#qg>ijy0WER8m9jNrr_YDm}I8Ql54uAX(YER{r5j_I%!WT zqqqj0J}M>uSErVFJzb@zCW)p65vPG#o6)mqx4ERf(SLk4XiZvav$hhCIubqFn&~*H znK?bg=4#1RX>J=wsfO8c{Xoq^Ksw$?+DlcTZtj-E3-}kK2S|5DCZq|CO*qW`{ Vx~<&Wt={^r;2N&tx@{2v06SkSZ{`31 literal 0 HcmV?d00001 diff --git a/mrtg/mq-month.gif b/mrtg/mq-month.gif new file mode 100644 index 0000000000000000000000000000000000000000..f803686425a119fdc8dd624f8e246c1b58bd8e4c GIT binary patch literal 4436 zcmV-a5v%S;Nk%v~VORpA0OJ4v_4W0_!op-^Wd8sF0L%aY0001H0RI6000930W&le7 zJ^*KcPv8JR05AY%089WlEC2ui09XQ}06+x(Fvv-(y*TU5yZ>M)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`k&X;0oYx_% zsF95#{(o8PJm1losOJ-HC`>fL)ZY(tJadqB-0HwoKrdEI`6M0N4D0|lx&K7>!K zkD-2k3G?z6u23d)DT!i9+F1^lIAIe0+YrE1*M)}^v+Npb>>|Zlxhi&>*v8wF3soMg z$gA5My~pYZ{aKDv<=$H9R%@s&L)w1&9%+RA(*TG;azkHtwQfJvmu2Q0=BhhLk(=I% z53aCELH9TyOK*igj`cM$b^i2Id7_=?+<0yLRa;nW)#h4$_pK#WPfFzW*I>wjcOiX( z;nSL6;_V=pFn&Q)*;@~8#a&}iJcl586Jh0sN-dp{iY%CglH(^ka?;}*II5?_07Me_ zPC8zoWX2e%otDx{O}3FFlF%p#q?A@_=@5+4 zgI*70BGTz0pBfS>CIQj}nvq#;dg-dHdW0xc{V|v7fvwiss*4GU#NijH<{{Cek}el) zYP6;&ppeI26PT$K{wAkojOJCOs;$&2imN~i-2+aq2F7u1wcyJ1EjeW!SE>=2@-pf{ z=O(o7An#7mAFs-`i)}d}dIKCRvib@sq^AsPOR?b=%mZ~DjoZ~jy&%wUw}BWe@eT-U zq;L)ugXrvy+)7Juq(X$HX|lRx46-%LYHVR|jWO)UfY25wtwSca$V9ojZr4|~vvoBu zFSh+W$5cXNLk+ALZ|obgd&npXy}+&na-8`njT?Bx@b;a8A?KT6ZI9H9@mgMo=iYyW z6&(uN`*AWHQ>J*9HFAeO?6J31GhDV254B}A6_@PwO=W7s(M=>DF7mc9YZabZ!<{*Ut7TmfO01GSi5tx@^??BCm=j??n!dN@%X~Sire2KHS7v0YiQ=<3! z;^jN`Mx^ZSkVVFP@V`KE;ha=6GQK~`bw)xaZ$NtY-&Yh@s1przPOU|Gly=HPi zPL-w_>6(}XCrCj+MX-Vx%%BDha={IH@Pi<%MF)v>r6nOSgeXj*3UM$(`7wh@%i9DD zae|T>+VF-r%%Kejpu-;e@P|MQq7a8j#3CB;h)7JL5|_xtCW3*7PK=@yrhZ5>(Nbd=$H>P* zbdg-rk=+-8@y0*)@sLCrRP_XDIm+!Zer;S|BzrMO=#edLjKibMK=VKoI?x}5M5HL` zV907TE0gF-qZ5+!q!|hje*KG@qt-ObU(xcGJiMhXcUj9`>e83I{G~91NlaiGbC}00 zCNh_)%w{I@naqTyGowjOW#)34*p#L=tJ%v&Xwyn)%%dZ-Xe?7r(vtORARTEZzB{H; zoM0s9DCgORQuczK$idGbNA^g1`g0nABHrW{_|8p^^9_}p3)4zQ!fGV+Grj4|g8oEy zMk2J36rud*pL9pbje<`x76RWs)%7}!j)kMVu%}^cBe<5j^rZuB8zx7JhEA4H69iOe zJp5I&$4wVw2sJWo2E;3rqknz)vKm)4LcuFzu z+!cLYIF=p`GTwBDXfh>aQZ>6q!|=zXlC{ZWb%74cuw`Eo0$WT; zx>&nRlvG2-81BI06_f^bMh{x8QUse$!PJ8zUP+FI5Q|%-YEmd=;hGh`{)M5;dRDc` zUCr;LGTooDXSDW7En29{pZgFOu&sSsGsgQ#P<&TJ3$l=34uC7Rb+>WbQLS&L*PoW@ z4ZFLI-P*K^6kL3cVea+fWwxN5kx7!Kq{I>RC;@2`~_~IH1)2#YIY8YBX9PP;?h;NHdrbrPsWcl%SFn!phc6x~c^3c6>J7?#g8TM=O&J0pB^`d3mJR z<1$vBw%QPs?+{>2+BeW{9(1O|thln-l__umVI8->Jq&Skp}k8UDTqUpe8XKM4%gQT(_#3_Vu45|;SDYi1f`GT;n zHEu!SP{k@@8=x74DPLHc7qwKn2}qU=fOEHM-t|qkw)sI-l8ZL^OlR1AQ=L%5g=D*>|m7ET9Zx>MN9xpG|i<@(wBfaAx$2!10(Q#{N9OGzD`=PYJ_O`qI z?QoB~+~-dBy4(Hkc+b1u_s;je`~B~L54_+9Px!(c{_u!Tyy6!h_Zc|;@sN+aOn9scCLvVJrd;as|={)F1Px_3AzVxV1{WVUn`qsNX6|8^d%W;nM*W3Q~R)l9X zZs{g21x)9-55Dku5PRj(N#qOE$Eb&|QClOW-#WUp(zESTUOV*LSloShvkzP5o7DLW z4W~ij+I{c;6a4p_7xWpe>#g_H`gy*7Y#&WF_5OEx7t1&QJkh_4b1To$)CXz$H%k1M z3&w#;;`e@WHGcsZe-7AD3`vhdc0w@N$M|2tsNo9L=InK4@p{H;5@zh=f38 zIWvWokbnP|hYEF0aOQ{a0EvirgygqV{*1^+j;It~6N!l^YJwPw8Z?U8fm)iF1AzE4 zKe{enV7zEaM2iRzjk+qJCz>5C22q)%= zbZCXNmyHNnj}qx06qyaAsE~$mVH&9fV%U2h2Ydzzin+LrGRc82nTZjIZj07v1XhDh zKy!0aa>+-BD;ScVGm?i;hONoC1X^VGAlLLb?-^dM9 zsck|DhS~^|UE!2&W|W5TN9{%sUwMtEm}_;21ZXLIPzi%K<7+^WluF5yAPAC`n3r>z z3kvB%_y)SeTXhk?e+A404fM0+tonnIl7)M{qH- z1s0*XDuw1Yr1?0CSs$F1YAp4DocS4;^_p^NS@JSACK3hB8CmaUWyE=q&o*hWF;FhE znpRnrKL{%$`Gj(#o<{y*JDQmxlBpHrIf;nzop&{DF{y_j5*fhNmV^K^t+|QS#*gJT zHkNTMg*KIau|3X(m!@M_17RJp<{$o<5t?y2C?aQn0+1VLn|k)4_=Z{Sb%?SSpV66W z{i!_}x?hsPpP81N;-WECwwQq;qQP=}R9AcJAfI5im`LUbafUFP0HWR1n-vN+e6uSp zlVQaONX}+xHhPnx;9t^_2D3q+1=^Uw=_^0Ul9A$)s^FzqGdDM|HNoR*Ndr29Q(s|2 zT&-bP_pysKie@V6HXE7{nV>zZ@lk@pqjUI^GZ&O*_%UJAAPOO$5+xY;c0H;YJX-b} zZjq;X*{23k9RAIiFlCfyPGd`aRk8s+ZhmoH=Q8q#vS(-W!g5ZC^HmJQCeZNXKY03n8 zL1r7`AXXMpG3q(b+942lk1nT|C~u~f9d6n+u*waICL4)Ds8ku3h{A)V^N7>)6`6UDMT4(Im={G+te`57 zDY%{xON&caJ1JtJjLpv=^AJ{))3*DY8d3t8!3i@iC!m z2{ucitY1<`JJxT#G^GNn84wHSK|`;={KJB0Pd79hg~ZBVwog5hBP&F_0r& z*%}0o>$OPRmypSV1i7k3N!-+M+FzkCR%n2lXb%yH0I!AV6_`_9@!$iDGzjsD99EVVBs7CB2R)=y! z%#jFIhB~~%OPs?~+;uYC#ZmmlUUG7k5X8vCRFSa8SxitNr^bH?aQ|n8J^{zUCdVv% z!%1w%c!tM_io|=|a&g?oR}3V4yeEGAz<|66Xe`2xj7W|A$dW8Zkvz$koI)CWz<8Rx a$(-EDp8Uz69Ll0R%A{P%ro49%00292lzH|5 literal 0 HcmV?d00001 diff --git a/mrtg/mq-week.gif b/mrtg/mq-week.gif new file mode 100644 index 0000000000000000000000000000000000000000..28f794bc6ceb8158b4627f926802519023372c8a GIT binary patch literal 3415 zcmV-d4XE-*Nk%v~VORpA0OJ4v_4W0_!op-^Wd8sF0L%aY0001H0RI6000930YyeRJ zLjZH2R{#KD05t$+080QqEC2ui09XQ}06+x(Fvv-(y*TU5yZ>M)j$~<`XsWJk>%MR- zQ-TECc&_h!@BhG{a7Zi~kI1BQ$!t2G(5Q4uty-@DK`k&X;0oYx_%!B|V0zDD(16jq!^Okd z+S}YW#m9`m%R0^7I^*M1*rk5yUG4CA?!-LF$UgIbWRqLwJNb0h`5Q>E;2Tx;oPYyh z?-(mb;2tu3_$uL#eB}rNoFmYn$BF(QL)H-)YY4`EPo9mb27u)mmS~D>bkea_ygLOJ z%9+`OCljAbYF+`VBqxHCeF_q7Bh-*Xh~0FOoVtc;Oe7fxF2#bNX%SWlpGvV<4{TV8 zR?}MYY87cEr840pv(qZLtv1fH(9c3O(8gS`Z{E}*Hd?&D!zO4D~?KB(n;MhN_c!Ab(xZv*GxmOVnKDjgSEvu3L9^U)wbEwtW za(SxzzV+wt567>MaCydRWd4=ifCLt3pl|{nsNjMOHt0`+McFr>gq}?3;Ds1w$RLE= zpkvx?e}O2Qh_vC+TYe$t2G=zjw%Fo{J0v5OE-J3ZqKh~>*c4?w@EAyq=S^rKeCb)k zoQc!bN8(ON%J*T93SATrkp3*ENRC)8=*x^t__*W{9ByMJJz17X;FeQ(IpQ9M*?44Y zP1^J&baP6FWJzs2k`qWVcA1HPMuZumkY>aOpb%qLWhNt@nYHLzrGe#MplxcE4UCU6 zlxa7Za)zC5v2oPSE3QZi(PUg|21TQiK4xEtu&x2}l zS*cD`?54tX3Tk1h{y8CD7(*ggs9uRAgix@g{-7qZ+}b7_mF9Rz#IYldYmBKz%35Nq z>#FOmyUx8zX|q+jsta4>cB}6p%C5*Jz2RQE@4zDU>*l=0$$4nB+J*XVyAU&3Cw1&T zEHO^j^@i)Whbk%WC@QUMN?$5%_esc|bZqNuD$DtCDJU1RF~Ky~Y_l#i->mb_Jj0Q5 z&p-z)G!s9+nV2Z%4XyOj4HkV-$SW23vefC6Z1vSxXRY*wdY`2}Z*KWrx_t*a>T&2KF=Phb>;C7?y69(%oxDbJtn(rZfcj#~&g;QH`ypPiv z`9V?0LfPN`l1wdx(=_5e_~%y`+>kJdi|IM&sFOKFT@=|BOzGN)3+Kch!z;P%cFwNt z;ZWi;<)?>DBRoDWOL=4J$OFE66Wihr1m}N79rZu9pb<^=5)y{}_S$!!{rB8^?LGJ4 zk8ghY=##Jh`Rk|8{`>C7-~RmY(=UJh_}{O;{rsCR{{H#fQ~v-+!1*NYd6l|b!|pUW ziaD=#5rf>U>QOo0;RbjI14iSL_c=6G@E5Sl)#*4$!XtR_gPmiR-2%2i-96Arw1Z&- zA!sp8jm224&;+V{kgWxVa2S|t!Ujv2H-zM=hcdEZj8NsJAChi_C1jNpr%1&rTJefl z%%c7lx2VNl+3O9$TGg8n_6NlbFAv4D;28HdLm9phD({J*%O==H=Gm(e*sEI{sm4d@ ztxPl53!oqixR3u0@Q{N9C%SIz_O;&l=(yz?lC=QoJATlSFO49DHh~9ratw>&sF-fKYX0tIsWo! zl0dp|dYUwfM$MT$OtwT%dV1ec1c}j1zOSU4JZVNBiPDu`)TM}QsY%P{QJAW9rv0;; z9+zc>SSnO9y<6x$Q<+U)jzyY30IFz&s<(!Uqo{scVxx?L)KPw=A}Pt`c(h6ddQOUs zZ?vTvY5@RW;Z+8&3aaA8Osr-Dw*Da*d|2BP>KTx?p;|3$Og7u{*z#4yeFJJ!{%gkE`c-=p zy)AN@``p?}L%Pm=ZFL(v6f-VnJk;fnv%I68uR>J2=yk(#P0QZ)B0>xBjjw#?OW*q1 z_rCbeuYUK--~RgdzW@%ffCo(A0vq_i2u`qq7tG)WJNUu%oq>cWOyLS!_`(>@u!c9x z;SPH^1nYILh(|n!5R>@CD7J!$Q_SKP6Rnpnj+5&q{7)*|F^us^5u2B3STx@(a5|}KmOlypW41Ec&p;EM<@mhV z462H+T25!2BYj*tD=JC{RpW@ftk__v8PUJNS3^eU&_*}&(4gL#WUv~}OwZNS+C%*?x`vH(WrKI&DJ4kSCo3$htbcED+FX#LQ35>!v?a;B5ip8 zWIq6hu6yPoJ6&rV&fLzOt;g*`JYhP|o8EIj(~a+eeFKG^zEz>6O!0~{G^h{HIH3b; zXjw!0;0mX7UR9oJJ1a391dX`39nFhRd%Q9yg!z|ee(L^a-`wI9tX#V#4W^Box!T>v z^>$glbd+1UhC_EaEoDCKk`w#q`^q`Yp;-t{L%GjbU(~hIM9#CwsMVT6JJRE6^fqrZ z>3D6q)3J>3y0_C9RS1@UB+@#mavjhA$gvNM9QQ!jJnU03;t}g2)o7c%>KymEKDkKw z%3J>On9n?`?ujn0kSgj3eLLGp9{D93JmF7Ay|1GVY$4PA?y}jpS&ip)GJ_p-vQORN zJ^y%rFQGlyLdxzzI-$!@?2zSGfEe;q60Ek#bm4DPGdfumWq?Ueh5PpR>XH0h` zO4nr)_ipM(2U)~J8F&P|6N4IvO&n--zhHA0sC}Ntd^ki+VFrOIcmop1a;-OJtgsbo z5`L5cco8y$=XHXrGl9Q1e7Hb<6ZZ>`utDg8d_uQ6tR_sIhj>Y~fsl7}TG$ASu!Gn_ zgR4hHZ|H_-CWIwOgjmRe`?q+I&@1jHXvZW+)Q_>G1zlQHR$rQwoV zb%fn`YXk|DhscctsFLr*lPsD3kU7~PIBAm1aEJY-lS|2z`dD=FSdFHrl>QfsHo06U64nJ#i27AcvQxi5g}CbI-BUe%d{`I!S5M6`fi z@I;!MxgDPQUQqdw(Pd*0rHiO(g+^k2x)prLbyu|6RqByPu>~OK<}9u0SSSLUuDM6K zsa&f`8oBwKPl#lplOV^$(%$}e+F*`Dx;AT=2PVf0y__IaQ9nV + + +terror.hungry.com Sendmail MailQueue Statistics + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

terror.hungry.com Sendmail MailQueue Statistics

+

+The statistics were last updated Wednesday, 11 March 1998 at 2:00 +,
+at which time 'terror.hungry.com' had been up for 1. + +
+`Daily' Graph (5 Minute Average)
+ + + + + + + + + + + + + +
Max Mailq:377.0 Mailq + Average Mailq:261.0 Mailq + Current Mailq:207.0 Mailq +
+ +
+`Weekly' Graph (30 Minute Average)
+ + + + + + + + + + + + + +
Max Mailq:374.0 Mailq + Average Mailq:188.0 Mailq + Current Mailq:192.0 Mailq +
+ +
+`Monthly' Graph (2 Hour Average)
+ + + + + + + + + + + + + +
Max Mailq:378.0 Mailq + Average Mailq:90.0 Mailq + Current Mailq:203.0 Mailq +
+ +

+ + + + +
+ BLUE ###Outgoing Traffic in Bytes per Second
+ MAGENTA###Maximal 5 Minute Outgoing Traffic

+ + + + + + + +
+ + + + + + +
+ 2.5.1-1997/10/24 + Tobias Oetiker + <oetiker@ee.ethz.ch> + and Dave Rand <dlr@bungi.com> +
+ + diff --git a/mrtg/mq.log b/mrtg/mq.log new file mode 100644 index 0000000000..dfa0237316 --- /dev/null +++ b/mrtg/mq.log @@ -0,0 +1,2535 @@ +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 diff --git a/mrtg/mqueue b/mrtg/mqueue new file mode 100755 index 0000000000..0666b16e3e --- /dev/null +++ b/mrtg/mqueue @@ -0,0 +1,15 @@ +#!/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"; diff --git a/mrtg/mrtg.conf b/mrtg/mrtg.conf new file mode 100644 index 0000000000..5fc68b173b --- /dev/null +++ b/mrtg/mrtg.conf @@ -0,0 +1,37 @@ +# +# 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 +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]:

terror.hungry.com Sendmail MailQueue Statistics

+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]: diff --git a/mrtg/mrtg.ok b/mrtg/mrtg.ok new file mode 100644 index 0000000000..e69de29bb2 diff --git a/perl/aliases2html-1.0.tar.gz b/perl/aliases2html-1.0.tar.gz new file mode 100644 index 0000000000000000000000000000000000000000..58c244f1409f47d0fe3d6c5c5b14e68867da4410 GIT binary patch literal 1194 zcmV;b1XcSViwFR|Sa&l31MOCQZ`wu}&%gLnJSA=f9l^MTL;(kdHDp1e>6E0CrqV|l|r0tDIeQyA#=fji3Np-TV6(`lce({_^ zU!}jYG6e@6Dbhc5G=Q_ghao!2U3jN&b2s=ppM84lisUi1e)MFgrqh?zO8Tgz zLWe*eVxI;>d8%n5cBE2DR1%9al~Kf|epIvbLLNfZA!3^C=q&tf*8WER=sHVL zJ+kj**^a3?6wbxg9P3LS8V@oJ`5GrNoYO?LrHz@p#t!U+}8emTu71%$S-9ky#K3{de z{8aDC*XEnL?c_Q~C0QOvp{O}1)WCnIWT+6AV-aHEkg}u!nL$QDLYhcn67wjEmyQ|w ziCGMpP*01fU6T&ypWs||LpqI?0qN>+m8nX+kid zt~*}AKikjl2!{4Kll@Yj`)R~D$@(o&u{`ijG7jk?eCV7T4ze zyskgLcd7aMS~-igv$Fo{ABYA91_lNO1_lNO1_lNO1_lNO1_lNO1_lNO2LBuU1y-O9 Iwg4yq0Fp*vi~s-t literal 0 HcmV?d00001 diff --git a/perl/aliases2html-1.1.tar.gz b/perl/aliases2html-1.1.tar.gz new file mode 100644 index 0000000000000000000000000000000000000000..1421bfd6cae3cb8f9ee654fc4f25fabf6c2728ae GIT binary patch literal 1434 zcmV;L1!ejliwFRlDf=@31MOFBZ`w!@&R6^^rVdS^2iVXwT)`k{LoP@(JtgT$r_x3) zUV>G#_IcMysy6-YH@oY#4P2|4%>Y&rhcP2NvUDOsw}lwXg<(v2X0dnY$)E(VHR~@O+%`RTv}ZcfvV|;hgw% z6$Tz>gn}bVIO1L_jIUdX&s#JcqRz3)m96%(XWgd#v}t$o^bZmR#59rHo89 z^Pjt@#C954d6?JtAaY|y#_C<$RfW#HepSA&<1-B7fZRnc^|U2{JQbSbOkSPz4d?Xo zEn+#J~$5OA3C7Fiv{MGTF_&9Cn68PP4F2~PN44>y{;TRB#{xuz# z2zYboyq*mWbYvJsd@wOq3M6R?n=@cKv+2+o!|D0tWH2}9`$}AAX%vk&HB*;hj((e@v~9K5ZjL;XV}_fa=6V zyw%j9XnG-Ib(nd$--u5oxRtkVqDB+g7rr|aeYyb zl!ZzdO=Wj+6gpJNy^V-)Q`6&FtpC?aU&-fNu%vX#k)=)83e7e)TBn5Mx=?GN5N=x> z%K4Lq)5d-Q>s`;Miy-kxuhx28#~rfk18;ySU5M`cVxrsidS;C5O6T~%ZBtQb_};B# zs1A$O1ER-7x4N)`uvRHSNlet~9FU zL&ulLk$3u`o36SrBD6N1O~)6Liw4eswrAGi^JjUdnXjq1v;=mAaDGJzc*JV?nj6S; zQhP&vDXk+c9wm2Nrfj{N@5?Koc)}j5YoVAG_Gl4Oj(rl@t)*1$&AZ;)U+O*aRpKDi z85LxA?<&pA#fid+I7twEOVB5HkS3Cw+!&J-Ip`+}BhW(W(4_cMriv&-bXDC=Oevwa z#a*-rLPm5$#8n~=W5Sb|;?(vt=*`0L10)gtaw0LsAA#UggcxJDUSXriMYy$3bm$r^ zwW?5WRF!h0n)vu}jUSQ=)xVOEyA7=0dX2isT7;}o_58R|Wh)W{!WIr*bc<&4ohwy^ zsF+=5HCotSt6xmURP2L*_m$ScHSe2wf|J5XK|1>KH>Fyc8?(Ndq7V`}6|>ywd4~Pz z*^86uY$CC*H5K@8T@mIs`nAkA;GdfOFYw<+&sBXF9I5&GMmclv-W&h-zbYk_R8mPL ol~htmC6!cCNhOt3Qb{G1R8mPLl~htmC4C3|4Q*wha{wp+0H9LK8~^|S literal 0 HcmV?d00001 diff --git a/reports/rfc/draft-andrews-dns-ascii-01.txt b/reports/rfc/draft-andrews-dns-ascii-01.txt new file mode 100644 index 0000000000..700c7e7ac2 --- /dev/null +++ b/reports/rfc/draft-andrews-dns-ascii-01.txt @@ -0,0 +1,109 @@ + 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] + +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] + diff --git a/reports/rfc/draft-gulbrandsen-dns-rr-srvcs-03.txt b/reports/rfc/draft-gulbrandsen-dns-rr-srvcs-03.txt new file mode 100644 index 0000000000..6fe0d696a4 --- /dev/null +++ b/reports/rfc/draft-gulbrandsen-dns-rr-srvcs-03.txt @@ -0,0 +1,559 @@ + +Applications Area Arnt Gulbrandsen +INTERNET-DRAFT Troll Technologies + 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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + + diff --git a/reports/rfc/draft-ietf-dnsind-clarify-01.txt b/reports/rfc/draft-ietf-dnsind-clarify-01.txt new file mode 100644 index 0000000000..a8b652e502 --- /dev/null +++ b/reports/rfc/draft-ietf-dnsind-clarify-01.txt @@ -0,0 +1,334 @@ + + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/reports/rfc/draft-ietf-dnsind-serial-03.txt b/reports/rfc/draft-ietf-dnsind-serial-03.txt new file mode 100644 index 0000000000..7f2e652785 --- /dev/null +++ b/reports/rfc/draft-ietf-dnsind-serial-03.txt @@ -0,0 +1,445 @@ + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/reports/rfc/draft-ietf-drums-smtpupd-02.txt b/reports/rfc/draft-ietf-drums-smtpupd-02.txt new file mode 100644 index 0000000000..7ef9df5b71 --- /dev/null +++ b/reports/rfc/draft-ietf-drums-smtpupd-02.txt @@ -0,0 +1,3403 @@ + +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) + + + + +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 + +<> + +2.3.5 domain + +<> + +2.3.6 buffer + +2.3.7 state table + +<> + + +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 . 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 " (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 + contains the source mailbox. + + MAIL FROM: [ ] + + 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 can contain more than just a mailbox. The + is a reverse source routing list of hosts and + source mailbox. The first host in the should be + the host sending this command. + + The optional are associated with negotiated SMTP + service extensions (see section ##2.2). + + The second step in the procedure is the RCPT command. + + RCPT TO: [ ] + + 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 + can contain more than just a mailbox. The + may be a source routing list of hosts and the + destination mailbox. However, in general, the + 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 are associated with negotiated SMTP + service extensions (see section ##2.2). + + The third step in the procedure is the DATA command. + + DATA + + 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: + | R: 250 OK + | + | S: RCPT TO: + | R: 250 OK + | + | S: RCPT TO: + | R: 550 No such user here + | + | S: RCPT TO: + | R: 250 OK + | + | S: DATA + | R: 354 Start mail input; end with . + | S: Blah blah blah... + | S: ...etc. etc. etc. + | S: . + | 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 +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 + 553-Harry Smith + 553 Melvin Smith + +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 + | + | Or + | + | S: VRFY Smith + | R: 251 User not local; will forward to + | + | Or + | + | S: VRFY Jones + | R: 550 String does not match anything. + | + | Or + | + | S: VRFY Jones + | R: 551 User not local; please try + | + | 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 + | R: 250-Fred Fonebone + | R: 250-Sam Q. Smith + | R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + | R: 250- + | R: 250 + | + | 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., "" +(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 . The command codes themselves are alphabetic +characters terminated by if parameters follow and +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* + + ehlo-line ::= ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + ; syntax and values depend on ehlo-keyword + ehlo-param ::= 1* + + ALPHA ::= + DIGIT ::= + + CR ::= + LF ::= + SP ::= + +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: + 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 "." (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 ":" ] ">" + + 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. + + +<> ::= | + +<> ::= """ """ + +<> ::= "\" | "\" | | + + ::= | "\" + + ::= | + + ::= + + ::= the carriage return character (ASCII code 13) + + ::= the line feed character (ASCII code 10) + + ::= the space character (ASCII code 32) + + ::= one, two, or three digits representing a decimal + integer value in the range 0 through 255 + + ::= any one of the 52 alphabetic characters A through Z + in upper case and a through z in lower case + + ::= any one of the 128 ASCII characters, but not any + or + + ::= any one of the ten digits 0 through 9 + + ::= any one of the 128 ASCII characters except , + , quote ("), or backslash (\) + + ::= any one of the 128 ASCII characters (no exceptions) + + ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." + | "," | ";" | ":" | "@" """ | 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:" + + ::= "Received:" + + ::= ";" + + + ::= "FROM" + + ::= "BY" + + ::= [] [] [] [] + + ::= "VIA" + + ::= "WITH" + + ::= "ID" + + ::= "FOR" + +<<>>FOR and need to be nailed down. + + ::= The standard names for links are registered with + the Internet Assigned Numbers Authority (IANA). + + ::= The standard names for protocols are + registered with the Internet Assigned Numbers Authority + (IANA). + + ::=
::= the one or two decimal integer day of the month in + the range 1 to 31. + + ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + ::= the four decimal integer year in the range 0000 to + 9999. + + ::= the two decimal integer hour of the day in the + range 00 to 24. + + ::= the two decimal integer minute of the hour in the + range 00 to 59. + + ::= the two decimal integer second of the minute in the + range 00 to 59. + + ::= 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 Service ready + 221 Service closing transmission channel + 421 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 + 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 + 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 . + 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 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + 252 Cannot VRFY user, but will accept message and attempt + delivery + + 354 Start mail input; end with . + + 421 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 + 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 USC-ISIF.ARPA Service ready + + +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 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 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 "." 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 is 512 characters. + +reply line + + The maximum total length of a reply line including the + reply code and the is 512 characters. + + +text line + + The maximum total length of a text line including the + 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. + + +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 + +<> + + +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. + + +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. + + +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 , optionally some text, and . + + 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 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. + + +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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + 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: + 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 . + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + 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: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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 + 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 + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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- + R: 250-Fred Fonebone + R: 250-Xenon Y. Zither + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + 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 + R: 250- + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + 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: + 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 . + 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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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. + + +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. + + + + +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 . + +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. + + + +The characters carriage return and line feed (in that order). + + + +The space character. + +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. + + +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. + diff --git a/reports/rfc/draft-ietf-html-i18n-04.txt b/reports/rfc/draft-ietf-html-i18n-04.txt new file mode 100644 index 0000000000..0ba8309292 --- /dev/null +++ b/reports/rfc/draft-ietf-html-i18n-04.txt @@ -0,0 +1,2296 @@ + + + +Network Working Group F. Yergeau +Internet Draft G. Nicol + 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 . Subscription address is . Discussions of the group are archived at + . + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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: + + + + + + + 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] + +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 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 element does not + include quotation marks, they have to be added by the rendering pro- + cess. + + NOTE -- 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 + element, and its sibling , are introduced to allow proper + markup of such text. and 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] + +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] + +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: + + AB xy CD + zw EF + + + + Expires 2 December 1996 [Page 13] + +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 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 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 ) 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] + +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] + +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] + +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: + + + + 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 + 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] + +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. + + + + + + ... + + -- + > + + + + + + + + ]]> + + + + + + + + + Expires 2 December 1996 [Page 19] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + + + + + %ISOlat1; + + + + + + + + + + + + + + Expires 2 December 1996 [Page 20] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires 2 December 1996 [Page 21] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Heading + is preferred to + + + + Expires 2 December 1996 [Page 23] + +Internet Draft HTML internationalization 27 May 1996 + + +

Heading

 + --> + ]]> + + + + + " + > + + + + + + + + + + + + + + + + #AttVal(Alt)" + > + + + + + + + + + + + + + + Expires 2 December 1996 [Page 24] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires 2 December 1996 [Page 25] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + ]]> + + + + + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + + + + + + Expires 2 December 1996 [Page 27] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + Directory" + > + Menu" + > + + + + + + + + Expires 2 December 1996 [Page 28] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + Heading +

Text ... + is preferred to +

Heading

+ Text ... + --> + ]]> + + + + + + + + + + + + + + + + + + + + + + + + + Form:" + %SDASUFF; "Form End." + > + + + + + + + + + + + + + + + + + Expires 2 December 1996 [Page 30] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + Select #AttVal(Multiple)" + > + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + ]]> + + + + + + + + + + + + + + + + " > + + + + + + + + + + + + Expires 2 December 1996 [Page 32] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + [Document is indexed/searchable.]"> + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + + + + + + + + + +7.2. SGML Declaration for HTML + + + + +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] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires 2 December 1996 [Page 36] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires 2 December 1996 [Page 37] + +Internet Draft HTML internationalization 27 May 1996 + + + + + + + + + + + + + + +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. + + + [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 + + + [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] + +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, + + + [NICOL2] G.T. Nicol, "MIME Header Supplemented File Type", Work + in progress, , + 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] + +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. + + [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] + +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] + diff --git a/reports/rfc/draft-ietf-http-v11-spec-03.txt b/reports/rfc/draft-ietf-http-v11-spec-03.txt new file mode 100644 index 0000000000..ff63034193 --- /dev/null +++ b/reports/rfc/draft-ietf-http-v11-spec-03.txt @@ -0,0 +1,8893 @@ + + +HTTP Working Group R. Fielding, UC Irvine +INTERNET-DRAFT H. Frystyk, MIT/LCS + 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 . Discussions of the +working group are archived at +. General discussions about +HTTP and the applications which use HTTP should take place on the 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 "*element" indicating at least and at most + +Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13] + + + + +INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996 + + + 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: "(element)" is equivalent to + "*(element)"; that is, exactly 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 "#element " indicating at least + and at most 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 = + CHAR = + +Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14] + + + + +INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996 + + + UPALPHA = + LOALPHA = + ALPHA = UPALPHA | LOALPHA + DIGIT = + CTL = + CR = + LF = + SP = + HT = + <"> = + +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 = + +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* + + 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 = + +A string of text is parsed as a single word if it is quoted using +double-quote marks. + + quoted-string = ( <"> *(qdtext) <"> ) + + + qdtext = 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 "." 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 +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 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 = + +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 = + + 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 = *<> + + hex-no-zero = + +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 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 = * + +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 = + + 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 = + +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 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 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] + + + diff --git a/reports/rfc/draft-ietf-ids-dnsnames-00.txt b/reports/rfc/draft-ietf-ids-dnsnames-00.txt new file mode 100644 index 0000000000..fa63541353 --- /dev/null +++ b/reports/rfc/draft-ietf-ids-dnsnames-00.txt @@ -0,0 +1,561 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +INTERNET-DRAFT May 1996 + + + This Internet Draft expires 29th November, 1996. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 10] + diff --git a/reports/rfc/draft-ietf-mailext-mail-attributes-04.txt b/reports/rfc/draft-ietf-mailext-mail-attributes-04.txt new file mode 100644 index 0000000000..cee193c23f --- /dev/null +++ b/reports/rfc/draft-ietf-mailext-mail-attributes-04.txt @@ -0,0 +1,1154 @@ +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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] + draft-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] diff --git a/reports/rfc/draft-ietf-ssh-handbook-03.txt b/reports/rfc/draft-ietf-ssh-handbook-03.txt new file mode 100644 index 0000000000..5fb846cbb4 --- /dev/null +++ b/reports/rfc/draft-ietf-ssh-handbook-03.txt @@ -0,0 +1,5334 @@ + +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] + + diff --git a/reports/rfc/draft-ietf-userglos-glossary2-01.txt b/reports/rfc/draft-ietf-userglos-glossary2-01.txt new file mode 100644 index 0000000000..8daa19cc58 --- /dev/null +++ b/reports/rfc/draft-ietf-userglos-glossary2-01.txt @@ -0,0 +1,3472 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/reports/rfc/draft-newman-datetime-00.txt b/reports/rfc/draft-newman-datetime-00.txt new file mode 100644 index 0000000000..f36726df00 --- /dev/null +++ b/reports/rfc/draft-newman-datetime-00.txt @@ -0,0 +1,505 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +Internet Draft Date and Time December 1996 + + + + year / 4 + cent / 4 - 2 * cent) % 7]); + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newman [Page 9] + diff --git a/reports/rfc/draft-vixie-ops-stdaddr-00.txt b/reports/rfc/draft-vixie-ops-stdaddr-00.txt new file mode 100644 index 0000000000..59221f989a --- /dev/null +++ b/reports/rfc/draft-vixie-ops-stdaddr-00.txt @@ -0,0 +1,317 @@ + + 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] + + 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] + + 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] + + 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] + + 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] + + 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] + + diff --git a/reports/rfc/draft-vixie-ops-stdaddr-01.txt b/reports/rfc/draft-vixie-ops-stdaddr-01.txt new file mode 100644 index 0000000000..1b494c52f7 --- /dev/null +++ b/reports/rfc/draft-vixie-ops-stdaddr-01.txt @@ -0,0 +1,369 @@ + + 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] + + 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] + + 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] + + 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] + + 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] + + 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] + + 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] + diff --git a/reports/rfc/rfc1942.txt b/reports/rfc/rfc1942.txt new file mode 100644 index 0000000000..9d7d2d95c6 --- /dev/null +++ b/reports/rfc/rfc1942.txt @@ -0,0 +1,1683 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + diff --git a/ss/19960831-rekrutering.html b/ss/19960831-rekrutering.html new file mode 100644 index 0000000000..dbf67ad224 --- /dev/null +++ b/ss/19960831-rekrutering.html @@ -0,0 +1,69 @@ +<HTML> +<HEAD> +<TITLE> + + + + +Tormod <tormods@stud.cs.uit.no> & Pans <pans@orgsek.sst.org.uit.no> +
1996-08-31 +
Sak +
http://www.cs.uit.no/~petterr/ss/19960831-rekrutering.html +
+

Rekrutering til realfag

+ +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. + +

De siste årene har søkningen til realfag gått dramatisk ned, spesielt +er andelen jenter gått til helvete. (tall og sånnt). + +

- realister er allsidige +
- teknologifrykt + +

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. + + + +

Hva universitetet kan gjøre

+ +
    +
  • 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. + +
  • klargjøre ansvarsfordeling internt +
  • informasjon til elevene (overta/fortsette det JG/IMR har gjort) + Fristille JG/IMR til å bedre rekrutering av jenter til høyere nivå. +
  • Landsdelspolitikerne må på banen +
+ +

Forslag til vedtak

+ +
+ +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: +
+ + + + diff --git a/ss/19960908.net-tjenester.html b/ss/19960908.net-tjenester.html new file mode 100644 index 0000000000..e84082d370 --- /dev/null +++ b/ss/19960908.net-tjenester.html @@ -0,0 +1,89 @@ + + +Net-tjenester til studentstyret arbeidsutvalg + + + + +Petter Reinholdtsen +<pere@td.org.uit.no> +
1996-10-13 +
Sak 84/96 +
http://www.cs.uit.no/~petterr/ss/19960908.net-tjenester.html +
+

Net-tjenester til studentstyrets arbeidsutvalg

+ +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. + +

Systemet kan settes opp på meget kort varsel, og være i drift i +løpet av høsten hvis det gis klarsignal. + +

Resultat av installasjonen

+ +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. + +

Kontorlandskapet vil få en delt filserver der alle dokumenter og +andre data kan lagres. Tilgang til filene kan reguleres fra bruker +til bruker. + +

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. + +

Nødvendig utstyr og kostnader

+ +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). + +

Operativsystem og støtteprogrogrammer krever under 300Mb av disken. +Resten vil være tilgjengelig for brukerdata. + + + +
Budsjett
Tiltak Kostnad +
Innkjøp av maskinvare +
    +
  • - minimum 486 m/16Mb ram +
  • - Ethernet-kort +
  • - 1-2 Gb SCSI HD +
  • - tape-streamer +
+		10.000,- +
Installasjon og en måneds innkjøring av server 5.000,- +
Totalt 15.000,- +
+ +

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,-. + +

Innstallasjon er satt til 5.000,-. Dette er det jeg vil ha for å +gjøre jobben. Andre kan sansynligvis gjøre det billigere. + +

Drift og vedlikehold

+ +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. + +

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. + +

Av hensyn til installasjonens stabilitet og sikkerhet bør kun +IT-personell med erfaring gjøre slike endringer av systemet. + + + + diff --git a/ss/9610.semavg.html b/ss/9610.semavg.html new file mode 100644 index 0000000000..934a555d91 --- /dev/null +++ b/ss/9610.semavg.html @@ -0,0 +1,180 @@ + + + + + + + +Petter Reinholdtsen +<pere@td.org.uit.no> +
Cato Hauge Olsen +<cato@stud.cs.uit.no> +
1996-12-04 +

+

Endringsforslag, fordeling av semesteravgift

+Saksframlegg til studentstyret 10/96, 4. desember 1996 + +

Innledning

+ +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. + +

Presentasjon av forslag

+

Forslag fra Petter

+ +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. + +

Jeg foreslår å kutte "Tilskudd NSU" med like mye som støtten +fra bruker å være, og overføre dette til "Tilskudd +stydentstyret". Tilskudd studentstyret reduseres altså med 190.000. + +

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. + +

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. + +

Jeg synes det er viktig å prioritere mangfoldet blant +studentaktivitetene, og vil derfor øke posten til studentforeninger, +der det erfaringsmessig søker rundt 30 foreninger. + +

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". + +

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. + +

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. + +

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. + +

Forslag fra Cato

+ +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. + +

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 + +

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,- + + +

Tallene

+ +Tallene er stort sett i hele tusen. + + +
B ´93B ´94R ´95B ´96B ´97PetterCato +
34601SemesteravgiftR: -3.813R: -4.025-4.063020-3.965
R: 4.108		-4.550-3.900-4.000 +
Overføring fra UiTø til studentstyret--357 +
79101Tilskudd studentstyret410238190.000190190200160 +
79102Tilskudd studentforeninger130150132.200130120170130 +
79103Tilskudd studentidrett375420408.437465465420450 +
79104Tilskudd studentradio224270270.000270Fjernes-- +
79105 Tilskudd studentavis395475450.000450454440454 +
Sivilarbeider TSI/Samfunnet-6059.100 +
79106Tilskudd studentsamfunnet523083.82870241241241 +
79107Tilskudd svalbardstudentene-1011.31010101010 +
79108Tilskudd Jusshjelpa----252525 +
79109Tilskudd ISU --NY21-21 +
79201
79202		Annonser for INFO og
Annonser som støtte		110158.842-Fjernes-- +
79301Tilskudd NSU (fast)411479494.380494494294494 +
79302Tilskudd SAIH (fast)108126130.100130130130130 +
Spesiell konstnader utenlandske studenter--11.120-- +
79402Bolighjelpa--31544Fjernes-- +
79501Tilskudd Studentenes Sosialtj. (fast)370,5460437.632588605605605 +
79502Refusjon egenandeler (fast)9011090.827110110110100 +
79503Tilskudd helsefondet (fast)350350487.104350350350350 +
79504Krisehjelp (fast)888.1008888 +
79600Barnehagesubsidier150250-250350250350 +
79700Diverse sosiale og kult. kostnader155,525194.49681000 +
79750UKA-97--NY100100100 +
Fond barnehager-100 +
79800SSts Disposisjonsfond-1270100 +
79900Semesteravgiftsfondet NY750272 +
Til fordeling v97547 +
Bo-miljøprosjektet70.235 +
Saldering hos samskipnaden443765 +
SUM 3.2403.9063.9654.5503.9004.000 +
+ +

Notater til postene

+Felleskommentarer er skrevet med vanlig skrift. Petters kommentarer er skrevet med fet skrift, og Catos kommentarer er skrevet med hellende skrift. +
+ +
Semesteravgift +
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). + +
Dette er 13.000 semesteravgifter til Kr. 300,-. Tallet vil bli høyere hvis det blir like mange semesteravgifter som i år. + +
Tilskudd studentidrett +
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. + +
Tilskudd studentavis. +
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. + +
Tilskudd svaldbardstudentene + +
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). + +
Tilskudd NSU +
Dette er kr. 38,- per student pr semester. For 1995 var det 13.010 +semesteravgifter. + +
Saldering hos samskipnaden +
Her er restpengene fra semesteravgiften blitt brukt opp av samskipnaden. + +
+ +

Referanser

+93,94 Brev fra Studentstyret v/Kjetil Kvalsvig til +Studentsamskipnaden etter møte 1993-12-08 +
95 Regnskapstall fra samskipnaden uthentet 1996-12-04 +
96,97 Sakspapir til SS 10/96 sak 99/96 + + diff --git a/ss/budsj96.html b/ss/budsj96.html new file mode 100644 index 0000000000..ebe57ebaa1 --- /dev/null +++ b/ss/budsj96.html @@ -0,0 +1,56 @@ + + + + + + +Petter Reinholdtsen +
1996-10-16 +
Til Studentstyret +
+ +

Budsjett 1996 for Studentstyrets arbeidsutvalg

+ +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". + +

+ +
1996 +
Inntekter +
Tilskudd fra semesteravgifta100.000,- +
Tilskudd fra UiTø 700.000,- +
Tilskudd fra NSU 200.000,- +
Tilskudd UiTø-gruppa? +
Tilskudd bolighjelpa? +
Tilskudd seminar24.000,- +
Tilskudd Barents0,- +
Sum Inntekter 1.024.000,- +
Utgifter +
Honorar leder103.400,- +
Honorar nestleder87.890,- +
Honorar politisk sekretær87.890,- +
Lønn organisasjonssekr.204.000,- +
Honorar AU-medlemmer94.000,- +
Feriepenger57.718,- +
Arbeidsgiveravgift63.489,- +
Administrasjon47.500,- +
Kopimaskin / trykking50.000,- +
Informasjon / aksjoner32.813,- +
Skolering / seminarer35.000,- +
Avsetning / invest.15.000,- +
Bolighjelpa? +
Universitetsstyregruppa? +
Reiser 30.000,- +
Barents 40.000,- +
Tilskudd institutt AU'er60.000,- +
Urnevalg 4.500,- +
Barnepass 10.800,- +
Sum utgifter1.024.000,- +
+ + + + diff --git a/ss/pc-spec.html b/ss/pc-spec.html new file mode 100644 index 0000000000..a7f2c69258 --- /dev/null +++ b/ss/pc-spec.html @@ -0,0 +1,54 @@ + + + + + + + +Petter Reinholdtsen - +pere@td.org.uit.no +
1996-12-12 +

+ +

Prisanslag, nettserver

+ + + +
Kabinett m/strøm og plass +~ 500 + +
Hovedkort med min 486 dx +? + +
RAM 16Mb +1.000 + +
Nettkort tynnether +~ 500 + +
SCSI-kort +~ 1.000 + +
SCSI-disk 2GB +ny ~4.200 + +
SCSI-tapestreamer (helst DAT) + ~3.000 + +
Diskettstasjon 3.5" +ny ~300 + +
Tastatur +ny ~200 + +
Div. kabler og lokk +~200 + +
Sum: +~ 9500 + +
+ + + + diff --git a/ss/ref97k.html b/ss/ref97k.html new file mode 100644 index 0000000000..46c9555787 --- /dev/null +++ b/ss/ref97k.html @@ -0,0 +1,275 @@ + + +Forslag til referat fra konstituerende Studentstyremøte torsdag 5.12.96 + + + + + + +

- forslag til -

+ +

Referat fra Konstituerende Studentstyremøte for +
Studentstyret 1997 torsdag 5.12.96

+ + +Tilstede: + +
Eidi Ann HansenISV +
Roger JørgensenSSF +
Pål D. EkranSEL +
Liss M. JenssenSELgikk 21.05 for Gjertrud Pedersen +
Tormod K.SivertsenSEL +
Therese BakkevoldISV +
Petter ReinholdtsenIMR +
Ingulf NordahlIRV +
Ann Kristin MarkussenIRV +
Roy T. MagnussenIBG +
Marie BarlindhaugFM +
Sigrid Ovanger StenslandROSSA +
Stig-Erik FalkISL +
Solbjørg MarjalaROSSA +
Hugo RystrømISVgikk 21.05 for Ole Martin E. +
Sissel MikkelsenSSSR +
Margaret AaragFM +
Trine EskelandSSF +
Aina WikestadTSVL +
Nils Kristian BakkeModerat +
Marianne HolstModerat +
Stian JensenModerat +
Ingar HaukanesNFH +
Ogbebo FortuneISUfra 15.25 gikk 21.20 +
+ +

Meldt forfall: + +
Ingrid HedlundISL +
+ +

Tid: 16.15 ( - 21.35 ). +
Sted: Hiet, Hovedgården. + +

Til konstituering. +
Winston Makhete leverte skriftlig melding om at han trakk seg fra +Studentstyret 1997. Solbjørg Marjala overtar som fast medlem av +Studentstyret. + +

Valg av møteledelse. +
Jørn Fause og Pia Skøien ble foreslått og enstemmig valgt. + +

Godkjenning av innkaling og dagsorden. +
Innkallingen enstemmig godkjent. + +

Merknader til dagsorden: +
Fra ordstyrerbordet: Forslag om å vedta forretningsorden før den +videre saksbehandlingen. +
Enstemmig vedtatt. +
Fra Nils Kristian Bakke: To saker til Eventuellt. +
1) Intensjonsvedtak om helgemøter i Studentstyret +
Vedtatt (sak S 110/96 under Eventuellt). 16 stemmer for, 5 mot, 2 +avholdende. +
2) Uttalelse om tvangsflytting av studenter +
Falt. 12 stemmer for, 10 mot, 1 avholdende. +
Fra ordstyrerbordet: Forslag om at S 105/96 kun behandles som en +orienteringssak. +
Falt. 10 stemmer for, 10 mot, 2 avholdende. +
Fra Margaret Aarag og Marie Barlindhaug: "Foreslår å utsette sak +104/96 til neste SST-møte el. etter evt. diskusjonsmøte / +overlappingsseminar." +
Vedtatt. 22 stemmer for, 1 avholdende. + +

Dagsorden enstemmig godkjent med disse endringene. + +

Forretningsorden. +
Nytt forslag til forretningsorden delt ut på møtet. +
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). +
Falt. 3 stemmer for, 16 mot, 3 avholdende. + +

Sak SSt 105/96 Arbeidsprogram for Studentstyret 1997.

+Utsatt. + +

Sak SSt 105/96 Honorering og strukturering av studentstyrets +arbeidsutvalg.

+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." +
Vedtatt. 10 stemmer for, 8 mot, 5 avholdende. + +

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." +
Vedtatt. 10 stemmer for, 8 mot, 5 avholdende. + +

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. + +

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." +
Falt. 8 stemmer for, 13 mot, 2 avholdende. + +

Forslag fra Roger Jørgensen ble satt opp mot saksframlegget: "Leders +honorar senkes til 100.000,-. Nestleder heves til 70.000,-." +
Vedtatt. 14 stemmer for, 5 mot, 4 avholdende. + +

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." +
Falt. 9 stemmer for, 12 mot, 2 avholdende. + +

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): +
Falt. 9 stemmer for, 12 mot, 2 avholdende. + +

Honorering av Studentstyrets Arbeidsutvalg blir som følger: + +
Leder:100.000,-/år +
Nestleder:70.000,-/år +
Sekretær:173.000,-/år +
AU-medlemmer/komitéledere:4.000,-/mnd. +
+ + +

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. + +

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. + +

Sak SSt 106/96 Valg av studentstyrets leder for 1997.

+Følgende kandidater stilte til valg: +
    +
  • Petter Reinholdtsen +
  • Trine Eskeland +
  • Stian Jensen +
  • Eidi Ann Hansen +
+ +Kandidatene fikk fem minutter til å presentere seg før det ble åpnet +for en omfattende spørsmålsrundte. + +

Det ble i henhold til forretningsorden foretatt preferansevalg: + +
Petter Reinholdtsen33 +
Trine Eskeland42 +
Stian Jensen28 +
Eidi Ann Hansen41 +
+ +Denne stemmefordelingen resulterte i en ny valgomgang mellom Trine +Eskeland og Eidi Ann Hansen. Det ble gjennomført flertallsvalg: + +
Eidi Ann Hansen13 +
Trine Eskeland11 +
+ +

Studentstyret velger som sin leder for perioden 1/1 - 31/12 +1997: Eidi Ann Hansen. + +

Sak SSt 107/96 Valg av Studentstyrets nestleder for 1997

+Følgende kandidater stilte til valg: +
    +
  • Stian Jensen +
  • Roy T. Magnussen +
+ +Kandidaten som ikke tidligere var presentert fikk anledning til dette, +før det ble åpnet for en spørsmålsrunde. +
Det ble foretatt flertallsvalg: + +
Stian Jensen16 +
Roy T. Magnussen8 +
+ +

Studentstyret velger som sin Nestleder for perioden 1/1 - 31/12 +1997: Stian Jensen. + +

Sak SSt 108/96 Valg av AU-medlemmer for Studentstyret.

+Følgende kandidater stilte til valg: +
    +
  • Roy T. Magnussen +
  • Solbjørg Marjala +
  • Sigrid Ovanger Stensland +
  • Ingulf Nordahl +
+Kandidater som tidligere ikke var presentert fikk anledning til dette, +før det ble åpnet for en spørsmålsrunde. +
Det ble foretatt preferansevalg: + +
Roy T. Magnussen36 +
Solbjørg Marjala36 +
Sigrid Ovanger Stensland28 +
Ingulf Nordahl44 +
+ +

Studentstyret velger som sine AU-medlemmer i perioden 1/1 - 31/12 +1997: +

    +
  • Ingulf Nordahl +
  • Roy T. Magnussen +
  • Solbjørg Marjala +
+ + +

Sak SSt 109/96 Valg av kontrollkomité for studentstyret 1997.

+Følgende kandidater stillte til valg: +
    +
  • Torbjørn Flaatten +
  • Tor-Ståle Hansen +
  • Torgeir Dølerud +
  • Arulnesan Marianayagam +
+ +

Kandidatene fikk anledning til en kort presentasjon før en kort +spørsmålsrunde. +
Det ble foretatt preferansevalg: + + +
Torbjørn Flaatten41 +
Tor-Ståle Hansen35 +
Torgeir Dølerud43 +
Arulnesan Marianayagam25 +
+ +

Studentstyret velger til kontrollkomité for perioden 1/1 - 31/12 +1997: +

    +
  • Torbjørn Flaatten +
  • Tor-Ståle Hansen +
  • Torgeir Dølerud +
+ +

Sak SSt 110/96 Intensjonsvedtak om helgemøter i studentstyret.

+Saksfremlegg fra Nils Kristian Bakke ble delt ut på møtet. +
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. + +

Endringsforslag fra Eidi Ann Hansen: "(som 5. avsnitt) +Studentstyret vil vurdere helgemøter i Studentstyret på +overlappingsseminaret i begynnelsen av perioden. +
Falt. 7 stemmer for, 10 mot, 4 avholdende. + +

Nils Kristian Bakkes forslag vedtatt. 12 stemmer for, 3 mot, 6 +avholdende. + +

Møtet hevet 2135. + +

Referent + +
Pia Skøien (sign.) + + + diff --git a/ss/regn96.html b/ss/regn96.html new file mode 100644 index 0000000000..6f980611ad --- /dev/null +++ b/ss/regn96.html @@ -0,0 +1,108 @@ + + + + + + +Petter Reinholdtsen +
1996-10-16 +
Til Studentstyret +

+ +

Foreløpig regnskap 1996 for Studentstyrets arbeidsutvalg

+ +

+ +
1996Budsjett +Regnskap +
pr. 9.okt. +
Inntekter +
Tilskudd fra semesteravgifta +100.000,- +
Tilskudd fra UiTø +700.000,- +450.000,- +
Tilskudd fra NSU +200.000,- +
Tilskudd UiTø-gruppa +? +
Tilskudd bolighjelpa +? +
Tilskudd seminar +24.000,- +
Tilskudd Barents +0,- +
Tilskudd arrangement +16.118,- +
Sum Inntekter +1.024.000,- +466.118,00 + +
Utgifter +
Honorar leder +103.400,- +
Honorar nestleder +87.890,- +
Honorar politisk sekretær +87.890,- +
Honorar AU-medlemmer +94.000,- +
Lønn organisasjonssekr. +204.000,- +
Totalt +577.180,- +397.534,76 +
Feriepenger +57.718,- +41.627.15 +
Arbeidsgiveravgift +63.489,- +26.556.32 +
Administrasjon +47.500,- +18.628,38 +
Kopimaskin / trykking +50.000,- +27.162,53 +
Informasjon / aksjoner +32.813,- +11.111.50 +
Skolering / seminarer +35.000,- +4.000,- +
Avsetning / invest. +15.000,- +14.246,03 +
Bolighjelpa +? +? +
Universitetsstyregruppa +? +18.304,- +
Reiser +30.000,- +14.959,50 +
Barents +40.000,- +0,- +
Tilskudd institutt AU'er +60.000,- +0,- +
Urnevalg +4.500,- +254,- +
Barnepass +10.800,- +1.500,- +
Upostert +26.926,58 +
Underskudd 1995 +52.765,02 +
Sum utgifter +1.024.000,- +671.400.77 +
+ + + + diff --git a/store/doc-espensk/emacs-default.html b/store/doc-espensk/emacs-default.html new file mode 100644 index 0000000000..02c07b99c5 --- /dev/null +++ b/store/doc-espensk/emacs-default.html @@ -0,0 +1,48 @@ + + Tilrettelegging av emacs-konfig-filer + + + +

Tilrettelegging av emacs-konfig-filer

+ +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. + +

Måten dette fungerer på, er at emcas laster inn og eksekverer en +fil, default.el, før selve editoren starter opp. Denne +filen finnes under /store/lib/xemacs/site-lisp og +/store/share/emacs/site-lisp for henholdsvis XEmacs og Emacs. + +

Disse filene genereres hver natt av en nightly job. Det +som skjer, er at alle filer på formen ``default.el-*'' +blir konkatinert isammen til en enkel ``default.el''. +Sammen med Python-dsitribusjonen følger det f.eks. med en emacs-mode +(python-mode.el) for editering av python-filer. Dette +ønsker vi å benytte oss av, og lager derfor følgende to filer: + +

+ /store/lib/xemacs/site-lisp/default.el-python
+ /store/share/emacs/site-lisp/default.el-python +
+ +Disse filene er identiske, og inneholder følgende elisp-kode: + ++ (autoload 'python-mode "python-mode" "Python editing mode." t) + (setq auto-mode-alist + (cons '("\\.py$" . python-mode) auto-mode-alist)) + + +Koden fører til at emacs automatisk laster inn +python-mode.el når funksjonen python-mode +blir startet i emacs (f.eks. ved ``M-x python-mode''). I +tillegg sier den at når en fil som ender på ``.py'' blir +lastet inn, så skal python-mode automatisk startes opp. + + +
+
eSk
+ + diff --git a/store/doc-espensk/emacs-dir.html b/store/doc-espensk/emacs-dir.html new file mode 100644 index 0000000000..84a6f5df7d --- /dev/null +++ b/store/doc-espensk/emacs-dir.html @@ -0,0 +1,95 @@ + + Tilrettelegging av emacs-info-sider + + + +

Tilrettelegging av emacs-info-sider

+ +Enkelte applikasjoner (særlig GNU applikasjoner) har medfølgende +dokumentasjon i emacs-info-format. Denne dokumentasjonen består av +filer som ender på .info, .info-1, +.info-2, etc, og ender som oftest opp i +/store/info-katalogen når ``make install'' +har gjort seg ferdig. + +

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 + +

+ <navn>.dir.<doktype> +
+ +og befinne seg under /store/info. Navn er her +navnet på dokumentasjonen (f.eks. bash eller +gcc). Doktype forteller hvilket emne +dokumentasjonen inneholder. Dette benyttes for å plassere +meny-entryet på en fornuftig plass i menyen, og kan ha følgende +verdier: + +
+
emacs +
Benyttes for dokumentasjon som omhandler bruken av Emacs/XEmacs. + +
elisp +
Benyttes for emacs-lisp-dokumenasjon. + +
packages +
Benyttes for dokumentasjon som omhandler bruken av en tillegspakke til + emacs (f.eks. AUC-TeX eller GNUS). + +
compilers +
Benyttes for dokumentasjon til kompilatorer eller utviklingsverktøy + (f.eks. GCC eller Make). + +
library +
Benyttes for dokumentasjon som omhandler diverse biblioteker + (f.eks. Libg++ eller Mmalloc). + +
standard +
Benyttes for dokumentasjon av diverse standarder og formater (f.eks. + GNU coding standards). + +
program +
Benyttes for dokumentasjon av andre programpakker (f.eks. Bash og Zsh). + +
+ +For å lage en meny-entry for Bash, lager vi f.eks. en fil +``info/bash.dir.program'' i bash-filsettet +som inneholder følgende tekst: + ++ * Bash: (bash). Bourne Again Shell + + +Dette fører til at linjen dukker opp under overskriften; ``Other +programs and packages'' neste dag (etter at +nightly-jobbene til Emacs eller XEmacs har kjørt). + +

Mulig forslag til meny-entry

+ +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 ``flex.info'': + ++ START-INFO-DIR-ENTRY + * Flex: (flex). A fast scanner generator + END-INFO-DIR-ENTRY + + +Den aktuelle linjen kan derfor bare klippes og limes rett inn i den +aktuelle dir-filen. I dette tilfellet +``flex.dir.compilers''. Man bør derimot passe på å +starte forklaringen av dokumentasjonen (i vår tilfelle ``A +fast...'') på kolonne 33. Dette fører til at alle forklaringene +blir pent alignet ca. langs midten av emacs-vinduet, xtermen, +eller hvor nå enn dokumentasjonen skal leses. + + +
+
eSk
+ + diff --git a/store/doc-espensk/environ.html b/store/doc-espensk/environ.html new file mode 100644 index 0000000000..5b66edca74 --- /dev/null +++ b/store/doc-espensk/environ.html @@ -0,0 +1,208 @@ + + Environment-konfigurering + + + +

Environment-konfigurering

+ +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 +PATH eller MANPATH-variablene, eller at +andre applikasjonsspesifikke variabler må settes +(eks. FMHOME i FrameMaker). + +

Det er derimot ønskelig at brukerne skal slippe å vite om disse +variablene -- de skal automatisk konfigureres inn i brukerens oppsett. +Et filsett, env-config, i store sørger for +dette. + +

I katalogen /store/etc/ENV ligger det en rekke filer +``ENV-*'' som forteller noe om hvlike +environment-variabler som må settes. Disse filene hører til +forskjellige filsett (teTeX, postgres95, +osv.). Filsettet env-config inneholder dessuten noen +default-variabler som det ikke passer å spesifisere i de andre +filsettene (eks. TZ og XFILESEARCHPATH, samt +standardverdier for PATH og MANPATH). + +

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. + +

Konfigurasjonsfilenes format

+ +La oss se på formatet som disse konfigusrasjons-filene har. + +
    +
  • Blanke linjer, samt kommentarer (linjer som begynner + med #) blir ignorert. + +

  • Dersom tekststrengene $TOP eller + $TOPDIR forekommer, blir dette byttet ut med filstien + til linktre-roten (typisk /store). + +

  • Formatet på de resterende linjene, er som følger: + +
    + <uid>:<gid>:<pri>:<type>:<variabel>=<verdi> +
    + +
    +
    <uid> +
    Er en kommaseparert liste av brukere (dvs. bruker-id'er) som skal + ha variabelen satt (f.eks. ``espensk,geiri''). + Dersom feltet består av ``*'', vil alle brukere få + variabelen satt. Komplimentet av brukere kan også spesifiseres + ved å benytte ``!''. ``!root'' + 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. + +

    <gid> +
    Er en kommaseparert liste over grupper (dvs. gruppe-id'er) som + skal ha variabelen satt. ``/usr/bin/groups'' + benyttes for å bestemme hvilke grupper den aktuelle brukeren er + medlem av. Formatet er forøvrig likt det som benyttes for + <uid>. + +

    <pri> +
    Forteller hvliken prioritet denne variabelsettingen har. I + filstier benyttes dette til å fortelle hvor tidlig i stien + verdien skal settes. I PATH har + f.eks. ``/store/bin'' prioritet 5 og + ``/store/opt/krb5/bin'' priotitet 4. Dette fører + til at ``/store/opt/krb5/bin'' havner før + ``/store/bin'' i den ferdige stien. + +

    Dersom vi har med vanlige verider å gjøre (dvs. alle verdier + som ikke er stier) vil dette fungere som en helt vanlig + priotitet. TZ med prioritet 4 benyttes f.eks. før + TZ med prioritet 5. + +

    <type> +
    Forteller hvilken type variabel vi har med å gjøre. +
    +
    p - +
    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 + ``/usr/ingres/bin'' inn i PATH, + vil dette bare gjelde på lglaben (og andre steder hvor + ingres er installert). +
    n - +
    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 XFILESEARCHPATH til å være + ``/store/lib/X11/app-defaults/%N''. I dette + tilfellet finnes jo ingen slik katalog. +
    s - +
    sier at vi har med en enkel verdi å gjøre (f.eks. + TZ). +
    + +

    <variabel>=<verdi> +
    Dersom variabelen er en enkel verdi (type s), blir + variabelen (eventuelt) satt til den gitte verdien. Dersom + variabelen derimot er en sti (type p eller + n), blir den gitte verdien (eventuelt) lagt til i + stien. +
    + +

    Hvis en linje ender med ``\'' (backslash), blir + linjen konkatinert med neste linje, og et ``:'' (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: + +

    + *:*: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 + + + Begge sier at alle brukere (og alle grupper) skal ha de 3 filstiene + lagt til i PATH. Siden prioriteten er høy (2), vil + disse elementene havne langt frem i stien. Siden variabel-settingen + er av type p, vil eksistensen til hver av katalogene + bli sjekket før de blir tatt med. Dvs. at dersom f.eks. katalogen + ``/opt/graphics/common/bin'' ikke eksisterer, vil den + ikke bli tatt med i den ferdige stien. + +

    Den typiske bruken av environment-settinger, er derimot meget + enkel. Som oftest ønsker vi bare å legge til et enkelt element i + PATH og/eller MANPATH. Dette gjelder + f.eks. for Kerberos-applikasjonen. Filsettet inneholder derfor en + fil ``etc/ENV/ENV-kerberos''. Innholdet i denne filen + er: + +

    + # + # Kerberos settings + # + *:*:4:p:PATH=$TOPDIR/opt/krb5/bin + *:*:4:p:MANPATH=$TOPDIR/opt/krb5/man + + + Vi ser også at filen inneholder en liten kommentar. Dette er smart + fordi det fører til at + + + $ cat /store/etc/ENV/ENV-* + + + gir nogenlunde fornuftig output. + +
+ +

Hvordan benytte seg av det ferdiggenererte oppsettet

+ + +Applikasjonen env-config genererer filene +/store/etc/src.sh og /store/etc/src.csh hver +natt ved hjelp av en nightly command. De genererte filene er +i henholdsvis bourne-shell og c-shell format, og kan +``sources'' av andre shell-oppstart-filer (eller interaktivt +av brukerne) dersom det er ønskelig. Zsh genererer +dessuten sin egen /store/skel/zshenv hver natt slik at +den ikke behøver å source noen av disse filene. + +

Dersom applikasjoner ønsker å konfigurere dette selv, slik som +f.eks. zsh gjør, er det ønskelig at koden i +env-config benyttes. Eksempel på perl-kode følger: + +

+ 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 ); + + +Den aktuelle teksten kan dermed plasserers hvor det måtte være +ønskelig (eks. /store/skel/zshenv). +``&Env'build_csh_env'' kan også benyttes istedenfor +``&Env'build_env'' dersom csh-syntaks er +ønskelig. + +

Filsett som skal benytte seg av environment-konfigurasjonene bør +settes til å ha dependency env-config (dette +gjelder f.eks. zsh). Hvis ikke dette blir gjort vil ikke: + +

    +
  • ``environ.pl'' kunne inkluderes i perl-skript + (dersom det benyttes). +
  • ``etc/src.sh'' eller ``etc/src.csh'' + vil ikke eksistere (dersom dette f.eks. skulle sources i + oppstartfilene). +
  • Default-konfigurasjonene vil ikke eksitere. Dette vil føre til + at vi bl.a. ville få en meget slank PATH og + MANPATH. +
+ +
+
eSk
+ + diff --git a/store/doc-espensk/in-install.html b/store/doc-espensk/in-install.html new file mode 100644 index 0000000000..51c2548ab0 --- /dev/null +++ b/store/doc-espensk/in-install.html @@ -0,0 +1,102 @@ + + Kompilering i store + + + +

Kompilering i store

+ +Hvordan man kompilerer selve applikasjonen i store 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). + +

Det man derimot må passe på når man kompilerer programmer, er at +filstier som blir hardkodet inn i programmene benytter prefiksen +/store istedenfor den filstien som blir foreslått (typisk +/usr/local). + +

Kommandoene unshadow og fix

+ +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 hpux vil +sansynligvis ikke gjelde for solaris), og må derfor kopiere +filen over til skyggetreet slik at vi forandrer på kopien av filen +istedenfor orginalen. Til dette benytter vi kommandoen +unshadow. Hvis vi f.eks. skal forandre på en fil +src/config.h, kan vi skrive: + ++ $ unshadow src/config.h + + +Deretter kan vi editere filen etter behov. Som oftest ønsker vi å +kjøre unshadow på en fil fordi vi vil forandre den. Av +denne grunnen finnes også en kommando fix som kjører +unshadow på den spesifiserte filen, og deretter starter +opp vi på den. Følgende to kommandosekvenser er derfor +like: + ++ $ unshadow Makefile + $ vi Makefile + + $ fix Makefile + + + +

Configure-skript

+ +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 store særdeles enkel. Alt +man behøver å gjøre, er å spesifisere en prefiks, /store, +til konfigurasjonsskriptet. Dette er også tilfelle for pakken +sharutils. Vi skriver derfor: + ++ $ ./configure --prefix=/store + + +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 cc, men man vet jo aldri hva som +kommer til å hende over natten. En enkel måte å spesifisere dette på, +er å kjøre configure på følgende måte: + ++ $ CC=cc ./configure --prefix=/store + + +Etter at configure har kjørt ferdig behøver man +forhåpentligvis bare å starte make. Programpakken burde +da kompilere seg ferdig uten problemer. + ++ $ make + + +

Spesifisering av bibliotek

+ +Dersom du spesifiserer søkestien for bibliotek som skal benyttes under +kompileringen (opsjonen -L til cc eller ld), så bør stier +som er mest mulig standard spesifiseres. Å spesifisere f.eks. +``-L/usr/local1/lib'' er mao. en lite lur ting å gjøre -- +dette for at programmet da sansynligvis bare vil fungere på tklaben. +Katalogen /usr/local1 eksisterer nemlig ikke andre steder +på installasjonen. + +

Å benytte /usr/local i store er generelt sett +lite ønskelig. Grunnen til at vi vil konvertere til store er +jo bl.a. fordi vi ønsker å gå bort ifra et uoversiktlig +/usr/local-system. Å gjøre appliksjoner i store +avhengig av /usr/local gjør ikke denne konverteringen +enklere. + + +

+
eSk
+ + diff --git a/store/doc-espensk/index.html b/store/doc-espensk/index.html new file mode 100644 index 0000000000..4cca29b38f --- /dev/null +++ b/store/doc-espensk/index.html @@ -0,0 +1,24 @@ + + Store + + + +

Store

+ +
    +
  • Installering i Store
    + Detaljert instruksjon om hvordan man installerer applikasjoner + under store. Dokumentasjonen er spesielt tilpasset + lokale preferanser. + +
  • Store-dokumentasjon fra PVV.
    + En nokså spinkel dokumentasjon, men inneholder en god introduksjon + til selve store-konseptet. Dette er samme dokumentasjon som + finnes under /store/doc/store-doc/, og som kan + aksesserer fra emacs-info-sidene. +
+ +
+
eSk
+ + \ No newline at end of file diff --git a/store/doc-espensk/install.html b/store/doc-espensk/install.html new file mode 100644 index 0000000000..5dd62d4417 --- /dev/null +++ b/store/doc-espensk/install.html @@ -0,0 +1,28 @@ + + Installerting i store + + + +

Installering i store

+ +Den enkleste måten å forstå hvordan kompilering i store foregår, er +ved å benytte et eksempel. I dette tilfellet benytter vi GNU Sharutils. + + + +
+
eSk
+ + diff --git a/store/doc-espensk/mailcap.html b/store/doc-espensk/mailcap.html new file mode 100644 index 0000000000..3d8754070e --- /dev/null +++ b/store/doc-espensk/mailcap.html @@ -0,0 +1,91 @@ + + Mailcap-konfigurering + + + +

Mailcap-konfigurering

+ +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. metamail og +netscape. + +

For å få dette til, lager en del applikasjoner mailcap-filer som +den benytter seg av. Metamail lager f.eks. en fil +``/store/etc/mailcap'', og netscape lager en +fil ``/store/lib/netscape/mailcap''. Disse filene +genereres ut ifra innholder av filene som finnes under: + +

+ /store/etc/mailcaps +
+ +I denne katalogen eksisterer en del filer med navn på formen: + +
+ mailcap-<navn>-<prioritet> +
+ +Hver av disse filene inneholder én eller flere mailcap-entryer +som tilsammen bygger opp den fullstendige mailcap-filen. +``Navn'' forteller hvilken applikasjon de aktuelle +mailcap-entryene gjelder for (f.eks. xv eller +xanim). ``Prioritet'' forteller hvilken +prioritet disse mailcap-entryene har. Vi har f.eks. en fil, +``mailcap-arena-9'', som inneholder: + ++ text/html; /store/bin/arena %s + + +og en fil, ``mailcap-netscape-4'', som inneholder + ++ text/html; /store/bin/netscape -remote openFile\\(%s\\) + + +Begge mailcap-entryene gjelder for content-typen; +``text/html''. Netscape sitt mailcap-entry blir derimot +foretrukket fordi den har bedre prioritet. + +

Flere felter kan også spesifiseres i mailcap-entryen. De +applikasjonene som ikke forstår dette (f.eks. netscape), +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 +frame hadde muligheten til å håndtere PDF-dokumenter. +Dersom vi ga argumentet ``-savepdf'' til +imaker, ville dokumentet bli lagret i PDF-format. Vi +kunne da hatt følgende situasjon: + +

``mailcap-acroread-5'' inneholder: + +

+ application/pdf; /store/bin/acroread %s ; \ + description = "Portable Document Format" + + +``mailcap-frame-9'' inneholder: + ++ application/pdf; /store/opt/frame5/bin/imaker -run_in_fg -f %s ; \ + compose = /store/opt/frame5/bin/imaker -run_in_fg -savepdf -f %s + + +Siden acroread har prioritet 5, og imaker +prioritet 9, ville acroread bli benyttet fremfor +imaker for å vise PDF-dokumenter. Imaker er +derimot alene om å kunne lage PDF-dokumenter, og den resulterene +mailcap-entryen ville derfor bli: + ++ application/pdf; /store/bin/acroread %s ; \ + description = "Portable Document Format" ; \ + compose = /store/opt/frame5/bin/imaker -run_in_fg -savepdf -f %s + + +
+
eSk
+ + diff --git a/store/doc-espensk/post-install.html b/store/doc-espensk/post-install.html new file mode 100644 index 0000000000..3ae9853406 --- /dev/null +++ b/store/doc-espensk/post-install.html @@ -0,0 +1,303 @@ + + Arbeid etter kompileringen + + + +

Arbeid etter kompileringen

+ +
    +

  1. Make install

    + Når du har kompilert ferdig programpakken i skyggetreet, gjenstår + det bare å installere pakken. Dette består som oftest i å skrive: + + + $ make install + + + Dersom du har konfigurert makefilene riktig, eller kjørt + configure med korrekte argumenter, vil binærfiler, + bibliotek, manualer, etc. bli installert under + /store/bin, /store/lib, + /store/man, osv. + +

  2. Postinst

    + Disse filene må nå flyttes over til versjonstreet, og symbolske + lenker fra linktreet til versjonstreet må opprettes. Kommandoen + postinst gjør dette for deg. + + + $ postinst + Architecture suffix [hp700ux9] ? + Server [tklab1] ? + Application [sharutils] ? + Version [4.2] ? + Linktree [tklab1] ? + + + Som ved shadow-kommandoen, blir du også her konfrontert + med en del spørsmål. Og som ved shadow-kommandoen, vil + default-verdiene som regel være korrekte. + +

    Hva postinst-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, + +

    + /store/<filsti>, +
    + + vil den flytte denne til sin respektive plass i versjonstreet, + +
    + /store/store/tklab1/<applikasjon>/ver-<versjon>/<filsti>. +
    + + En symbolsk lenke blir så opprettet fra linktreet til denne filen. + +

    Postinst sjekker også (ved å benytte kommandoen + file), 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 + sharutils vil f.eks. følgende to symbolske lenker bli + opprettet. + +

    + /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 + + + Ved enekelte anledninger ønsker du kanskje å installere filer som er + eldre enn 10 minutter fra linktreet. Dette kan du gjøre ved å gi + argumentet ``-t <minutter>'' til + postinst. Du spesifiserer da en maksimalalder på + filene du ønsker å installere, gitt i minutter. Dette er særlig + nyttig for programpakker som benytter tar for å + installere filene sine i linktreet (f.eks. emacs). + Modifikasjonsdatoen til de installerte filene blir da uendret, og + filene kan bli flere år gamle. + +

  3. Spesielle konfigureringer

    + 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 ``Spesielle konfigureringer'' for + nærmere informasjon. + +

  4. Register

    + Når du har gjort deg ferdig med installeringen, må du registrere + applikasjonen slik at de interne programmene i store 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 + register: + + + $ register + What store [tklab1] ? + What application [sharutils] ? + (Info) (register) <sharutils@tklab1> Updating registration. + + (Warning) (register) <sharutils@tklab1> YOU MUST RUN chkapp MANUALLY. + + Full name . ... ... [] ? Shar utilities + + Available versions are: 4.2 - choose primary: + Primary Version ... [4.2] ? + Program Type .. ... (? for list) [] ? arc + License Type .. ... (? for list) [] ? gpl + Release level for version 4.2 [release] ? + Signature . ... ... [] ? eSk + Short Description . (max 30 chars) [] ? + ==>Shell archiving utilities <== + XXX - fix sourcecode count (TODO) + Online Help ... ... [none] ? + Importance ... ... [5] ? + Source ... ... ... [] ? ftp://prep.ai.mit.edu/pub/gnu/sharutils-${version}.tar.gz + Nightly Command ... [] ? + Not Links . ... ... [] ? + Dependencies .. ... [] ? + Current description is: + : + Do you want to edit the description [N] ? y + Enter text to be appended (terminate with '.') + Husk å fikse emacs-info-sidene. + . + + + 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: + +

    +
    Full name, Short Description og Description +
    Bør være skrevet på engelsk. Det er planer om å lage et + web-grensesnitt mot store, 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. + +

    Short description blir forresten brukt til + bl.a. generering av rapporter. Description blir benyttet + til bl.a. generering av news-meldinger. Et eksempel på en slik + description kan være: + +

    + 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. +
    + +
    Release level +
    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 release levels forteller + hvordan hver profilering prioriterer utgivelsene): + +

    Newer: override alpha beta gamma release stable + dated old obsolete prealpha +
    Normal: override stable release gamma dated beta + old alpha obsolete prealpha + +

    For tklabben benyttes newer, og for resten av + installasjonen benyttes normal. Prioriteten av + release levels ovenfor bestemmer hvilken versjon som skal + installeres av en gitt applikasjon. + +

    Eks: Vi har versjon 1.4 av en applikasjon installert i + store, og denne versjonen er satt til relase level, + ``release''. Vi installerer nå versjon 2.001 av samme + applikasjon, og setter release level til ``beta''. Dette + vil føre til at versjon 2.001 vil bli installert på tklaben, mens + versjon 1.4 blir installert andre steder.

    + +

    Importance +
    Forteller hvor viktig applikasjonen er. Jo høyere tall, jo viktigere + er applikasjonen. Perl-internal har + f.eks. importance 9 fordi hele store baserer seg + på dette filsettet. + +

    Foreløpig blir ikke dette feltet meget benyttet. Et unntak er + noen lokale patcher til perl-internal som gjør at + dersom det skjer en konflikt i navnerommet (eks. to filer som + heter /store/etc/config), så vil kun det viktigeste + filsettet få filen installert.

    + +

    Source +
    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. Store kan også + konfigureres slik at denne nye pakken automatisk blir hentet. + +

    På grunn av at dette feltet skal benyttes internt av + store, 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: + +

    + prep.ai.mit.edu:/pub/gnu/sharutils-${version}.tar.gz +
    + + 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. +

    + +

    Nightly command +
    Spesifiserer en kommando som blir kjørt hver natt (fra skriptet + cclient), og hver gang en linkup 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. + +

    Envirnoment-variabelen $TOPDIR 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 /store). For å starte et perlskript i + linktreet hver natt, kan man derfor spesifisere f.eks.: + +

    + perl $TOPDIR/etc/make-emacs-dir.pl +
    + + Flere kommandoer kan dessuten spesifiseres ved å skille dem med + ; (semikolon). +

    + +

    Not Links +
    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 nightly command, og spesifiseres som et + perl regular expression med filnavn relativt til + linktre-rota. Applikasjonen perl-internal genererer + f.eks. news-meldinger under /store/news, og har + derfor følgende notlinks regexp: + +
    + news/.* +
    + + Dette forhindrer at filene under /store/news blir + slettet av cclient, eller kopiert opp i et eller + annet versjonstre av postinst. Flere notlinks + regexp kan gis ved å separere dem med mellomrom (space). +

    + +

    Dependencies +
    Gir en liste (separert med mellomrom) av applikasjoner som den gitte + applikasjonen er avhengig av. Exmh er + f.eks. avhengig av MH, Tcl og Tk. Dette fordi exmh + 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 exmh bli installert. + +

    Det er selvfølgelig bare mulig å spesifisere applikasjoner som + faktisk ligger i store i dependency-listen. Det + vil ellers være vanskelig for store-programmene å vite om + den aktuelle applikasjonen faktisk eksisterer på systemet. + +

    Det er ikke mulig å spesifisere versjonsnummer for + appliksjonene, og applikasjonsnavnene må samsvare nøyaktig med + navnet som applikasjonen har i store. Navnene er også + case-sensitive, slik at ``Tcl'' ikke er det samme som ``tcl''. + Exmh har f.eks. følgende dependency-liste: + +

    + mh tcl tk +
    + +
    + + +

  5. Chkapp

    + Etter at register er kjørt, må chkapp + kjøres for å oppdatere listen over hvilke versjoner av applikasjonen + som eksisterer, samt hvilke arkitekturen hver versjon har støtte for. + + + $ chkapp + Which master [tklab1] ? + Which application [sharutils] ? + + + Chkapp 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 + summary.<versjon> 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. + +
+ +
+
eSk
+ + diff --git a/store/doc-espensk/pre-install.html b/store/doc-espensk/pre-install.html new file mode 100644 index 0000000000..c97005d923 --- /dev/null +++ b/store/doc-espensk/pre-install.html @@ -0,0 +1,128 @@ + + Forberedelse til kompilering i store + + + +

Forberedelse til kompilering i store

+ +
    +
  1. 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. + +

    Hvis du kompilerer for HP-UX 10, må du passe på at transition + linkene ikke er aktive. Prøv f.eks. å kjøre `ll + /etc'. Dersom du her ser en hel mengde lenker, så er lenkene + i bruk. Disse fjernes ved å kjøre kommandoen + tlremove (må kjøres av root-brukeren). + +

    Vi har her tenkt å kompilere applikasjonen for HP-UX 9, og velger + derfor å kompilere dette på tklab1. + +

    + $ rlogin tklab1 + + +

  2. Når man skal arbeide med installering i store, lønner det + seg å være logget inn som store-brukeren. Siden + store-brukeren ikke har passord, må vi først logge inn som + root. + + + $ su - + Password: + $ su - store + + +

  3. Dersom en eller annen versjon av applikasjonen ikke eksisterer + i store fra før, må der lages en plass for den i + store-treet. Dette gjøres under ved å lage en katalog + under /store/store/tklab1 med et fornuftig navn. I + vårt tilfelle velger vi å kalle applikasjonen + sharutils. + + + $ mkdir /store/store/tklab1/sharutils + $ cd /store/store/tklab1/sharutils + + +

  4. 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 (`tar tf -'). Dersom dette siste er tilfellet, vil + det være meget lurt å pakke opp applikasjonen i en underkatalog. + + + $ gzip -dc ~/tmp/sharutils-4.2.tar.gz | tar xf - + + +

  5. Navngi underkatalogen slik at de interne programmene i store + forstår hva det er som foregår. Navnet på katalogen som inneholder + kildekoden skal være på formen ``src-<versjon>''. + + + $ mv sharutils-4.2 src-4.2 + + +

  6. 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 + ``src-<versjon>-<arkitektur>''. Disse + katalogene inneholder symbolske lenker inn i katalogen hvor den + virkelige kildekoden befinner seg. Et slikt skyggetre + lages med kommandoen shadow. + + + $ shadow + Which compile store [tklab1] ? + Which application [sharutils] ? + What version [4.2] ? + What architecture [hp700ux9] ? + + + Som vi ser, får vi en del spørsmål når vi kjører + shadow. 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. + +

    Et par ord om arkitekturnavnet er kanskje på sin plass her. Vi + ser av ekempelet over at HP-UX 9 presenteres ved navnet + ``hp700ux9''. I likhet presenteres HP-UX 10 med navnet + ``hp700ux10''. Dette betyr at arkitekturen en HP + Series 700 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. ``hp700ux905'' og ``hp700ux1001''). + +

    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 ``hp700ux9'' og ``hp700ux10'' + (f.eks. en binærdistribusjon av Netscape), kan vi derfor benytte + arkitetkturnavnet ``hp700''. På samme måte kan vi + benytte arkitekturnavnet ``allarchs'' til å bety alle + mulige arkitekturerer. Dette er f.eks. nyttig for applikasjoner som + er skrevet i et abstrakt, arkitekturuavhengig språk + (eks. exmh). + +

    Arkitekturnavnet ``local'' 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. ``hp700ux9'', så vi + dette local-treet bli skygget -- ikke det uberørte, + orginale kildekodetreet. + +

  7. Vi er nå klar til å ta fatt på selve kompileringen. + + + $ cd src-4.2-hp700ux9 + + +
+ +
+
eSk
+ + diff --git a/store/doc-espensk/spec-config.html b/store/doc-espensk/spec-config.html new file mode 100644 index 0000000000..ac267c06a4 --- /dev/null +++ b/store/doc-espensk/spec-config.html @@ -0,0 +1,24 @@ + + Spesielle kofigureringer + + + +

Spesielle konfigureringer

+ +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. + + + +
+
eSk
+ + diff --git a/store/httpstore.html b/store/httpstore.html new file mode 100644 index 0000000000..1d52bf7c2d --- /dev/null +++ b/store/httpstore.html @@ -0,0 +1,16 @@ +
+Automatic software distribution via HTTP +

+ +STORE in WWW. +

+ + +Automatisk oppgradering av web-browsere +

+ +.../storetar/info?app=sdf +

+ +.../storetar/list?arch=linux +

diff --git a/store/httpstore/httpstore-0.1.tar.gz b/store/httpstore/httpstore-0.1.tar.gz new file mode 100644 index 0000000000000000000000000000000000000000..ddfc894de8e6f1aa454f0b7df901eef71af490e8 GIT binary patch literal 1216 zcmV;x1V8&9iwFqPJEJfF188(~aC3BTa%C+rE-@~2VR8WNS8Y$*ND$_0{VS%%K%&EM zAx=b05fsrB>B6BvD;>ujHO?k>@!Q#J0$1|iZ)RqvSOHq(YCB5!!XQt%cQ4aHk;x}L#v6pmSGvKM#E?{mT1aqwU&$* z&SS3R85L|82}{}2b}Y@F(2G)CKu69_ukzfM4r(EFnk4FZ-zJcQ8k1J_BwNs_>K9qz}G zeyvs!fyXfLGoJbvIcIQu@>_p@)-=Ol@fAk$aF1&EzJNqn%br%Nj0TfvJUTHXSd(|Y*VH^>^(TH%MuRiKO!CG#$l4O zEQ6ZQH0U0F0&>$N(XzNdzI z#Ku@E8u~-1!CO!VAUx{uO#+ngl77+DIvDMC+ms50UAG5^xUqoWpr$d+)`31Fc z!lGJ#zq=0d7Nl%MFbh!Sx?Ly_3+?tjt%hll#n|%$2DL4;*{(98MD-(wdjwP#I9E(3 z)f?A~6I*(toP&nt!nDM*2&*HY51>c(1e!)W*B?75}_g!KpRh-m@;BMqI2 zRkju*XiCxJpMA)m5N~?_mxuKStU>pGtGMsy-T#JZwyXQ!Y?}0*Fq^H0wYdLZLFQl0 zHeBPL4ngHU56Y{V?irPV?!|ae2`zB}&b%RDCHpV$^o7imyYv5p$lubl{IAj2nDRff z-4N&BGTP0>`F{m@n*ZG+f8sMs0FBL#Wpy^J2Ly1hd!Qz1JW8GLS&DZ@@E+%P&(XVO zIEe>w2cMuq&$(paq^{?4=JGscDrd;@#&LQnNqLlc{*c#T=iqP;-_LrUrFsy%PN0v+ zW8EG3D#9Qm3A2es{GIz)mrT=vf1xFT4Bzv{Q>t;w8V3${=2AzLN7-X<_xNOAu*)fX zT!t>=1(FWp$PkoFTJ1AuaO9*JBmRdlqKo23-_~%rHo-uIWjTdIF-1^RRyd@&`9!8j zLWbL0>=;&k7+3AOLSo=t1gs*fNL5Q_Gi9q~#ES1s?hNPI6&wzU8d-_dveaFhR7O>o zc0L^Zx_^vqLalmdM*MVAGTh@&z20vBcfoSAJPe)mMk5qvIc#aOeU}6ART?QnvOw6; zLnSv|IWKu6E;o!(HTAZqzJ<=7o2rOd7ucquO89kqlkkc*)?-(GVM`X+C3f8L&dKm zy*h1(aga e(+Ff!?4qB2IWA-&3t7njSpEg!5%$FZ761TWRbajV literal 0 HcmV?d00001 diff --git a/store/httpstore/httpstore-0.2.tar.gz b/store/httpstore/httpstore-0.2.tar.gz new file mode 100644 index 0000000000000000000000000000000000000000..e4179e88e8ae58d889943db91e56a7a8497dca9e GIT binary patch literal 2164 zcmV-)2#fb0iwFqNV(%~j188(~aC3BTa%C+rE;253VR8WN7;978NHSloU(qWZZ0Bq} zz{VHbIFQ5vssf=LHdV>8msRAktsqNUX#{2y-@m>8aosZ`*#-l9cOBsbY zrf1A~l<+WSHOtsAAAOTyS#_(~XyDhfn_D)0ExTS9Uo{?CTUK*(Ys=o;z`12_ZdvxD z#=U^K)*iWBsnU-x@O|TlR`bMj60a*xo z(+G-Cds2fFHsv(Yw3D%y0RA}vuqk4B6BcmC2X7MjOw73#1`rP6?a7;d50Y@mFC1hx z@Dd(-pHc#A=bi)mCnv{-ro9hSNXB964`Ap81K?u@zQb9<;T*j{%pBg*04RD}rg?F3 zVeo+w#v>#3xDkZrKS@|K4{lA{^?gXv(Fl1UImtSJG#bUufJxc?3+FO{3+B7wgrN+_ zjB^%4pLxMJ^ang)0d$D#&eBfWk9OeyIF|EY%qSo3bx{7_Qvb0uT&w?$&F1Dq{(pzD z_LFqF`N<1Rw1Ka!!MrA9@gS-~bEzt9wXBU+WAkcNI7Sw-Dioub4ZZ1hNp4VTYs7l* zpccg;=G_E%I4=N9l?Eq@e9v`cj)s`*BE^yL`6c|xjOsZQl#h z=_;_IpW|q0kc_<{FT>8k(TghRW||;s=sG^tH`5(?HT01V6=+|>Rkk)6cTqaDQsDR! zQ;XT}sfRAoiGlBZG9rX5uH%~NhQV;?`Ah+?!MxEb$cP1`K(dl$nDQv)tH@$DA_J@< z!jr(y*{#7LCMP(q%OX5!K2X45aYj{>1O^UwpzJXN_KtoAv}(oBiYL2$z_E?SlR-TS zQW4k)*V|fga+zXu3b-<7?i2*?OfE6U>3~6uvYtd~e6CmJcSEnBMC+xPIfG1Xlu<5Z z)+_5pX)Ik>zE~oL{t&sXPcA18#$CY50))ElF)p*g!CYYIvP4_&BeP>CP8d;RY$0XQ z3%-LSW99zL&K?9^4U4_x5bi}O4=cAD;LF7EJh9=6Ls(C z-Ivnw?#ceggQHh(2&8#KC`&l|9Zi^rF{=ATBg3yxFvDKsav7~f3vBA~wl))UO&f+W z6s3s)Lw9cOjGi`tpP)9JN3`^#qB6-SDt=;7By?C`*9y0h7%OOKze0fb7b)dzzWIN& zwO~W*1CRW23n4~V!FQ5;znLag&4@Dt+-jl1o#wewSK=-8EzC5<=)Yuhr@ls}Fkwrj z3$t8rsrXgB-7)>r)iM(29-&~KD_+>)zYybwnXY;YKvQ zl6hyoIqD<$hY<_PZ+|{K-0iWGzdd*z8GTxfO1D6b#t-YaTqCM6sbs% z;gG0S6tVF!GgOfd6@=vs+H-OVY_C>RFs%r2vC2>lD2t+yL2goe$-QKTD;h1BqWBdB zvz1fUV2o9Y$`$>JVmxj@e-YxL6Yv_pj96>&5I3i_tiqlKr-9y9JS5%vF@5$0KgFI+ znTvH4D>(_}ei+iHhX17C75Mr!+w^%j3e!YT2+oTFy+YNK)+uTBIrM_EE~bhHRU|D* zKS5TmKwC^dl6OV+Wgfm7_2TnnDP88?UjtFkVG&v*zesSoIKc#AaaCkQ1_lNFh!|VLX?uE!Q&tdMgg8crCC)g6a)<{ zfK|VB15`>c?{~AxLZZ)IvBJj+KykF}wa)%Vm;Axx)ekQNqt7fDG2a`3x;36--`Ft` z4;`vyPGfks0-j9nnKMEcC1K3rjA1+XSXdQ(Q7&eBqV7s3oGr+Y#+Md@1f!Ri&6ZhJ z)>Djyf;k_$Bg}t1gZaD#`Y##HucA0)>OJpwJG-#o@4ebS)#YtOTp=^;)Ae&Ykd=I= zdN*gWB9`aGGIjLjX-pNF?72dcy_R|S-Q=c6({W@j1)pxb&*Nv=^jkwH8A zCx@@m>Ye@G?#nK^fIj&1`J0#T$r)8m1_vVA-QHOe$!7qDeYd>YXZ<~r+Din7=xQo( zF?!=Ow)Vq+B`}N~SYVkO?awy+CK_*yK{Pn?`~eHde1@>tOz1~ux~iY4G(q{KrULs% z_h;XFEcgEtw2SLR_q@kl?|-)4yw?BQ8(RJ0Ad%S^flQ-24W3=OduH z7}FyW-FtTXd+)A4Fa06JVfh2os<)+E9+u=ya$CI`(ff^Rk`;mK7BWOLU>CAY&YJoG z6c;<<$r=5kr7Bp>W|QtBvP-5l;*U}y|KEgQ(+@+)mHZ8%qG9d#_C&L~)av1VQ~-}8 zw7Uc~P%Og8dL6{+EfWb9RRU6X;Ee zZn>tqtLMFtS^ni8=C6ON6tUqc$W|C(^BeVE$i>RSUNd@96!-9JEiML(v9#7+i7Je6 qwL?amsz-{|4qf1-T#FpCr;s0= literal 0 HcmV?d00001 diff --git a/store/storepaper.ps b/store/storepaper.ps new file mode 100644 index 0000000000..40e4b8545c --- /dev/null +++ b/store/storepaper.ps @@ -0,0 +1,12637 @@ +%!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 df45 +DI<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 DI<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>III107 +DIII<000FF80000003FFE000000FFFF800003FFFFE00007FFFFF0000FF80F +F8001FE003FC001F8000FC003F00007E003F00007E007E00003F007E00003F007C00001F +00FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80FC00001F80 +FE00003F807E00003F007E00003F007F00007F003F8000FE001FC001FC001FE003FC000F +F80FF80007FFFFF00003FFFFE00000FFFF8000003FFE0000000FF8000021217EA026>I< +FC03F800FC3FFE00FCFFFF00FDFFFF80FFFFFFC0FFE07FE0FF801FF0FE0007F0FC0007F8 +FC0003F8FC0001F8FC0001F8FC0001FCFC0000FCFC0000FCFC0000FCFC0000FCFC0000FC +FC0000FCFC0000FCFC0001FCFC0001F8FC0001F8FC0003F8FE0007F0FF000FF0FF801FE0 +FFE07FC0FFFFFFC0FDFFFF80FCFFFE00FC3FFC00FC07F000FC000000FC000000FC000000 +FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000 +FC000000FC000000FC0000001E307AA028>I114 D<00FFC00007FFF8001FFFFE003FFFFE003F +FFFE007F007C00FE000C00FC000000FC000000FC000000FC000000FE0000007FC000007F +FE00003FFFC0001FFFF0000FFFF80003FFFE00007FFE000003FF0000007F8000003F8000 +001F8000001F8040001F8060001F8078003F00FF00FF00FFFFFE00FFFFFC007FFFF8000F +FFF00001FF800019217EA01D>I<03F00003F00003F00003F00003F00003F00003F00003 +F00003F00003F000FFFFFEFFFFFEFFFFFEFFFFFEFFFFFE03F00003F00003F00003F00003 +F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003F00003 +F00003F00003F00003F00003F00003F80203FC1E01FFFF01FFFF00FFFF007FFC003FC018 +2B7FAA1C>I +II<7E00003F +003F00007F001F8000FE001FC000FC000FE001F80007E003F00003F007E00001F80FE000 +00FC0FC000007E1F8000007F3F0000003F7E0000001FFC0000000FF800000007F8000000 +03F000000003F000000007F80000000FFC0000001FFC0000003F3E0000003E1F0000007C +1F800000FC0FC00001F807E00003F003F00007E003F00007E001F8000FC000FC001F8000 +7E003F00007F007F00003F80FE00001FC0222180A023>120 DI 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>I45 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 DI<0000001FFE0000C0000003FFFFC001C000001FFFFFF0 +07C000007FFFFFFC0FC00001FFFC00FF1FC00007FFC0001FBFC0001FFF000007FFC0003F +FC000001FFC0007FF0000000FFC000FFE00000007FC001FFC00000003FC003FF80000000 +3FC007FF800000001FC007FF000000000FC00FFF000000000FC00FFE0000000007C01FFE +0000000007C01FFC0000000007C03FFC0000000003C03FFC0000000003C07FFC00000000 +03C07FFC0000000003C07FF80000000000007FF8000000000000FFF8000000000000FFF8 +000000000000FFF8000000000000FFF8000000000000FFF8000000000000FFF800000000 +0000FFF8000000000000FFF8000000000000FFF8000000000000FFF8000000000000FFF8 +0000000000007FF80000000000007FF80000000000007FFC0000000000007FFC00000000 +03C03FFC0000000003C03FFC0000000003C01FFC0000000003C01FFE0000000003C00FFE +0000000007800FFF00000000078007FF00000000078007FF800000000F0003FF80000000 +1F0001FFC00000001E0000FFE00000003C00007FF00000007800003FFC000000F000001F +FF000003E0000007FFC0000FC0000001FFFC007F800000007FFFFFFE000000001FFFFFF8 +0000000003FFFFE000000000001FFE0000003A3B7BB945>II70 +D72 D +I76 DII<000000FFF800000000000FFFFF80000000007FFFFFF0 +00000001FFC01FFC00000007FF0007FF0000001FFC0001FFC000003FF000007FE000007F +E000003FF00000FFC000001FF80001FF8000000FFC0003FF8000000FFE0007FF00000007 +FF0007FF00000007FF000FFE00000003FF800FFE00000003FF801FFC00000001FFC01FFC +00000001FFC03FFC00000001FFE03FFC00000001FFE03FFC00000001FFE07FF800000000 +FFF07FF800000000FFF07FF800000000FFF07FF800000000FFF0FFF800000000FFF8FFF8 +00000000FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000 +FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000FFF8FFF800000000FFF8FFF8 +00000000FFF8FFF800000000FFF87FF800000000FFF07FFC00000001FFF07FFC00000001 +FFF07FFC00000001FFF03FFC00000001FFE03FFC00000001FFE03FFE00000003FFE01FFE +00000003FFC01FFE00000003FFC00FFF00000007FF8007FF00000007FF0007FF8000000F +FF0003FFC000001FFE0001FFC000001FFC0000FFE000003FF800007FF000007FF000003F +FC0001FFE000001FFF0007FFC0000007FFC01FFF00000001FFFFFFFC000000007FFFFFF0 +000000000FFFFF800000000000FFF80000003D3B7BB948>II82 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>III<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>IIIII<3FFFFFFFC03FFFFFFFC03FFFFFFFC0 +3FF001FF803F8003FF003F0007FF003E0007FE003C000FFC007C001FF8007C001FF80078 +003FF00078007FE0007800FFE0007800FFC0007801FF80000003FF00000007FF00000007 +FE0000000FFC0000001FF80000003FF80000003FF003C0007FE003C000FFC003C001FFC0 +03C001FF8003C003FF0007C007FE0007C007FE0007C00FFC000F801FF8000F803FF8001F +803FF0007F807FE001FF80FFFFFFFF80FFFFFFFF80FFFFFFFF8022257DA42A>I +E /Fj 49 122 df45 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 DI<00000000FFF8000030000000 +1FFFFF000070000001FFFFFFE001F0000007FFFFFFF803F000003FFFE003FE07F000007F +FE00007F0FF00001FFF000001F9FF00003FFC0000007FFF0000FFF00000003FFF0001FFE +00000000FFF0003FFC000000007FF0007FF8000000007FF000FFF0000000003FF001FFE0 +000000001FF001FFC0000000000FF003FFC0000000000FF007FF800000000007F007FF80 +0000000007F00FFF000000000007F01FFF000000000003F01FFF000000000003F01FFE00 +0000000003F03FFE000000000001F03FFE000000000001F03FFE000000000001F07FFE00 +0000000001F07FFC000000000000007FFC000000000000007FFC00000000000000FFFC00 +000000000000FFFC00000000000000FFFC00000000000000FFFC00000000000000FFFC00 +000000000000FFFC00000000000000FFFC00000000000000FFFC00000000000000FFFC00 +000000000000FFFC00000000000000FFFC00000000000000FFFC000000000000007FFC00 +0000000000007FFC000000000000007FFC000000000000007FFE000000000000003FFE00 +0000000000F03FFE000000000000F03FFE000000000000F01FFE000000000000F01FFF00 +0000000000F01FFF000000000001F00FFF000000000001E007FF800000000001E007FF80 +0000000003E003FFC00000000003C001FFC00000000007C001FFE000000000078000FFF0 +000000000F00007FF8000000001F00003FFC000000001E00001FFE000000007C00000FFF +00000000F8000003FFC0000003F0000001FFF0000007E00000007FFE00003F800000003F +FFE001FF0000000007FFFFFFFC0000000001FFFFFFF000000000001FFFFF800000000000 +00FFF800000044467AC451>IIII73 D77 D<00000007FFC0000000000000FFFFFE000000000007FF +FFFFC0000000001FFE00FFF0000000007FF0001FFC00000001FFC00007FF00000007FF00 +0001FFC000000FFE000000FFE000001FFC0000007FF000003FF80000003FF800007FF000 +00001FFC0000FFE00000000FFE0001FFC000000007FF0003FFC000000007FF8003FF8000 +000003FF8007FF8000000003FFC007FF0000000001FFC00FFF0000000001FFE00FFF0000 +000001FFE01FFE0000000000FFF01FFE0000000000FFF03FFE0000000000FFF83FFE0000 +000000FFF83FFE0000000000FFF87FFE0000000000FFFC7FFC00000000007FFC7FFC0000 +0000007FFC7FFC00000000007FFC7FFC00000000007FFCFFFC00000000007FFEFFFC0000 +0000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC0000 +0000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC0000 +0000007FFEFFFC00000000007FFEFFFC00000000007FFEFFFC00000000007FFE7FFC0000 +0000007FFC7FFE0000000000FFFC7FFE0000000000FFFC7FFE0000000000FFFC3FFE0000 +000000FFF83FFE0000000000FFF83FFE0000000000FFF81FFF0000000001FFF01FFF0000 +000001FFF01FFF0000000001FFF00FFF8000000003FFE00FFF8000000003FFE007FFC000 +000007FFC003FFC000000007FF8003FFE00000000FFF8001FFE00000000FFF0000FFF000 +00001FFE00007FF80000003FFC00003FFC0000007FF800001FFE000000FFF000000FFF00 +0001FFE0000007FFC00007FFC0000001FFF0001FFF00000000FFFE00FFFE000000003FFF +FFFFF80000000007FFFFFFC00000000000FFFFFE00000000000007FFC000000047467AC4 +54>79 DI82 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>II87 +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>II120 DI +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 DI<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 DI<000003FE000C0000 +3FFF800C0000FC01E01C0003F000783C000FC0001C7C001F0000067C003E000003FC00FC +000001FC01F8000000FC01F0000000FC03F00000007C07E00000003C0FE00000003C0FC0 +0000003C1FC00000001C3F800000001C3F800000001C3F800000000C7F800000000C7F80 +0000000C7F000000000CFF0000000000FF0000000000FF0000000000FF0000000000FF00 +00000000FF0000000000FF0000000000FF0000000000FF0000000000FF0000000000FF00 +000000007F00000000007F800000000C7F800000000C3F800000000C3F800000000C3F80 +0000000C1FC0000000180FC0000000180FE00000001807E00000003003F00000003001F0 +0000006001F80000006000FC000000C0003E00000180001F00000700000FC0000E000003 +F00038000000FC01F00000003FFFC000000003FE00002E357CB337>IIII<000003FE000C0000003FFF800C000000FC01E01C000003F000 +783C00000FC0001C7C00001F0000067C00003E000003FC0000FC000001FC0001F8000000 +FC0001F0000000FC0003F00000007C0007E00000003C000FE00000003C000FC00000003C +001FC00000001C003F800000001C003F800000001C003F800000000C007F800000000C00 +7F800000000C007F000000000C00FF000000000000FF000000000000FF000000000000FF +000000000000FF000000000000FF000000000000FF000000000000FF000000000000FF00 +0000000000FF000000000000FF000003FFFFE07F000003FFFFE07F80000007FE007F8000 +0001FC003F80000001FC003F80000001FC003F80000001FC001FC0000001FC000FC00000 +01FC000FE0000001FC0007E0000001FC0003F0000001FC0001F0000001FC0001F8000001 +FC0000FC000001FC00003E000003FC00001F0000067C00000FC0000C7C000003F000383C +000000FC01F01C0000003FFFC00C00000003FE00000033357CB33C>I73 D<007FFFFF007FFFFF00007FE000001FC000001FC000001FC00000 +1FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC00000 +1FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC00000 +1FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC000001FC00000 +1FC000001FC000001FC000001FC000001FC000001FC03C001FC07E001FC0FF001FC0FF00 +1FC0FF001F80FE003F807C003F0060007F0030007E001C00FC000F03F00003FFE00000FF +000020347DB227>IIIII<000007FC00000000007FFF +C000000001FC07F000000007E000FC0000001F80003F0000003F00001F8000007E00000F +C00000FC000007E00001F8000003F00003F0000001F80007F0000001FC0007E0000000FC +000FC00000007E001FC00000007F001FC00000007F003F800000003F803F800000003F80 +3F800000003F807F800000003FC07F000000001FC07F000000001FC0FF000000001FE0FF +000000001FE0FF000000001FE0FF000000001FE0FF000000001FE0FF000000001FE0FF00 +0000001FE0FF000000001FE0FF000000001FE0FF000000001FE0FF000000001FE07F0000 +00001FC07F800000003FC07F800000003FC07F800000003FC03F800000003F803FC00000 +007F801FC00000007F001FC00000007F000FE0000000FE000FE0000000FE0007F0000001 +FC0003F8000003F80001F8000003F00000FC000007E000007E00000FC000003F00001F80 +00001F80003F00000007E000FC00000001FC07F0000000007FFFC00000000007FC000000 +33357CB33C>II82 D<001FE0030000FFFC030001F01F0700078003CF000F0000FF001E0000 +3F001C00003F003C00001F007800000F007800000F007800000700F800000700F8000007 +00F800000300F800000300FC00000300FC00000300FE000000007F000000007FC0000000 +3FF00000003FFF0000001FFFF000000FFFFF000007FFFFC00003FFFFF00000FFFFF80000 +3FFFFC000003FFFE0000003FFE00000003FF00000000FF800000003F800000001F800000 +001FC00000000FC04000000FC0C0000007C0C0000007C0C0000007C0C0000007C0E00000 +07C0E000000780E000000780F000000F00F000000F00F800001E00FC00001C00FF000038 +00F3C000F000E0FC03E000C03FFF8000C003FE000022357CB32B>I<7FFFFFFFFFFE7FFF +FFFFFFFE7F800FF801FE7C0007F0003E780007F0001E700007F0000E700007F0000E6000 +07F00006600007F00006E00007F00007E00007F00007C00007F00003C00007F00003C000 +07F00003C00007F00003C00007F00003C00007F00003000007F00000000007F000000000 +07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000 +07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000 +07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000 +07F00000000007F00000000007F00000000007F00000000007F00000000007F000000000 +07F00000000007F00000000007F00000000007F00000000007F0000000001FFC0000001F +FFFFFC00001FFFFFFC0030337DB237>IIII<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>II +II<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 +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>II<000001FF80018000000FFFE0018000007FFFF803 +800001FF807E07800003FC000F0F80000FF000038F80001FC00001DF80003F8000007F80 +007F0000003F8000FE0000003F8001FC0000001F8003F80000000F8007F80000000F8007 +F000000007800FF000000007800FE000000003801FE000000003801FE000000003803FC0 +00000003803FC000000001807FC000000001807FC000000001807F8000000001807F8000 +00000000FF800000000000FF800000000000FF800000000000FF800000000000FF800000 +000000FF800000000000FF800000000000FF800000000000FF800000000000FF80000000 +0000FF8000000000007F8000000000007F8000000000007FC000000001807FC000000001 +803FC000000001803FC000000001801FE000000001801FE000000003800FE00000000300 +0FF0000000030007F0000000070007F8000000060003F8000000060001FC0000000C0000 +FE0000001800007F0000003800003F8000007000001FC00000E000000FF00001C0000003 +FC000780000001FF803E000000007FFFFC000000000FFFF00000000001FF800000313B7B +B93C>IIII<000000FF8000C000000FFFF000C000003FFFFC01C00000 +FF803F03C00003FC000787C0000FF00001C7C0001FC00000EFC0003F8000007FC0007F00 +00003FC000FE0000001FC001FC0000000FC003F800000007C003F800000007C007F00000 +0003C00FF000000003C00FE000000003C01FE000000001C01FE000000001C03FC0000000 +01C03FC000000000C07FC000000000C07FC000000000C07F8000000000C07F8000000000 +00FF800000000000FF800000000000FF800000000000FF800000000000FF800000000000 +FF800000000000FF800000000000FF800000000000FF800000000000FF800000000000FF +8000007FFFFF7F8000007FFFFF7F8000007FFFFF7FC00000003FE07FC00000001FC03FC0 +0000001FC03FC00000001FC01FE00000001FC01FE00000001FC00FE00000001FC00FF000 +00001FC007F00000001FC003F80000001FC003FC0000001FC001FC0000001FC000FE0000 +001FC0007F0000001FC0003F8000003FC0001FE000007FC0000FF00000E7C00003FE0003 +C3C00000FFC01F83C000003FFFFE01C000000FFFF800C0000000FFC00000383B7CB941> +III75 DIII<000003FF00000000001FFFE000000000FE01FC00000003F8007F00000007E0 +001F8000001FC0000FE000003F000003F000007E000001F80000FE000001FC0001FC0000 +00FE0003F80000007F0003F80000007F0007F00000003F800FF00000003FC00FE0000000 +1FC01FE00000001FE01FE00000001FE03FC00000000FF03FC00000000FF03FC00000000F +F07FC00000000FF87F8000000007F87F8000000007F87F8000000007F8FF8000000007FC +FF8000000007FCFF8000000007FCFF8000000007FCFF8000000007FCFF8000000007FCFF +8000000007FCFF8000000007FCFF8000000007FCFF8000000007FCFF8000000007FC7F80 +00000007F87FC00000000FF87FC00000000FF87FC00000000FF83FC00000000FF03FC000 +00000FF03FE00000001FF01FE00000001FE01FE00000001FE00FF00000003FC00FF00000 +003FC007F00000003F8003F80000007F0003FC000000FF0001FC000000FE0000FE000001 +FC00007F000003F800003F800007F000001FC0000FE0000007E0001F80000003F8007F00 +000000FE01FC000000003FFFF00000000003FF000000363B7BB941>II<000FF800C0003FFF00C000FFFF81C003F807 +E3C007C000F7C00F80003FC01E00001FC01E00000FC03C000007C07C000007C078000003 +C078000003C0F8000001C0F8000001C0F8000001C0F8000000C0FC000000C0FC000000C0 +FC000000C07E000000007F000000007F800000003FE00000003FFE0000001FFFE000000F +FFFE000007FFFFC00003FFFFF00001FFFFFC00007FFFFE00000FFFFF000001FFFF800000 +1FFFC0000001FFC00000003FE00000000FF000000007F000000003F000000003F8000000 +01F840000001F8C0000000F8C0000000F8C0000000F8C0000000F8E0000000F8E0000000 +F0E0000000F0F0000001F0F0000001E0F8000001E0FC000003C0FE00000780FF80000F00 +FBE0001E00F0FE00FC00E07FFFF800C00FFFE000C001FF8000253B7CB92E>83 +D<3FFFFFFFFFFFE03FFFFFFFFFFFE03FFFFFFFFFFFE03FC003FE001FE03E0001FC0003E0 +7C0001FC0001F0780001FC0000F0700001FC000070700001FC000070700001FC00007060 +0001FC000030600001FC000030600001FC000030600001FC000030E00001FC000038C000 +01FC000018C00001FC000018C00001FC000018C00001FC000018000001FC000000000001 +FC000000000001FC000000000001FC000000000001FC000000000001FC000000000001FC +000000000001FC000000000001FC000000000001FC000000000001FC000000000001FC00 +0000000001FC000000000001FC000000000001FC000000000001FC000000000001FC0000 +00000001FC000000000001FC000000000001FC000000000001FC000000000001FC000000 +000001FC000000000001FC000000000001FC000000000001FC000000000001FC00000000 +0001FC000000000001FC000000000001FC000000000001FC000000000001FC0000000000 +01FC000000000001FC000000000007FF000000001FFFFFFFC000001FFFFFFFC000001FFF +FFFFC00035397DB83C>II87 D<7FFFFE001FFFFC007FFFFE001FFFFC007FFFFE001FFFFC0000FFF00007FF8000 +003FC00001FC0000003FC00000F00000001FE00000E00000001FE00000C00000000FF000 +018000000007F800038000000007F800030000000003FC00060000000001FE000E000000 +0001FE000C0000000000FF001800000000007F003800000000007F803000000000003FC0 +6000000000001FC0E000000000001FE0C000000000000FF180000000000007F380000000 +000007FB00000000000003FE00000000000001FE00000000000001FE00000000000000FF +000000000000007F000000000000007F800000000000007FC0000000000000FFC0000000 +000000DFE00000000000018FF00000000000038FF000000000000307F800000000000603 +FC00000000000E03FC00000000000C01FE00000000001800FE00000000003800FF000000 +000030007F800000000060003F8000000000E0003FC000000000C0001FE0000000018000 +0FE00000000380000FF000000003000007F800000006000003F80000000E000003FC0000 +000C000001FE0000001C000000FE0000003C000000FF000000FE000000FF800007FF0000 +03FFC000FFFFE0001FFFFF80FFFFE0001FFFFF80FFFFE0001FFFFF8039397EB83E>I91 +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>IIIII<3FFFFFFC3FFFFFFC3F8001F83E0003F03C0007F0 +380007E030000FC070001FC070001F8060003F0060007F006000FE006000FC006001F800 +0003F8000003F0000007E000000FE000001FC000001F8000003F0000007F0006007E0006 +00FC000601FC000603F8000603F0000E07E0000E0FE0000C0FC0001C1F80001C3F80003C +3F00007C7E0003FCFFFFFFFCFFFFFFFC1F247EA325>I<01E0004007F800E00FFE01C01F +FF87803C3FFF00700FFE00E003FC004000F0001B0879B62A>126 +D E /Fo 28 125 df45 +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 +D69 D72 D80 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>II +121 D124 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 diff --git a/td-drift/950209.referat.html b/td-drift/950209.referat.html new file mode 100755 index 0000000000..7262613247 --- /dev/null +++ b/td-drift/950209.referat.html @@ -0,0 +1,52 @@ + + +Referat, møte i TD's driftsgruppe, Torsdag 9. Februar 1995 + + + +

Referat, møte i TD's driftsgruppe, +
9. Februar 1995

+ +Tilstede: Rune Braathen, Petter Reinholdtsen, Frode Fjeld, Per Harald Myrvang, Hans +Ole Rafaelsen, mm + +

Fordeling av arbeidsoppgaver for semesteret, pr. maskin: + +

+
hostname maskintype Ansvarlig +
PS/2 - Frode +
spurv SPARC - Hans Ole +
dc9 * MicroVAX - Michael +
HP3000 - Per +
minerva 386 - Petter +
+* dc9 er pr. nå ikke operativ + + +

Prioriterte oppgaver:

+ +
    +
  1. Nameserver for domain td.org.uit.no på spurv +
  2. eksportering av filsystemet v.h.a. STORE +
  3. IBM4019 printer i drift +
  4. w3-server på spurv +
+ + +

Andre oppgaver:

+ +

Rune renskriver og sender Benchmark-resultater for maskiner +tilhørende Nordix data og Cinet til de respektive. + +

Frode undersøker muligheter for konfigurert versjon av Doom for +spilling på videokanon under UKA-95. + +

Petter undersøker muligheter for større lokaler, samt spørsmål +rettet til EDB-utvalget angående Ether-kabel til TD-laben. + +

+
Rune Braathen
+ + + + diff --git a/td-drift/950330.referat.html b/td-drift/950330.referat.html new file mode 100755 index 0000000000..8f9a7b9982 --- /dev/null +++ b/td-drift/950330.referat.html @@ -0,0 +1,40 @@ + + +Referat, TD's driftsmøte, Torsdag 30, Mars. + + + +

Referat, møte i TD's driftsgruppe, +
Torsdag 30, Mars. 1995

+ +Tilstede: Rune Braathen, Hans Ole Rafaelsen, Per Harald Myrvang, mm. + +

1. Status for labben/maskinene (Hva er gjort siden sist)

+ +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 uten 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. + +

2. Utlevering av brukerlista til Informatikk/TK

+ +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. + + +

3. Eventuelt

+ +Rune Braathen vil forespørre Studieadministrasjonen ved fagområdet +Medisin om å donere noen utrangerte gamle 286-maskiner til TD's +maskinpark. + +
+
Rune Braathen
+ + + + diff --git a/td-drift/foreningstilgang.html b/td-drift/foreningstilgang.html new file mode 100644 index 0000000000..8153dad711 --- /dev/null +++ b/td-drift/foreningstilgang.html @@ -0,0 +1,35 @@ + + + + + + + + + +Petter Reinholdtsen +
1996-10-23 +
+

Om TD og andre foreninger

+ +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. + +

Hvis foreningen ønsker dette, så kan de få en URL på rot-nivå, slik +Studentsamfunnet og +Hoyre har fått det. + +

I tvilstilfeller avgjør TD-drift hva som skal gjøres. Foreningene +har klagerett til TD-styret som endelig avgjør saken. + +

+
Petter Reinholdtsen - +pere@td.org.uit.no
+ + + + diff --git a/td-drift/letter2.gif b/td-drift/letter2.gif new file mode 100644 index 0000000000000000000000000000000000000000..919d56ecede1e168461e562b6415eb90c2b2dbd5 GIT binary patch literal 92 zcmZ?wbhEHb6lIWPXkcLY|NlP&1B2pE7Dgb&paUX6G7L<{E&VG`zm;1w$3*2fkKOOm t52o=adS;f*O{kisJA0?$n~M{4A1&Q?!qn;2N0EKf8=87n$gnb40{|&iA`t)p literal 0 HcmV?d00001 diff --git a/td-drift/skjema.html b/td-drift/skjema.html new file mode 100644 index 0000000000..4a35657e2b --- /dev/null +++ b/td-drift/skjema.html @@ -0,0 +1,133 @@ + + + + +TDs Bruker-skjema, + +
+ + + +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. + +
+
+

Brukerkontrakt

+

Brukeropplysninger

+
    + +
    Fornavn + + + + + + + + + + + + + + + +
    Etternavn + + + + + + + + + + + + + + + + + + + + +
    Telefon + + + + + + + + +
    Brukernavn + + + + + + + + +
    + +NB! Brukernavn skal ideelt bestå av brukerens fornavn + første +bokstav av etternavnet.Eks: Svenn Høgda = svennh, Ali Baba = +alib. Kuriose brukernanvn som sohot4u, +fantomet o.l. er ikke tillatt. Brukernavnet kan bli +annerledes pga. navnekollisjoner. + +

    +

+
+

Oppsett

+
    + +
    Email-addresse + + + + + + + + + + + + + + + + + + + + +
    + +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.

+ +
+
    +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. +
+

+
+Sted, dato og signatur + + + + diff --git a/td-drift/tddb.gif b/td-drift/tddb.gif new file mode 100644 index 0000000000000000000000000000000000000000..a067946086924713f3aebbfeff50b8e63316aa67 GIT binary patch literal 9420 zcmV;-Bs1GbNk%v~VO0X-0rLO=0001BqQITC%`j15hT;FCqoY4FnZKB3%*@P;jEv3A z%}Pp2aBy${0000000000EC2ui0969x0RRO4kc2Sgv@;Klv;SZyj$~<`XsWJk>%J=h zcyd+;^{mf0-%qz6Y)C8`kI1CbQ~^mgpXMb5rC2Od%3#aga+ct*cuX#nf!o$SHFuWjHUCX*wpT5S?($mz{)?mnc z&r{AQ+1KFV;^XAM-+#1My9CSa%k1v)^7Hid_V@Vt`uqI-{{H|23LHqVpuvL(6CQ+j zkD)y*3L{FKNU@^Dix@L%+{m$`MgsmI2M8ERvZTqAC{wCj$+D%(moQ_>oJq5$&6_xL z>fFh*r_Y~2g9`Nt66CI-NRujE%CxD|r%@YTe4UtJkk!!-_?DRpi*S zXw#})%eJlCn`Ph1olCc_-Me^a#?8yOuiw9b11H@pxUk{Fh!f)_toW^g$B-jSo=my2 z<;$2eYu?Pcv**vCLyHdGcw~aps8g$6&APQ~)k+zcW;?pJ?c2C>>)y@V^X%8ag9}d` zo159$ZF?(U&b+zv=bC>HpH7|lVB^T$Lf_84yZ7&vrB@#>yf~nv*=d7c&%V8T(xu7E z2W}oqdiC$~>)+pA{QUpcA^s)XePi)w;DHD(C!GuloRS&~gaDpaA9@6$_1pm* zcIe?_9)@^8Wg<>iqGlf&kRo&|*2ZCi(Z$ywgbt!c;e<9;h}wl%WvHQZBBmH*ha`q* zqLC;PsiKlBGU?)oFk&VijS)6zql8rI$m4N7inSq>FD@Bbm>@birkP8U$(fpJHknzQ zl))LLWK&xCpq)5cdEYbdDF?!~lm-)A+o_A8J<#p%v z=x12nF?uMJM}8_QsA)Pms-a4@cp|D{s*0qmu#&oJsoY7*8ilUpd8vTdZOSQko{}nP zsKV0PsHsQ}J7}t}{vsP|tIje@Xsl;ayPbbJ&ex}}V0BuovfwT&D724?X|A%0nw##p z#jY#vyGNqiE|~L%%N(}ZlD93lUU^$&ym8XYZn@;bd#<_y8(eU?;krw(to0r|@U=4L zt1YJX@!K!3-%9N9#0wiMFT)}q?5>aySDW&&Ax{f2w2mrRvBmmgjG@L``5Q3602k~s z$tNQV^vem$>#(sw|6DS3_|iPxzBp^8GtWyaymG@=n;h}T$8z2B%3n|XFnCQnU7pRF zMxE8vT`wE#&?Iv$x7BeYJhs+%ryH`^-IZ-NeQ0y3HdWirI%KdYvr4qeiYtvW%t10< zDx#A&`z*cw)-pZw-@`#Y_*8`_TRG*5vzs~6k-Lrg>WxR+IBq3Vc+)7jHa&!>@&V@=6`={PScpkJj?i4+Z`8*f&@GS=4V2RQBM9kDK>m zbx(dz;-{~^Z|8qye)~GDFaP}E!Qa*U_TNPR{`=?875@IC3I7JTz5r?kfCh{S0T&p) z1Xcxs4ve4#C+HLiQt*Np%wSF|sKE|;@PlL#9tcNB!V;QKI(qRWYRu!=s%XbP z`tgrmEI=7Eh7&y+5^yO2q#_r|$VNJHjDj@DAtwo&l2{P|n9QUmH_6FPdh(N?45cVX zNy<+aAd*4}q5vq#${nfXlBJBLEN4l}TH5lKxXk4yPl?A?PSPZ>)TJ?2qB1DSye2kZsm*Sh^PK2JXEjM8PCaHb zo$xH?I)M_-cIJ_p@yw?__eslnuF{@qd?!B#8cTl?Wr;Ka=sn3v(1tpcpZ-+n6#fPJ zNdO?gq7T)lL3>h9i8>LVoU|xLGfL8u<}#ulZ6ZZ0YSMUalqVfc>EA#a(w5rvrlmxw zOwG1ZoDTG*JBjH|X+~3@8uh5A{HAG!>a?C-6q7P|DpIEjRGkQwso5&(MNcu+uG&%#Xm{I9ohr7iz|9kF?eyEk!WKu3RjFrd{u)}{@^+S` zwMjj*geBTi*SfBaEtR&LUD>MEwM4~jXhHkj@}l*!IpVH*hifVIw%5Cc{A*MvYuKl~}?Mc5rt=tVXA<_?8-`$yFU|V94J1$HD|F z=L-DG<+4SL6@YrHneJYZZOl40B`N{IJag}p=Uye5UC0M?#kGD+bQC>OB z)zNa9Gu&mEe%U2xu27WMOlM4~l>1TVNfTP(P?w^sGs&}Qv+GltG1Ay zUF}U&pE04a-Xls9P3t7XI@Xs4wWeXh>0Cc{*Pre6kAJ=DU}JjNFDbUM6EJ6GtC-oN z&gLn%&FyY```h3Sx46em?sA)(+_u*5v|q!_bG!T9@Q$~<=S}Z=+Z)`yT=!~#dGCJv z``_bEcTV)}=|lqj;0RB+!WVw-d=vcGFqF2jp}3WYlX`}#q`1a6o)wAbn&VWlcz`he z=9Y;3;wO2e%2&?vmdDZI7SE>3XZ}cm7xLr~mpRRM&h!4B`w_i3*SXJ!9>+EZwd5?p zdCq5T?Hgme)6SMOv|ZwHV7I#I34VH|qps+ww*+_8S*p^jjrIC!{n1<}w9&<`Ym$JS z)k>GOpv!)3pr1VLdroWEPxAIW$DP_&r~7lyZfLyMS?{bqAwu{5ce2ZJ%7P~;;Q@VV z$RB>~{|t0V`mTV^d!99HzkA>xA9<5b9?!wPFqsjb0MCDZ-+W*EX1%N*DK_7kT zDSP@j8=lUrr@ifAulW4tyYr`6!0;>Ccoe&WxffRb?lo%nDJFMPLcCw}X< zbevav%2$B0)_xBcWo0#G^Ho-$1%UIXPIi}B(}924WqfC>nB z<=1Fphkyxqdz{5tisfJ1m3;u^fM&&268L{xRe^W~bl3-6H&R^y_Fw!Jgv8}vCst~b z^?XuCf~{wQCm2G;CrNOZSRoc+0p?f^7=Iy%V3x;&`&55dB4GS?gvC{ajP+JD2x&?< zUOL!yPS|!M(RXL_f)h4_GA37aC0ZkugE1SMohh=)cvh?})1BZem**oHg!hH7VW ziMM&O=Xc-*gI9=#dZ>G)M1g>~O)X}G{v;+`GN>!MQi#=MTj9ls%=Lm02+iFFuv zj@OA()qD5HSGYJ+AlPfHCx-$+hrtngA~%bqgk+pZi_c_>VWwur$cihmcPW@^!pLs8 zCwg;-jCQ4rSoV8s){DUydsBE5&3BF1=vCVIWZXDum}gkwsA^-UiRJiJ)#rYy$cyV} zTJ4BN??{gEh*amuW9hhh_b6RR_l&X#kNsFu|EPt#NNZll5>?l12$_%>wUC)uj}AGI z8&;4iF^)s$4cL&b_K+(Pk=ZtpAlXnB*;yD_k{YRF9GMaxnR3atk~h_oOcjt@ zW|As_l2AuZ3^$ZSS(HWzZ!kChl6-WOOv!LICyobca7{UtR9Te(my`s@Z&taL_4btR zn0p`>75hkX`52aFd6xGxlPFP>XsHxq8F6Zfl}d?hL|2z~d6!uvm+K~Uc-fa+Cz4s|S%$foG09|Q$yQPMkvMr&IyqE4>3x8SYj1g(lWBo^Ic=QjYmMn= zu=tH^Ns^sek%*~pq4{cY_>IwcYm66}Hkq0}Rhc{0n#=Z@hxUqPIh&h_nzqT3tGSoL z`E0yNjj_3wRT!KvIZR(ToCQ^!pn05~6rC&PjlDUClSq35$b7V^o1k=z(rHZ9w}zBw zo!8luPUxNFCyBp_exCjph1EEWDp{VMNrjeToX;t2?df{-xtzy0fa3>yr&*8EN1h0V zpVR4ZM24P!wSfwDUh{t7OHKJXW=utLEp-?JPLaKvCdZeeOpIi!KU`k^U>P{2d zTtwQ4nAwV1+JeM)qbgXR)aYR*_FdQ|V{sZ^kp`qg8l~e!rV47J42CP92&uuZljUfqeyvqgtpn#&kINfORUR zc*?1z>8T-ViGhlTp_)>}s7tGgpDiY+RpMeo*rueao~tOMxeA+nDvf^XX$OjEH>sx7 z_nCW@fx_ynBe<#3x}kjvoPt@K($tLFx@c@lkJvg(>gt-}x}CqctA84v;JU6xl_#bs7tY z7mHdMYp@%ePZRsCAM1?Z6qoI4pZr*|=5(@R>aX26nw!S5=U1=-z-usjPBPo9DI2cH zgtHy0{8zXn!CA>B)LJ!N1SVyHcMB zOT6l6yz}a=sH?nG+p>x2yaEZm(dx32c}{71q(57!*jtS9$9tn2ZKYeS*W10`+q2>R z+oHMqOvP$?=Sy|zd#$ZYy&UVg!yCW$sJ#a1ySY_Y^BaF>TC%n%tHPncuE?`5im85R ztK7$1yDPBj)}#@NyVLuBe|Sq0?7lvTf!9}xFSvh`DybO^WtNJmbb6|{nyG_T!Q@J< z4*P>vyTRq_hZC5nx;0raysn>U!?;MPD7>s3*rTbKyEmAqEd0QVI$AP(rLilrvFctM zh{3ses7w69OdOpL46_W@T|=0LA-1117OTqTqAeVOJIum%x?53PuWC!h`sZC`c!~`9 zqg)uIU0l8k`or29#wHA=z6xN)MO`pRsYw{Wf<>lG+{RK?z>-(LUw6Mmc!&PAmBLwk zjXn&cm#V5oYNk^w$oY54fl9(wY{sX&$obn`qHL!xdV^a`!ITVgc0NjztTT9Ih#>~4}G{eA}*UDI1%O`2c0^Gje z%b@S;q%^yULt0sJytswe%la!zP&9m#j?MzJXEKc#PVDmi3Py5aH3{Clb zP5Yd6-29XDY`8ca(1caZ={df4no0@Hy$j9Iq~*}4SI*g+wp0Ai^{mYn-O&8oy!H%} z&rFli9Ma1>((4S-7kbjn3D7DXWEkyx8jY(G?a!Di(=% z6p7lYy^*2Kx0vnP@C4bM-HEb2+k@MuPchoCO}^7?p2Lkxu29^x?Au@g*m*116>VXf zecZXE+=G|c%5ya;rs~W6FB1t(Bi8I%EpM~L~gz|-f$+0}k!HeRv ztmH8s&Kuq2Q<31Z3*G5R>LFQD9j+wpXe2$F0P3UPIa<>iW`B~8Z{^{t2{^o@n=Zl_BX%3Q&Zs~H2 z4xsnW`61bF6n@n>W;qZMcwKyz0#!~>opGQ-JIt^vFDU-U$72_ zvQFrh@LunrE$VuH?s|RL{0_NG;hg{<@B%;Z1Yht5uK+1= z@Cv{146pFb9qp_>?R?qq6yKNFUJ~DlXA6+FYny?ITa}MQ-vV!SZ3|@)+Oo4-fwHJ|XkBPV=aZ^H`?yC(rXA@AHhU@6=Ac zLyz<;5A`pP@4wFUGf(nQZ)iq;^HOi$O3xEOAJmiu<_xP8ME^HG{u)~^0B6r*YyUtX zkL-w^=s30H{A}}VUm^KzNNeBr)zN`smG-Ui_EaJ70X+A(jogB+=JA;I|FQRa)c0Y9 z$LZ}fgpcP`4-~gZ(8Idsp~Qz=m|MR*o{{JHkN>JyjI7xr`IA4)yKFI+FBOIl&5)mq z%hdV*{rRHr%b`!cjE?tyKO7;Re*qTd^TGPrB4RQ2UHKCGQ8D`{UHg?!Ni4x@eEj8} zEX$!R$|-)U{@ulW=*XxJ{5n#Izy8W!&Cl^+rTRoD_^ILim;UuT@u_gC$#N>;W~!*Q zy2J6R{}cYj5CD**$WC1E=G}iV6i2cwi$YLWwsl`vRT8?kZ@dP8n@@b;PdLmKjfn+p zc4YQ|!5`Guq|%ZxY*xD^1OnZ_U^^zebW>hBn69?nwk(6esYon#`~_dn>~?pI3_(D> zLO#Pj6U9ZwMn@5pGRc;uH%pwUOQS27O3hEu&B@VGFfcLFR5O}Pww)-U%uvv{xs5-< zz&u?(JGx!mU|zsKU=82LWaVY%NL4b=S!qyC%IRzBXYCkMFVyW+RzKEQwOH)WS~_Mu zKV){3clddFcxP~|X!L!i{%RI|egSd#!>6rVn1ZAPF07&MRy~LjB~GMxFJUK!8Ep`h zq0uA9i>17r3Mt8BK!+4nf;hC&|DcN40L{+9+wsrB^>W6`QlF$S>Z`VksLcYgf2&R%d0ep-o3m2bnD^8kAH^UvUV!my|4cbp8R|G@m-jojJ`=N6#4b<=ilG|e*gm% za6keJH1I$K6C_YR1{-ux1^NQBkBK-GwD3Xm^CYyBfNhqU~a!M+z zv@*&cv!pRdsfNs<$ScDXb4)VJH1kX-h0}6P7P)wEGt=+PimTtoP@RbHifRRLgw{j$_WPgO*oT$8DORG z8#Y#1jaByAN0@bXTX3MYVu5K@aYL52WU<9nTW;G;#akr6jT6&xyfil#b@Ls8 zU3dE}16tC;4JQh6?aK<6VT4I!f?M^?m0y1&&f?e71XhR~8_*c%6}%4a%om_c&Z znP;ex^I5Q<#U&UGa$qhvD36&**XchYjvD2a?<3ZTt;?l#9kAPm|%Y-ZRAPTKELKemlf-W2w3=zdL8Rl?oG`yG%{#$S< z9R_h{JRHUPfG9*H`iqE@Fk;n`_{7SEus$68Aq}DhEQ>)=i>z9rNzPEOPq1MjF{r^6 z<<+MxrcriMl+YJB7Dl7(gN#;Of@rd+Mm(~qi)GLO5nu+3SGY_ZejH@lj#$M6U@=~I z%wr>cv_~?y(H#UEf-BUZHF0RokT^sXumUzOM}{&>kQ_rFu@*B;5>kvkmbM_Ap7{TO`45ru%cx#Wn@dMQ1LQOG-fkZgiN3)6KKSAW;IU) zO}0o=1&6d|Hywn{Ir?y!)bwUK;{(oDYEuB*G-o@-gU(^9(4F(#5*tbWq)vL~^P2Wt z3;y)^&u{V*NB9J2LC+~rAraJ|3w%!Q%MS zqa(eJLrHql3u+XlE9IF=r^!*4#?(e8-4jG*dQ(-nbelHCX-_4g({=LHr$e0zO)n=@ zq9%25AZ;8{mHJc&85ML+g{o44+C*|zm84fyCp)$3QLc*frNaE`Ny7@$adNV(BR#7{ z)0xOCGIFgE4QsuESp_l5@vUZ*t23|oSHK2Vu!98_L+i@1yHX*qLfLB_&&ViuGDaYh zF(+4Lu}e()@|T*eLmgbZ!R17Os)eTaYyxbUTG28yxR9*tKp&3nIn^{_Z zP_~?Hl>*UB$=N@$5*D)EYb?q_kl-S5^Q$Fv0MT*p)6 zH%2$fNDwjsl|xm7a@fTK;kGj65{ zoI@#R$k6#Dc6KD58>8oskXgn>p09Z88)1O@c`)m(8*(iyXd=5cp8O^7qyG!vE6>=g z)7D?Ys^lM1=3e`N2`OmH6S0M#EtG`v>w}#d8RrttDc~%b1Ca0 z#2Rf|)=^`>b?Rd3`VxF@q-9yFTJKsiYvvFna0|)EGCCI7v{bewn4QP73KFrCl=dZ& zOv&KB7Ra;xgs6medRLh>eD5;f&*dd#J84{hlXf-(UyZ!KY*#P_``*r# zwjc9)?trJ2(oUu;fPE)m`cnMUL(VjzgPL)T{!7^6$iujyOXxV9Xi?F7VYJ|Kh;o{! zeB{zA`NU5SbC1Xz(-Q=X)|Za%g#Q+=SRc04V;=OGbI;6Alr9)GHeG#-{R!7z_^45W_MOjL>CTk< z)YBc?;bL;`!DTt#kq-5}H?!}mbZ)-i{xaV}-s~rFx|I=sH=++$wQoOV!y|w1&iAq` zmG^SU8N_skklyqmLj4#G|MbG8S${TOK<{4XGE`OQz*e4JnX>sP=| z*#G|Wryu_F|7%smKYnXiS_y~-4gde)|BJXk{96Hd=yIaIPYeYj-!ZxtG zD5SwiltigmieD=)JB+reySjM8!(b!3^fEh3bb?dNm}P@R*aO8mM4PZ%uu{Z?Cn%Uv zJ3<0v#j=w{SKLKdq@-3%ML7IKTU13<{3UAZ#mRd`Sd1<}(z+6KMtl1$eJeLZqDEru zMqTxM?ECF)>^y_w8vo+F5g->g~W({q&sMwygKy6fh0(~z{OVVEsCs2O*F;8 z+q{G%Nh$=%bp)>7QvS(c#JXO5Nny)DTI4;Cgve<~GH|R3Ok6{Ld;?fBK!L=`oPO1n%5 zsT{w<9LvV+%DH4jjx@@`M9aXOOu)p;$Sh03%uK$l%*3oqy8O!1Jj8P>%+GAg)LhHS zY|Xq3P0{>A(p*f_w9Kk}&9|h@+JuJN)QEBv0NIpHe0WUoD^8_6!{E$_;XI+$+)L%m zO2ceUpS;Y{{`*b7BslIojeO`%@Ei^I3(xTUPV(%|o6Jt_Tu%_vOZI$EBy0s_1M`6=YBd9V!W((4MML z3%w}}&Crd)^L-7JityD{;R2#iiP2E&Z?Nm?wR8S37 zQ5{uMEmc!JRa8w?Rb5q9ZBRbUNPVI5Xt zEmmVa)>+-vQLRyCZB}QkQ37~YX`NPTtyXKjR&32yZQWLG?N)F7R&WhhaUEB3Emw0r SS9DERbzRqNjaF`r0028U;QQME literal 0 HcmV?d00001 diff --git a/td/jubile.budsjett.html b/td/jubile.budsjett.html new file mode 100644 index 0000000000..7eaa405196 --- /dev/null +++ b/td/jubile.budsjett.html @@ -0,0 +1,41 @@ + + +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,- + +

Penger

+ +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,- diff --git a/td/jubile.debatt.html b/td/jubile.debatt.html new file mode 100644 index 0000000000..069d44bd3c --- /dev/null +++ b/td/jubile.debatt.html @@ -0,0 +1,59 @@ + + +Debatt om nett og juss + + + + +

Debatt: Elekronisk informasjonsformidlings forhold i Norge

+Tid: Tirsdag 25. april kl. 18:15 +
Sted: Store Auditorium, IMR/UiTø + +

Vi forsøker å få debatten sendt ut over MBONE. + +

Tema

+
+Hvilke forhold skal elektroniske oppslagstavler og elektronisk +formidling av informasjon ha i Norge. + +

Hvilke konsekvenser vil eventuell innføring av redaktøransvar for +formidling av elektroniske konferansesystem få. + +

Hva innebærer en eventuell konsesjonsordning for videreformidling +av nett-tjenester for ytringsfriheten og den nasjonale infrastrukturen +på dette området. +

+

Paneldeltagere

+
+
Gisle Hannemyr +
Oslonett A/S / Elektronisk Forpost Norges Råd +
Stein A. J. Møllerhaug +
DND/Skrivervik Data +
Ande Somby +
stipendiat ved Institutt for Rettsvitenskap + + +

Innleder

+
    +
  • Tage Stabell-Kulø +
+ +

Ordstyrer

+
    +
  • Terje Fallmyr +
+ +Dette er et samarbeidsarangement med Den Norske Dataforening/Tromsø + +

Stein A. J. Møllerhaug lanserte ideen om konsesjonsordning for +elektroniske oppslagstavler i rapperten +"Nytt Media Med +Nye Muligheter: Elektroniske Oppslagstavler" resultatet fra et +prosjekt i Den Norske Dataforening. + +

+
Petter Reinholdtsen - petterr@stud.cs.uit.no
+ + + + diff --git a/td/jubile.gjest.html b/td/jubile.gjest.html new file mode 100644 index 0000000000..24fe035e9e --- /dev/null +++ b/td/jubile.gjest.html @@ -0,0 +1,20 @@ + + + + + + +

Gjester ved TDs jubileumsuke

+ + +
    +
  • Stig S. Bakken <ssb@pvv.unit.no> +
    Programvareverkstedet, Universitetet i Trondheim +
    Kommer 24. april, trenger overnatting +
+
+
Petter Reinholdtsen - petterr@stud.cs.uit.no
+ + + + diff --git a/td/jubile.jobb.txt b/td/jubile.jobb.txt new file mode 100644 index 0000000000..34da03a616 --- /dev/null +++ b/td/jubile.jobb.txt @@ -0,0 +1,21 @@ +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 diff --git a/td/jubile.oppsum.html b/td/jubile.oppsum.html new file mode 100644 index 0000000000..9da5e9c70a --- /dev/null +++ b/td/jubile.oppsum.html @@ -0,0 +1,38 @@ + + + + + + +

Tromsøstudentenes Dataforening fyller 10 år

+ +

Oppsummering

+ +
+
Otto Anshus/SfI - Multimaskiner/distribuerte systemer +
Rundt 15 stykker var møtt opp til en presentasjon av bakgrunnen +for seksjonens prosjekt DOPS - Distribuerte og Parallelle System + +
Debatt om elekronisk informasjonsformidlings forhold i Norge +
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. + +
Stig Sæter Bakken/PVV - STORE & Rune Braathen/TD - SATAN + +
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. + +
+ + +
+
Petter Reinholdtsen - +petterr@stud.cs.uit.no
+ + + + diff --git a/td/jubile.prog.html b/td/jubile.prog.html new file mode 100644 index 0000000000..2beedc872f --- /dev/null +++ b/td/jubile.prog.html @@ -0,0 +1,72 @@ + + +Program for TDs Jubileumsuke + + + +

Tromsøstudentenes Dataforening fyller 10 år

+ +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, + +

Program

+ +
+
Lørdag 22. 19:00 +
Prøvekjøring av bilsimulator med alkotest mm. (Begrenset) +
Mandag 24. 18:15 - 19:00 IMR Lille Aud. +
Otto Anshus/SfI - Multimaskiner/distribuerte systemer.[1] +
Tirsdag 25. 18:15 IMR Store Aud. +
Debatt om elekronisk informasjonsformidlings forhold i Norge +
Med Gisle Hannemyr, Stein A. J. Møllerhaug og Ande Somby. +
Onsdag 26. 18:15 - 19:00, 19:15 - 20:00 IMR Store Aud. +
Stig Sæter Bakken/PVV - STORE - Automatisk programvaredistribusjon.[2] +
Rune Braathen/TD - SATAN - Digitalt dyr i åpenbaringen eller verktøy for økt sikkerhet.[3] +
Torsdag 27. 18:15 - 19:00, 19:15 - 20:00 IMR Store Aud. +
Jo Asplin/SfI - Volumavbilding av atmosfæriske og molekylære datasett.[4] +
Stig Johansen/SfI - Om +raytracing + +
Fredag 28. 18:15 IMR Undervisningsrom 4 +
Klassisk forum.[5] +
+ +Arrangementene er i utgangspunktet åpne for alle interesserte. + +
+[1] Dette er en presentasjon av en av de faglige sidene av prosjektet +Distribuerte og Parallelle System (DOPS) ved Seksjon for Informatikk + +

[2] +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 + +

[3] +Presentasjon av Security Administrators Tool for Analyzing +Networks (SATAN), et brukervennlig brekkjern for systemcrackere. + +

[4] +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. + +

[5] +Dette er et gammelt konsept der man setter seg ned over en bok-øl +med dempet klassisk musikk fra stereoanlegget og et datafaglig +starttema. + +

+
Petter Reinholdtsen - petterr@stud.cs.uit.no
+ + + diff --git a/td/saker.940913.html b/td/saker.940913.html new file mode 100644 index 0000000000..7ee8b4384d --- /dev/null +++ b/td/saker.940913.html @@ -0,0 +1,54 @@ + + +Saksliste til Styremøte i TD 940913 + + + +
+
Dato: +Tirsdag 13.september 1994 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, (Bjørn Stabell,) Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Dag-Frode Olsen, Vegar Næss, Bengt Norbakken, Frode Fjeld +
+
+

Saksliste til Styremøte i TD

+ +
    +0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] + +
  2. Orienteringer +
      +
    • Kvinneandelen på informatikk [Frode & Terje] +
    • Oppstart av vaktordningen [Ronny & Dag Frode] +
    • Tur til Autosom [Terje] +
    +
  3. Medlemsmøtet Torsdag 22. september [Frode] +
      +
    • Omorganisering i styret? +
    + +
  4. ISI-Cupen - 17. september [Petter]
    +Jeg ber om at vi spanderer pizza på laget som takk for innsatsen. + +
  5. 10 års Jubileum, tirsdag 25. april 1995 +
      +
    • Jublieumshefte +
    • Ideer? +
    + +
  6. Eventuelt +
+ +Vedlegg: Tidsplan H94 / +V95.

+ + +

Petter Reinholdtsen - Leder TD
+12.09.94 + + + diff --git a/td/saker.941003.html b/td/saker.941003.html new file mode 100644 index 0000000000..4df96dbf66 --- /dev/null +++ b/td/saker.941003.html @@ -0,0 +1,43 @@ + + +Saksliste til Styremøte i TD 941003 + + + +
+
Dato: +Tirsdag 3.oktober 1994 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Vegar Næss, (Bengt Norbakken,) Frode Fjeld, Runar Karlsen, +Heidi Hundåla Villmones +
+
+

Saksliste til Styremøte i TD

+Velkommen til de nye styremedlemmene. +
    +0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] + +
  2. Orienteringer +
      +
    • Kvinneandelen på informatikk [Frode & Terje] +
    • SUN SPARCstation 5 er SUN SPARCclassic [Petter] +
    • Tur til Autosom [Terje]
      +Terje orienterer om mulig tur til Autosim +
    +
  3. Oppsummering fra Medlemsmøtet +
  4. Publisitet rundt TD
    +Vi må markere oss mer blant studentene og i miljøet. +
  5. Arrangement for Høsten.
    +Noen gode ideer til hva vi skal ta oss til. :-) +
  6. Eventuelt +
+ +
Petter Reinholdtsen - Leder TD
+02.10.94 + + + diff --git a/td/saker.941025.html b/td/saker.941025.html new file mode 100644 index 0000000000..1c98bee296 --- /dev/null +++ b/td/saker.941025.html @@ -0,0 +1,46 @@ + + +Saksliste til Styremøte i TD 941025 + + + +
+
Dato: Tirsdag 25.oktober 1994 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen, +Heidi Hundåla Villmones +
+
+

Saksliste til Styremøte i TD

+Velkommen til de nye styremedlemmene. +
    +0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] + +
  2. Orienteringer +
      +
    • Pakke fra Skrivervik AS [Petter] +
    • Bedriftsbesøk [Terje] +
    • XPilot-konkurranse [Vegar] +
    • Programmeringskonkurranse [Frode] +
    • Juleavslutning [Espen] +
    • Økonomi [Bengt] + +
    • Kontakt med Jentegruppa [Frode & Terje] +
    • Nytt nummer av Vinduet [Vegar] +
    + +
  3. Samarbeid med fagutvalget [Ronny & Frode]
    +Hvilken arbeidsdeling skal være mellom TD og fagutvalget? + +
  4. Eventuelt +
+ +
Petter Reinholdtsen - Leder TD
+24.10.94 + + + diff --git a/td/saker.941122.html b/td/saker.941122.html new file mode 100644 index 0000000000..09680d5d87 --- /dev/null +++ b/td/saker.941122.html @@ -0,0 +1,61 @@ + + +Saksliste til Styremøte i TD 941122 + + + +
+
Dato: Tirsdag 22. november 1994 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen, +Heidi Hundåla Villmones +
+
+

Saksliste til Styremøte i TD

+
    +0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] +
  2. Orienteringer +
      +
    • Programmeringskonkurranse [Frode] +
    • Nytt nummer av Vinduet [Vegar] +
    • Fagutvalget [Ronny & Frode]
      +
    • Status for TD-maskinene [Petter] +
    + +
  3. Oppsummering fra XPilot-konkurransen +
  4. Oppsummering fra Jentegruppas info for 1.klasse +
  5. Bedriftsbesøk [Terje] + Skal vi ta en tur til Autosim? Hvor sent kan vi arrangere en tur? +
  6. Juleavslutning [Espen]
    + Hva gikk galt med årets juleavsluttning. Er det for sent å arrangere en? +
  7. Planer for våren +
    3.-5. februar?? (1.uke i feb.) +
    Skibotntur. [Vegar] +
    25. april +
    10 års jubileum +
    ? +
    Programmeringskonkurranse [Frode] +
    ? +
    Auksjon +
    ? +
    Forelesninger +
    ? +
    Bedriftsbesøk +
    ?? +
    Hva som helst... +
    + +
  8. Eventuelt +
+ +BTW: Hvor i svarte er protokollen! + +
Petter Reinholdtsen - Leder TD
+21.11.94 + + + diff --git a/td/saker.950119.html b/td/saker.950119.html new file mode 100644 index 0000000000..eda9392faf --- /dev/null +++ b/td/saker.950119.html @@ -0,0 +1,66 @@ + + +Saksliste til Styremøte i TD 950119 + + + +
+
Dato: Torsdag 19. Januar 1995 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 12:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +(Ronny H. Arild, Vegar Næss,) Bengt Norbakken, Frode Fjeld, Runar Karlsen, +Heidi Hundåla Villmones +
+
+

Saksliste til Styremøte i TD

+
    0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] +
  2. Orienteringer +
    • Status for TD-maskinene [Petter] +
    • Skibotnturen 3.-5. febr. [Frode & Vegar] +
      Skrivervik Data sender to stykker. Søknad om + støtte sendt IMR, SfI og Skrivervik Data. +
    + + +
  3. Vaktordningen [Ronny] +
    Det bør settes opp en ny ansvarlig, da Ronny ville trekke seg +tilbake på årsmøtet. + +
  4. Forelesninger [Petter] +
    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. + +
  5. 10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar] +
    Debattarrangement Bing/Hannemyr - planlegging igang +
    Invitasjon av andre dataforeninger +
    Jubileumsaften (Bespisning & taler) +
    ... + +
  6. Forsikring til TD-maskinene + +
    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. + +
  7. Vinduet [Alle] +
    De artiklene som ble avtalt skrevet til vinduet bør være ferdig +snarest. + +
  8. Eventuelt +
+Vedlegg: + + +Beklager at denne kom så sent. +
+
Petter Reinholdtsen - Leder TD
+18.1.95 + + + diff --git a/td/saker.950119.vinduet.txt b/td/saker.950119.vinduet.txt new file mode 100644 index 0000000000..65f1889ca0 --- /dev/null +++ b/td/saker.950119.vinduet.txt @@ -0,0 +1,41 @@ +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...... diff --git a/td/saker.950201.html b/td/saker.950201.html new file mode 100644 index 0000000000..f543c81d6d --- /dev/null +++ b/td/saker.950201.html @@ -0,0 +1,68 @@ + + +Saksliste til Styremøte i TD 950201 + + + +
+
Dato: Onsdag 1. Februar 1995 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen, +Heidi Hundåla Villmones +
+
+

Saksliste til Styremøte i TD

+
    0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] +
  2. Orienteringer +
    • Skibotnturen 3.-5. febr. [Frode & Vegar] +
    • Skifte av ansvarlig for vaktordningen [Ronny & Heidi] +
    • Forsikring til TD-maskinenen [Terje] +
    • 10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar] +
    • Programmeringskonkurranse [Frode] +
    • Forelesninger [Petter] +
    • Artikler til Vinduet [Alle] +
    • Bedriftsbesøk [Terje & Heidi] +
    + +
  3. Vaktordningen [Ronny] + +
    - 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? +
    - Tom Grydeland (Inst.råds repr) satte opp denne lista som innspill +til hva henvendelsen burde inneholde. + +
    • 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) +
    • Beregn 5 vakter i uka, (18 vår+15 høst) 33 uker pr. år. +
    • Foreslå hvordan utgiftene skal fordeles + +
    +
  4. Saker til Årsmøtet +
    Saker til årsmøtet må planlegges. + +
  5. Valg av revisor +
    Vi må velge en revisor til å gå gjennom regnskapet sammen med Bengt. + +
  6. Eventuelt +
+Vedlegg: + + +
+
Petter Reinholdtsen - Leder TD
+31.1.95 + + + diff --git a/td/saker.950215.html b/td/saker.950215.html new file mode 100644 index 0000000000..98a414025d --- /dev/null +++ b/td/saker.950215.html @@ -0,0 +1,53 @@ + + +Saksliste til Styremøte i TD 950201 + + + +
+
Dato: Onsdag 15. Februar 1995 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen, +Heidi Villmones Hundåla +
+
+

Saksliste til Styremøte i TD

+
    0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] +
  2. Orienteringer +
    • "Datapub" i forbindelse med Uka95 +
    • Forsikring til TD-maskinenen [Terje] +
    • 10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar] +
    • Programmeringskonkurranse [Frode] +
    • Bedriftsbesøk [Terje & Heidi] +
    • Framdrift for Vinduet [Vegar] +
    + +
  3. Vaktordningen [Ronny] + +
    - Brev til Instituttet ang. vaktordningspenger presenteres[Bengt] + +
  4. Oppsummering Skibotnturen 3.-5. febr. [Frode, Petter & Vegar] + +
  5. Saker til Årsmøtet [Espen & Ronny] +
    Saksliste til Årsmøtet må gjøres klart og innkalling sendes ut. + +
  6. Valg av revisor [Bengt] +
    Vil Ole Kristian? være revisor? + +
  7. Eventuelt +
+Vedlegg: + + +
+
Petter Reinholdtsen - Leder TD
+13.2.95 + + + diff --git a/td/saker.950301.html b/td/saker.950301.html new file mode 100644 index 0000000000..e547f744d7 --- /dev/null +++ b/td/saker.950301.html @@ -0,0 +1,61 @@ + + +Saksliste til Styremøte i TD 950301 + + + +
+
Dato: Onsdag 1. Mars 1995 +
Sted: Møterommet utenfor Ekspedisjonen, IMR +
Når: kl. 16:15 +
Styret: +
Petter Reinholdtsen, Espen Skoglund, Terje Marthinussen, +Ronny H. Arild, Vegar Næss, Bengt Norbakken, Frode Fjeld, Runar Karlsen, +Heidi Villmones Hundåla +
+
+

Saksliste til Styremøte i TD

+
    0. Godkjenning av styremøtereferat +
  1. Gjennomgang av post [Espen] +
  2. Orienteringer +
    • 10 års jubileum (24.-28. april) [Petter, Espen, Frode & Vegar] +
    • Programmeringskonkurranse [Frode] +
    • Brev til Instituttet sendt [Petter & Bengt] +
    + +
  3. Bedriftsbesøk [Terje & Heidi] +
    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. + +
  4. Forsikring til TD-maskinenen [Terje] +
    Terje har undersøkt priser på forsikring, og vi må bestemme oss +for hvilken vi tar. + +
  5. Årsmøtet [Espen & Ronny] +
    Alt skulle nå være klart til årsmøtet. + +
  6. Godkjenning av regnskap for 1994 +
    Regnskapet som ble godkjent per mail må refereres i +styreprotokollen. + +
  7. Regnskap 1995 fram til nå [Bengt] +
    Bengt legger fram regnskapet før perioden hans er over.. + +
  8. Abonnement på Linux Journal +
    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. + +
  9. Eventuelt +
+Vedlegg: + + +
+
Petter Reinholdtsen - Leder TD
+13.2.95 + + + diff --git a/tm/backuprutine.html b/tm/backuprutine.html new file mode 100644 index 0000000000..8b9b9f302f --- /dev/null +++ b/tm/backuprutine.html @@ -0,0 +1,67 @@ + + +Backup-rutiner på Origo + + + + +Origo drift - 1996-06-11 +
Petter Reinholdtsen <pere@td.org.uit.no> +
+ +

Backup-rutiner på Origo

+ +Backup foretas daglig av den som sitter nærmest DAT-spilleren. Pr. +1996-06-11 er dette Geir Frierstad. + +

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. + +

Backup tas av cron-jobber som kjøres fra valborg hver natt +vha. rsh. Hver morgen skal nattens backup tas vare på og +neste dags backup-tape gjøres klar. + +

Alle DAT-tapene merkes med maskin, ukedag og nummer og rotes i +løpet av tre uker. + +

Daglig rutine

+ +
    +
  1. Ta ut DAT-tape og merk med dato. Kontroller at DAT-nummer stemmer +overens med mail utsendt av cron. +
  2. Sett i neste DAT-tape (ett nummer større) +
  3. Frakt tapen merket med dagens dato til safe el. +
+ +

Dagsoversikt, backuptaper

+Det er 11 maskiner - kjell, valborg og egon er viktigst. + + +
Maskin Natt til Dagsnummer + +
Kjell Mandag 1 +
Valborg Tirsdag 2 +
egon Onsdag 3 +
gunnar Torsdag 4 +
Kjell Fredag 5 + +
benny Mandag 6 +
basse Tirsdag 7 +
cola Onsdag 8 +
Valborg Torsdag 9 +
death Fredag 10 +
eurosongMandag 11 +
pcpdy Tirsdag 12 +
egon Onsdag 13 +
romeo Torsdag 14 +
gunnar Fredag 15 +
+ +
+
Petter Reinholdtsen - +petterr@stud.cs.uit.no
+ + + + diff --git a/tm/perl.compile.html b/tm/perl.compile.html new file mode 100644 index 0000000000..c159413638 --- /dev/null +++ b/tm/perl.compile.html @@ -0,0 +1,39 @@ + + + + + + + +

Compilering av perl

+
+./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
+
+ +

Compiling gcc

+ +
+./configure --prefix=/store --local-prefix=/store --gxx-include-dir=/store/lib/g++-include 
+make bootstrap
+
+ +
+
Petter Reinholdtsen - +petterr@stud.cs.uit.no
+ + + + diff --git a/tm/xntpd.conf.html b/tm/xntpd.conf.html new file mode 100644 index 0000000000..6919e0a39c --- /dev/null +++ b/tm/xntpd.conf.html @@ -0,0 +1,22 @@ + + + + + + + +

Konfigurering av xntpd(8)

+ +xntp er kompilert i store. + +For å starte brukes '/store/etc/init.d/xntpd start'. + +

Konfigurasjonsfilene ligger på valborg:/local/config (ntp.conf*). + +

+
Petter Reinholdtsen - +petterr@stud.cs.uit.no
+ + + + -- 2.47.2